This catalog is the published plant record behind NeuronPlant deliveries: why a fabric, a cooling loop, or a storage tier was chosen. MCP is how agents read that record without scraping HTML. It documents the factory. It is not the product NeuronPlant sells.
Endpoint: https://neuronplant.com/api/mcp. Streamable HTTP. Read-only. No authentication. Customer names and customer specifications publish only after written approval, same gate as /customers.
Records
112
Topics
14
Tools
7
Held specs
3
Auth
None
Project file: .cursor/mcp.json. Global file: ~/.cursor/mcp.json. Cursor detects Streamable HTTP from the url field.
Production
{
"mcpServers": {
"neuronplant": {
"url": "https://neuronplant.com/api/mcp"
}
}
}Local (npm run dev)
{
"mcpServers": {
"neuronplant": {
"url": "http://localhost:3000/api/mcp"
}
}
}Claude Desktop (mcp-remote)
{
"mcpServers": {
"neuronplant": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://neuronplant.com/api/mcp"]
}
}
}Raw HTTP test
curl -X POST https://neuronplant.com/api/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}'Ask in natural language. The client picks the tool. Every full record ends with a canonical URL so answers can be cited.
list_catalog
Returns the published NeuronPlant factory catalog: platforms, NVIDIA switches, storage-by-workload, DSX campus layers, factory templates, delivery rationale, insights, plant layers, and anonymized project records. Each entry has id, topic, title, summary, and canonical URL. Use this before get_record. Customer names and unpublished specs are omitted.
get_record
Fetches one published record as Markdown, with the canonical URL appended for citations. Use an id from list_catalog, search_knowledge, or get_topic (for example platform:b300, switch:q3400, storage:training, dsx:cdu, factory:training, decision:why-separate-planes, insight:ethernet-vs-infiniband). Unpublished customer specs return sector and region only.
search_knowledge
Search the published NeuronPlant plant record for a topic, SKU, or delivery question across titles, summaries, and bodies. Use this when the user asks why a fabric, cooling loop, storage tier, or DSX campus layer was chosen, or which NVIDIA switch does which job.
list_topics
Returns every knowledge collection (platforms, switches, storage, DSX, factories, design decisions, and so on) with published counts. Customer-spec includes how many records are held pending written approval.
get_topic
Returns every published record in one collection. Use list_topics if you are unsure which topics exist. For customer-spec, unpublished rows are omitted; call list_held_specs for sector/region placeholders.
get_related
Given a record id, returns related published records from the same topic, plus explicit design-decision links. Use this after get_record to pull the 'why' alongside the SKU.
list_held_specs
Returns customer specification slots that exist in the content model but are not published. Sector and region only. No customer names. Same written-approval gate as the public /customers page. Use this to explain that a long-term factory record for customer specs exists, without leaking private detail.
MCP is the agent interface. These files are the discovery layer so a client that does not speak MCP can still find the catalog.
/llms.txtShort map of routes, MCP, and /llms/*.txt collection files./llms-full.txtConcatenated published knowledge, grouped by collection./llms/cabling.txtExample collection file. One per knowledge topic./api/knowledgeStructured JSON of the same catalog. Query with ?topic= or ?id=./.well-known/mcp.jsonMCP server card: name, version, Streamable HTTP URL, tool list.Held customer specification slots exist in the content model so future approved specs can land without a schema change. Until written approval they expose sector and region only. No invented names. No NVIDIA partnership claim. No NVOnline reprints.
NP / Intake
One accountable delivery partner from AI requirement to a delivered factory: site, power, cooling, compute, fabric, structured cabling & passive infrastructure, storage, platform, procurement, and handover. You do not need a vendor list or a hall name first. The hall is a supplier.