Skip to main content
Glama

trip2g

by io.github.trip2g
OverviewDiscussionsAdmin

federated_search

Search connected knowledge bases. Returns snippets with heading breadcrumbs (title > section > subsection) and a precise toc_path per match, same as search; results also carry an absolute kb_id (string) to use verbatim on follow-up calls. Pass kb_id for one base, kb_ids for selected bases, or omit both to fan out. Nested bases are addressed with '/': kb_id "philosophers/nietzsche" routes through the 'philosophers' peer to the base it federates (recursive), up to 3 levels deep. Canonical call: federated_search(kb_id="philosophers/", query) -> federated_note_html(kb_id="philosophers/", path=<result.note_path>) — the standard way to descend into a leaf corpus and read real content, not hub cards. The optional fields each run an extra search whose results are merged with the main one; fill them to find more.

Input Schema

NameRequiredDescriptionDefault
kb_idNoTarget 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.
limitNoMax number of results to return (default 6)
queryYesThe user's question exactly as they asked it. Do not rewrite it.
kb_idsNoTarget knowledge base ids; each accepts the same nested 'peer/base' form as kb_id
short_queryNoOptional. 2-3 words in English that the answering note is sure to contain: the main term and one qualifier, in dictionary form (nominative singular, infinitive). A short phrase, not a list; no punctuation. Keyword search needs every word to match, so fewer precise words beat many.
detail_limitNoHow many results include full snippet matches; results beyond this are returned as lightweight previews (title, path, score) to save context (default 3)
expected_answerNoOptional. One or two sentences in English that the answering note itself could contain, written the way the notes state facts (e.g. 'To reset a password, open Settings and select Security.'). Not a description of what the note covers, not a question. If unsure of details, stay general but keep it a statement of fact.
rephrased_queryNoOptional. The question asked another way in English: different words, and the canonical name of what it asks about if you know it. One sentence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / expected_answer
      Added value: +{
+  "description": "Optional. One or two sentences in English that the answering note itself could contain, written the way the notes state facts (e.g. 'To reset a password, open Settings and select Security.'). Not a description of what the note covers, not a question. If unsure of details, stay general but keep it a statement of fact.",
+  "type": "string"
+}
    • changedInput schema / properties / query / description
      Previous value: -"Search query"New value: +"The user's question exactly as they asked it. Do not rewrite it."
    • addedInput schema / properties / rephrased_query
      Added value: +{
+  "description": "Optional. The question asked another way in English: different words, and the canonical name of what it asks about if you know it. One sentence.",
+  "type": "string"
+}
    • addedInput schema / properties / short_query
      Added value: +{
+  "description": "Optional. 2-3 words in English that the answering note is sure to contain: the main term and one qualifier, in dictionary form (nominative singular, infinitive). A short phrase, not a list; no punctuation. Keyword search needs every word to match, so fewer precise words beat many.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/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 does well: it discloses the return shape, that a deeper-than-3-level path is rejected, that nested bases route recursively, that detail_limit downgrades excess matches to lightweight previews, and that the optional fields each trigger an extra merged search. It stops short of auth/permission requirements, ordering, or rate behavior, so not a 5.

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?

Front-loads purpose and return format, then moves to targeting, nesting, and the canonical call in a logical sequence. It is a dense single paragraph and somewhat long, but nearly every clause carries operational information, so little is wasted.

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

Completeness4/5

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

For an 8-parameter tool with no output schema and no annotations, the description supplies the return structure, the addressing rules, the depth limit, and the follow-up path. It is close to complete, though it omits how results are ranked and any error/permission conditions.

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 baseline is 3. The description largely restates what the schema already states about kb_id nesting and the three targeting modes; the genuinely new information (merged extra searches from optional fields) is behavioral rather than per-parameter semantics.

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?

States a specific verb and resource ('Search connected knowledge bases') and immediately characterizes the return payload (snippets, breadcrumbs, toc_path, absolute kb_id). It differentiates from the sibling search by framing itself as the federated variant and names federated_note_html as the downstream reader, so an agent can place it in the workflow without opening a schema.

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?

Gives explicit selection rules: kb_id for one base, kb_ids for several, omit both to fan out, and nesting only up to 3 levels deep. It also spells out the canonical two-call pattern (federated_search -> federated_note_html) that tells the agent when to use this tool rather than reading hub cards directly.

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

All trip2g toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources