Skip to main content
Glama

federated_expand

Walk a remote note's table of contents level by level inside a connected knowledge base (progressive disclosure), same as expand. Canonical call: federated_expand(kb_id=..., path=<result.note_path>, toc_path=[...]). Omit toc_path for the top level, or pass a toc_path to list that node's subsections. A section with subsections lists them; a section without subsections is returned in full, as federated_note_html would return it — has_children on each listed child says where that happens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pidNoNon-negative integer (uint64) remote note id, copied verbatim from a federated_search result's note_id field. Prefer path
hrefNoString remote note href, copied verbatim from a federated_search result's href field
pathNoString remote note path, copied verbatim from a federated_search result's note_path field
kb_idYesTarget knowledge base id; nested bases use '/' (e.g. "philosophers/nietzsche" routes through the 'philosophers' peer, recursively). Federation nests up to 3 levels deep (kb_id path segments); a deeper path is rejected.
note_idNoSame remote note id as pid, but as a STRING (uint64) — stringify the federated_search result's note_id field. Prefer path
toc_pathNoBreadcrumb path to the node to expand. Omit or [] for the top level.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

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 behavioral burden and does a good job: it discloses progressive disclosure, how sections with and without subsections are returned, and that has_children indicates where full expansion happens. It does not mention side effects or auth/rate constraints, but this appears to be a read-oriented navigation tool and the provided behavior is substantive.

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 three sentences with no waste: purpose and sibling anchor, canonical usage, then boundary behavior. It is front-loaded and every sentence earns its place.

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 and no annotations, the description gives enough context to call the tool correctly: it explains the top-level vs toc_path behavior, what happens at leaf sections, and how to recognize expandable children via has_children. Combined with the fully documented schema, it is complete for this tool's complexity.

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 input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds value by providing a canonical call showing how kb_id, path, and toc_path combine, and by clarifying toc_path semantics beyond the schema. It does not need to re-explain each parameter.

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 names a specific action and resource: 'Walk a remote note's table of contents level by level inside a connected knowledge base (progressive disclosure).' It also anchors the tool relative to siblings by saying 'same as expand' and clarifies the relationship to federated_note_html behavior. An agent can distinguish this from expand and federated content tools.

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?

The description gives a canonical call and clear guidance on when to omit or pass toc_path, which establishes usage context well. It references 'same as expand' and compares return behavior to federated_note_html, but it does not explicitly state when not to use this tool or give direct exclusion criteria against specific siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.