mcp-documentation

Search Doc

search_doc

Search indexed documentation with full-text keyword queries, using phrases, OR/AND, and filters to find relevant chunks with snippets.

Instructions

Full-text keyword search over indexed document chunks.

Matching is case-insensitive and word-based: punctuation splits words, so MP-BGP is indexed as the two words "mp" and "bgp". Unquoted, a '-' is query syntax and fails, so write "MP-BGP" in double quotes (a phrase). Space-separated terms are implicitly ANDed; there are no synonyms, so widen a search with OR ('L3Out OR "external routing"').

Each result carries a short snippet around the hits and a score; use read_doc with the result's chunk_number for the full chunk text.

Returns: Up to max_search_results matching chunks (see config.yaml), best match first, plus next_offset when more matches exist.

Raises: ValueError: pattern is not valid FTS5 query syntax.

Input Schema

TableJSON Schema

Name	Required	Description
`offset`	No	Skip this many best matches, for paging
`pattern`	Yes	SQLite FTS5 MATCH query. Examples: 'BGP AND OSPF', '"MP-BGP"', 'L3Out OR "external routing"', 'NEAR(bgp ospf, 10)', 'config*'. Quote any term containing punctuation such as '-'.
`category`	No	Only search this category, or null for all
`file_name`	No	Only search the document with this extension-stripped filename, or null for all
`subcategory`	No	Only search this subcategory, including those nested below it ('cisco' also matches 'cisco/aci'), or null for all

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	No
`next_offset`	No	Pass as offset to get the next page, or null when there are no more matches

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Sep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral burden and succeeds: it discloses case-insensitivity, word-based tokenization, quote requirements for punctuation, implicit AND, absence of synonyms, result ordering, max result cap, next_offset paging, and ValueError on invalid FTS5 syntax.

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?

The description is structured with a summary, behavioral details, returns, and raises. Every sentence earns its place, and the length is justified by the complexity of the FTS5 query language.

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?

Covers query syntax, result contents, paging, error handling, and how to retrieve full chunks. With an output schema present and no annotations to worry about, nothing an agent needs to invoke the tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining FTS5 query semantics, OR/AND usage, quoting pitfalls, and paging behavior, which meaningfully helps an agent form valid pattern values.

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?

Opens with 'Full-text keyword search over indexed document chunks' – a specific verb, resource, and clear scope. This distinguishes it from siblings list_doc, list_categories, and read_doc, and it even names read_doc as the follow-up for full chunk text.

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

Usage Guidelines4/5

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

Provides rich guidance on query formation and explicitly instructs using read_doc with chunk_number for full text. It doesn't spell out when to prefer search_doc over list_doc, but the search/list/read roles are clear from the first sentence and tool names.

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

Deploy Server