Fetch the instructions/guidance for a federated knowledge base by kb_id (e.g. "philosophers/nietzsche") — read a base's own conventions before searching it. Nested bases are addressed with '/' and the call routes through each peer recursively.
| Name | Required | Description | Default |
|---|---|---|---|
| kb_id | Yes | Target knowledge base id; nested bases use '/' (e.g. "philosophers/nietzsche" routes through the 'philosophers' peer, recursively) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the recursive routing behavior for nested bases. However, it does not disclose safety (read-only), authentication needs, error handling, or return format. These are minor omissions for a fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the purpose. Every part is informative with no fluff. The example is integrated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (federated, recursive), single parameter, and no output schema, the description covers the key behavior and usage pattern. It could mention what happens on error or if the kb_id doesn't exist, but it is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds the recursive routing behavior but does not provide new meaning beyond the schema's already clear explanation of the parameter. The example in the schema is repeated in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'instructions/guidance for a federated knowledge base by kb_id'. It specifies the scope (federated) and adds behavior (nested bases with '/', recursive routing). This distinguishes it from siblings like 'instructions' (non-federated) and other federated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'read a base's own conventions before searching it', indicating when to use the tool. It explains addressing nested bases. While it doesn't explicitly mention when not to use, the context and sibling 'instructions' imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The local/federated pairs are clearly separated by the federated_ prefix, and search, note_html, expand, and similar each have distinct roles. The main ambiguity is between instructions and wiki, which both sound like meta-instruction tools, and expand's documented leaf-reading overlap with note_html is a minor edge case.
Tool names are uniformly snake_case and the federated_ prefix creates a strong, predictable pattern across local and remote counterparts. However, base names mix verbs (search, expand), nouns (instructions, wiki), a format-ish noun (note_html), and an adjective used as a command (similar), so the pattern is not fully verb_noun.
11 tools is a well-scoped size for a read-oriented knowledge base with both local and federated access. Each tool maps to a clear workflow stage—search, read, navigate, find similar, or fetch instructions—without significant redundancy or bloat.
The tool surface covers search, reading, structural navigation, similar-note discovery, and federated equivalents, plus base instructions, which supports the core retrieval workflow end to end. The notable gap is the lack of a way to enumerate or browse all notes in a corpus without already having a query or path, though agents can work around this via search and instructions.