Skip to main content
Glama
RuloGB

compendio-mcp

by RuloGB
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Documentation search

search_docs

Search documentation with hybrid lexical-semantic matching; filter by tags, type, module, or inclusion status to find relevant sections.

Instructions

Hybrid search (lexical BM25 + semantic) in natural language over the project's documentation, with metadata filters. Entry point for any question about what the project does or why — behaviour, business rules, the exact text of a user-facing message, limits, endpoints, deployment steps, or the reasoning behind a decision. For a content or project question, this is the cheapest first probe; a filename alone does not reliably identify an indexed path, so resolve named .md files with docs_overview before calling read_doc. Source code remains the authority on current behaviour, while these docs are the only record of intent. The top result carries a full-length excerpt, centred on the part of the document that matched, which usually answers outright; the rest carry short ones, centred on their own match, enough to tell whether the top result is the right one. Each result has path, title, section, excerpt and score; section names the document region the fragment came from — a document with no headings reports one region for the whole file. A '…' at either end of an excerpt marks content omitted there — that is the signal to call read_doc with its path and section. If the project declares convention.excludedStatuses, documents in those statuses are left out unless include_excluded is set; if it declares none, no document is excluded by status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNoNumber of results (5 by default)
tagsNoFilter by tags (matching one is enough) — same caveat: omit unless docs_overview showed them.
typeNoFilter by document type — project-defined, and absent entirely in many projects. Omit it unless docs_overview showed you the value; never infer it from directory names or paths.
queryYesNatural-language query
moduleNoFilter by module — same caveat as type: omit unless docs_overview showed the value.
include_excludedNoInclude documents whose status is listed in convention.excludedStatuses (no effect if the project declares no exclusions)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it explains the hybrid search method, metadata filtering, excluded status behavior, the shape of each result, excerpt-length differences, and the meaning of the '…' marker as a signal to call read_doc.

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

Conciseness4/5

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

The description is longer than average but well structured and front-loaded with purpose. Some ideas are repeated or phrased redundantly, but every sentence carries useful operational guidance, so the verbosity is justified.

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?

Despite having no output schema, the description fully explains the result structure, excerpt behavior, filtering semantics, and the relationship to docs_overview and read_doc. This gives an agent enough context to use the tool correctly without additional documentation.

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?

The schema already covers all parameters with descriptions, so the baseline is high. The description adds valuable caveats beyond the schema, such as omitting tags/type/module unless docs_overview showed valid values, never inferring type from directory names, and the no-effect behavior of include_excluded when no exclusions are declared.

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 clearly states that this is a hybrid lexical+semantic natural-language search over project documentation, and frames it as the entry point for project content questions. It also distinguishes itself from siblings by telling the agent to use docs_overview first for named files and read_doc for full excerpts.

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 gives explicit when-to-use guidance: it is the cheapest first probe for content/project questions, and it instructs resolving named .md files with docs_overview before read_doc. It also explains when to call read_doc based on excerpt truncation, and how excludedStatuses affects results.

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

Deploy Server

Other Tools