neutrinos-mcp

Overview Schema Source Related Servers Discussions Admin

search_docs

Retrieve ranked, citable passages from Neutrinos product documentation by natural-language query. Ensure accurate answers for your specific product version across thousands of topics.

Instructions

Search the Neutrinos product documentation (53 publications, 3,117 topics) and return ranked, citable passages. This is the entry point for any question about Neutrinos products. IMPORTANT: the same topic is often documented separately for several product versions. If the user's version is known, pass product and version; otherwise only current versions are searched. Check sufficient_evidence before answering - when it is false, say the documentation does not cover the question rather than inferring an answer. Call list_products first if unsure what to pass for product.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	The user's question in natural language. Prefer the user's own wording - the index is built to absorb vocabulary mismatch. Several narrow searches beat one broad one.
`top_k`	No	Number of passages to return. Near-duplicate passages across versions are collapsed before this limit is applied.
`product`	No	Restrict to one product, e.g. 'Studio'. Values come from `list_products`. Omit to search all products.
`version`	No	Restrict to one product version, e.g. '9'. Requires `product`. Omit to use the current version.
`response_format`	No	'concise' returns ~400-token excerpts (use this by default). 'detailed' returns full sections and costs roughly 4x the tokens.	concise
`include_superseded`	No	Include documentation for superseded product versions. Use only when the user is explicitly on an older version or asking about history.

Output Schema

TableJSON Schema

Name	Required	Description
`notice`	No	Present when results were capped or scope was widened. Tells you how to narrow the next call.
`results`	Yes
`truncated`	No
`confidence`	Yes	Aggregate confidence over the returned set.
`scope_applied`	Yes
`match_expression`	No	The lexical expression that produced hits, after the relaxation ladder. If it shows OR-relaxation, matching was loose - weigh the results accordingly.
`version_ambiguous`	No	True when strong hits exist in multiple product versions and the user did not state one. Ask the user which version they are on.
`sufficient_evidence`	Yes	False means the documentation does not adequately cover this question. Tell the user so; do not compose an answer from weak hits.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Aug 28, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it delivers: it discloses scope, version-sensitive behavior (only current versions unless product/version passed), and the meaning of sufficient_evidence. It could add a bit more about limits (e.g., rate, token cost, or that it is a read-only search), but the disclosed behaviors are genuinely important and not obvious from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, tightly packed, front-loading the core purpose before caveats. Every sentence adds actionable value: what it searches, when to use it, how to handle versions, and how to interpret the evidence flag. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for an agent facing a documentation-search task: it states scope, expected behavior, version handling, evidence interpretation, and a sibling fallback. The output schema exists, so return values need no elaboration. This is a well-rounded definition that would let an agent call the tool correctly in nearly all scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all six parameters, including examples and defaults. The description adds context for product and version (version sensitivity) and references list_products for values, but it does not materially enrich the meaning of query, top_k, response_format, or include_superseded beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search'), a concrete resource (Neutrinos product documentation with corpus counts), and a clear output ('ranked, citable passages'). It positions itself as 'the entry point for any question about Neutrinos products,' distinguishing it from siblings like fetch_document and list_products.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly frames when to use the tool ('any question about Neutrinos products'), gives conditional guidance (pass product/version when version is known), and points to a sibling (call list_products first if unsure). It also tells the agent what to do with the result (check sufficient_evidence), leaving no ambiguity about when to apply this search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server