A
licenseNot graded
qualityB
maintenanceTurns markdown note directories into an MCP knowledge assistant server, enabling hybrid search, explanations, quizzes, and comparisons for any MCP-compatible AI tool.
MIT
trip2g
Server Details
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- trip2g/trip2g
- GitHub Stars
- 37
- Server Listing
- trip2g
Available Tools
11 toolsexpandAInspect
Walk a note's table of contents level by level (progressive disclosure). Canonical call: expand(path=<result.note_path>, toc_path=[...]) — copy path verbatim from a search result's note_path field. Returns the direct children of a TOC node: omit toc_path (or pass []) for the top-level sections, or pass a toc_path to list that section's subsections. Each child has title, level, path, and has_children. A section with subsections lists them; a section without subsections is returned in full (what note_html gives for that toc_path, plus section_html in the payload), so no second call is needed to read a leaf. This cannot be turned off, and a client that wants only structure never triggers it: has_children on each listed child says where descending would turn into reading.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id. Prefer path | |
| href | No | String note href, copied verbatim from a search result's href field | |
| path | No | String note path, e.g. "concepts/maska-i-glubina.md" — copy verbatim from a search result's note_path field. The default, preferred way to reference a note | |
| note_id | No | Same as pid: non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id. Prefer path | |
| toc_path | No | Breadcrumb path to the node to expand, e.g. ["Chapter 1"]. Omit or [] for the top level. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries full behavioral burden. It clearly discloses progressive-disclosure semantics, the leaf-section full-content behavior with section_html, and the 'cannot be turned off' nuance with has_children as the guide to avoid unintended reads. This is exactly the behavioral detail an agent needs.
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 dense but every sentence earns its place: purpose, canonical call, return shape, leaf behavior, and the has_children guard. It is front-loaded with the purpose and invocation pattern.
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?
For a tool with five parameters, zero required, no output schema, and no annotations, the description explains the return fields, handles the optional toc_path cases, and addresses the leaf-versus-structure edge case. Nothing critical for correct invocation is missing.
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%, and the schema already states the 'copy verbatim' rule and 'prefer path' for the identifier parameters. The description adds a canonical call pattern and clarifies toc_path usage, but does not introduce fundamentally new parameter semantics beyond the schema. Hence the baseline score of 3 is appropriate.
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 ('walk') and resource ('a note's table of contents') and describes the progressive-disclosure behavior. The return behavior (direct children of a TOC node) clearly distinguishes it from siblings like note_html (rendered content) and search (finding notes).
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?
Provides a canonical call template, instructs to copy path verbatim from a search result's note_path, and explicitly explains when to omit toc_path (top level) vs pass it (subsection). It also tells clients how to avoid triggering full leaf reads via has_children, and contrast with note_html's output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
federated_expandAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) remote note id, copied verbatim from a federated_search result's note_id field. Prefer path | |
| href | No | String remote note href, copied verbatim from a federated_search result's href field | |
| path | No | String remote note path, copied verbatim from a federated_search result's note_path field | |
| kb_id | Yes | Target 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_id | No | Same remote note id as pid, but as a STRING (uint64) — stringify the federated_search result's note_id field. Prefer path | |
| toc_path | No | Breadcrumb path to the node to expand. Omit or [] for the top level. |
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.
federated_instructionsAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kb_id | Yes | Target knowledge base id; nested bases use '/' (e.g. "philosophers/nietzsche" routes through the 'philosophers' peer, recursively) |
TDQS
A4/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
federated_note_htmlAInspect
Read a remote note inside a connected knowledge base. Canonical call, copying fields verbatim from a federated_search result: 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 there, not hub cards. federated_note_html(kb_id=..., match_id=<match.match_id>) reads just the focused chunk around a hit. Only pass pid/note_id if you already copied that exact id from a result. path is a string like "concepts/x.md"; match_id is "p:c"; a value like ":" or "/hub/goethe.md" is a PATH, not a note_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) remote note id, copied verbatim from a federated_search result's note_id field. Not a path, slug, or match_id. Prefer path or match_id | |
| href | No | String remote note href or absolute URL, copied verbatim from a federated_search result's href field | |
| path | No | String remote note path, copied verbatim from a federated_search result's note_path field | |
| kb_id | Yes | Target 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_id | No | Same remote note id as pid, but as a STRING (uint64) — stringify the federated_search result's note_id field. Not a path, slug, or match_id. Prefer path or match_id | |
| match_id | No | String chunk id of the form "p<pid>:c<chunk>", copied verbatim from a remote search match's match_id field; alone it is enough to resolve the note | |
| toc_path | No | Breadcrumb path to a specific section, e.g. ["Chapter 1", "Introduction"]. Use toc_path from a federated_search match, or a child path from federated_expand. Wins over match_id when both are given. Without either the whole note comes back. |
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 full burden, and it discloses important behavioral traits: federation nesting is limited to 3 levels, path format expectations, match_id format, and the precedence rule where toc_path wins over match_id. It also indicates that without toc_path or match_id, the whole note returns. Missing are error handling or auth requirements, but the provided behavior is substantial.
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 long but densely packed with useful information. It follows a logical flow: purpose, canonical call pattern, match_id alternative, pid/note_id caveat, and format clarifications. Every sentence contributes value, though it could be tightened slightly; the length is justified by the complexity of the federation context.
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 a 7-parameter tool with no output schema and no annotations, the description covers the essential usage semantics well. It explains the critical distinctions between parameter types and their precedence. The main gap is the lack of information about the return value structure or error cases, but given the focus on invocation, this is a minor omission.
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 documents all 7 parameters (100% coverage), so the baseline is 3. The description adds significant extra meaning: it explains the relationships between parameters (path vs match_id, toc_path precedence), gives format examples, and clarifies which parameters are preferred. This goes well beyond schema descriptions.
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 the tool's purpose: reading a remote note inside a connected knowledge base. It explicitly positions itself as the canonical call following federated_search and distinguishes between reading a full note versus a focused chunk via match_id. This differentiates it from sibling tools like federated_search and note_html.
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?
The description gives precise usage guidance: it shows the exact call pattern from federated_search results, explains when to use match_id vs path vs pid/note_id, and even clarifies ambiguous cases like a value ':' being a path not a note_id. It provides concrete examples of valid formats, making it easy for an agent to choose the right parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
federated_searchAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kb_id | No | Target 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. | |
| limit | No | Max number of results to return (default 6) | |
| query | Yes | Search query | |
| kb_ids | No | Target knowledge base ids; each accepts the same nested 'peer/base' form as kb_id | |
| detail_limit | No | How many results include full snippet matches; results beyond this are returned as lightweight previews (title, path, score) to save context (default 3) |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavioral traits. It explains that returns include snippets with breadcrumbs, toc_path, and kb_id; that nesting is recursive up to 3 levels deep; and that omitting both kb_id and kb_ids fans out across all bases. The canonical call pattern further clarifies expected usage.
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 a single, well-structured paragraph. It front-loads the core purpose and efficiently covers return format, parameter usage, nesting rules, and an example. Every sentence adds value, though the density might benefit from slight reordering.
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?
Given the complexity of federated search and the absence of an output schema, the description is remarkably complete. It explains return values, nesting depth limits, fan-out behavior, and provides a canonical call pattern. It addresses all key aspects needed for correct invocation.
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?
Although schema coverage is 100%, the description adds significant meaning beyond the schema by explaining the '/' nesting semantics for kb_id, the relationship between kb_id and kb_ids, and the context of detail_limit producing lightweight previews. This enhances the agent's understanding of how parameters interact.
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 the verb ('search') and the resource ('connected knowledge bases'). It distinguishes this tool from its sibling 'search' by emphasizing the federated nature and providing a canonical call pattern. The return format (snippets with breadcrumbs, toc_path, kb_id) is explicitly described.
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 provides explicit guidance on parameter usage: pass kb_id for one base, kb_ids for selected bases, or omit both to fan out. It explains nesting with '/' and gives a canonical call example. While it doesn't explicitly exclude scenarios (e.g., when to use plain 'search' instead), the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
federated_similarAInspect
Find remote notes similar to a known note reference inside a connected knowledge base. Preferred: path (a federated_search result's note_path field).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) remote note id, copied verbatim from a federated_search result's note_id field. Prefer path | |
| href | No | String remote note href, copied verbatim from a federated_search result's href field | |
| path | No | String remote note path, copied verbatim from a federated_search result's note_path field | |
| kb_id | Yes | Target 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. | |
| limit | No | Max number of results | |
| note_id | No | Same remote note id as pid, but as a STRING (uint64) — stringify the federated_search result's note_id field. Prefer path |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description adequately conveys it is a read-only similarity operation on remote notes. Does not detail algorithm or side effects, but suffices for a straightforward tool.
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?
One sentence with a clarifying fragment, no unnecessary words. Action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks mention of return format or behavior for multiple parameters provided. Sufficient for basic understanding but could elaborate on expected output and edge cases.
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 covers parameter descriptions (100% coverage). Description adds value by specifying preference for 'path' and instructing to copy from federated_search result fields, aiding parameter selection.
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?
Description clearly states verb 'Find... similar to a known note reference' and specifies resource 'remote notes' within a 'connected knowledge base'. It distinguishes itself from sibling 'similar' (local) and 'federated_search' (search).
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?
Implicitly suggests using 'path' from federated_search results, but does not explicitly state when to use this tool vs alternatives like 'similar' or conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instructionsCInspect
Full tool reference for the trip2g documentation base
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, what data it returns, or if any side effects occur. The simple nature of the tool (no parameters) partly mitigates this, but transparency is still minimal.
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 a single sentence with no wasted words. It is front-loaded and concise, though it could benefit from a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should explain what 'full tool reference' entails (e.g., returns a list of tools, descriptions, or instructions). The current description is too vague for an agent to understand its exact utility.
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?
The input schema has no parameters (coverage 100%), so the baseline is 3. The description adds no extra semantic information about parameters, but since there are none, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full tool reference for the trip2g documentation base' indicates the tool provides a comprehensive reference or instructions about the documentation base, but lacks a specific verb (e.g., 'list', 'retrieve') and does not clearly distinguish it from sibling tools like 'federated_instructions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'expand', 'search', or 'federated_instructions'. There is no mention of preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
note_htmlAInspect
Read a note. Canonical calls, copying fields verbatim from a search result: search(query) -> note_html(path=<result.note_path>) reads the whole note; search(query) -> note_html(match_id=<match.match_id>) reads just the focused chunk around a hit (cheaper, targeted); expand(path=<result.note_path>, toc_path=[...]) -> note_html(path=<result.note_path>, toc_path=[...]) reads one exact section. Only pass pid/note_id if you already copied that exact integer from a result's note_id field — never invent one. path is a string like "concepts/x.md"; match_id is "p:c"; a value like ":" or "/hub/goethe.md" is a PATH, not a note_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id — a value like ":" or "/hub/goethe.md" is a path, not a note id. Prefer path or match_id | |
| href | No | String note href or absolute URL, copied verbatim from a search result's href field | |
| path | No | String note path, e.g. "concepts/maska-i-glubina.md" — copy verbatim from a search result's note_path field. The default, preferred way to open a note | |
| note_id | No | Same as pid: non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id. Prefer path or match_id | |
| match_id | No | String chunk id of the form "p<pid>:c<chunk>" (e.g. "p32:c4"), copied verbatim from a search match's match_id field. Alone it is enough to resolve the note and reads a focused window around that hit | |
| toc_path | No | Breadcrumb path to a specific section, e.g. ["Chapter 1", "Introduction"]. Use toc_path from a search match, or a child path from expand. Wins over match_id when both are given: match_id is only used when toc_path is absent. | |
| context_words | No | Optional future hint for expanding focused reads |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool reads either the entire note or a focused chunk, that toc_path wins over match_id, and that pid/note_id must not be invented. It does not state the return format beyond implying HTML content, but the name and call semantics give adequate behavioral context for an agent.
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 dense but efficient: every sentence contributes either a calling pattern or a precision rule. The leading 'Read a note' front-loads the essential purpose. It is somewhat long-winded compared to the cleanest case and repeats the verbatim-source rule across pid/note_id, but there is no filler.
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?
For a 7-parameter tool with no output schema, it covers all relevant usage branches: full‑note read, focused chunk read, exact-section read, and the override semantics between parameters. It also tells the agent exactly which identifiers are invalid. No critical calling or disambiguation information 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 the baseline is 3. The description adds real value beyond the schema by specifying the verification source for each identifier (e.g., 'copy verbatim from result note_id'), giving concrete path format examples, and defining the match_id pattern. It clarifies precedence (− toc_path wins over match_id) and explains the practical trade-off of match_id reads.
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 opens with 'Read a note' and then enumerates three canonical calling patterns tied to concrete resources (whole note, focused chunk, exact section). This clearly states the verb, the resource, and how it differs from siblings like expand, search and federated_note_html, leaving no ambiguity about what the tool does.
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?
The description gives explicit when-to-use guidance: search -> note_html(path=...) for the whole note, search -> note_html(match_id=...) for a cheaper focused read, and expand -> note_html(path=..., toc_path=...) for a single section. It also names when NOT to pass pid/note_id unless copied verbatim, and distinguishes path vs match_id vs note_id formats. This fully routes the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Search notes by query. Returns snippets with a heading breadcrumb (title > section > subsection) that locates the approximate section, plus a precise toc_path per match. Each result carries note_path (string) and note_id (integer); each match carries match_id (string, form "p:c"). Drill-down workflow: 1) search to find the approximate section via the breadcrumb; 2) call note_html(path=<result.note_path>, toc_path=[...]) to read the matched section, or expand(path=<result.note_path>, toc_path=[...]) to navigate the note's structure level by level; 3) note_html(path=<result.note_path>, match_id=<match.match_id>) for a focused chunk window. Each match also carries section_url — a link straight to that heading, for citing the section rather than the whole note.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of results to return (default 6) | |
| query | Yes | Search query | |
| detail_limit | No | How many results include full snippet matches; results beyond this are returned as lightweight previews (title, path, score) to save context (default 3) |
TDQS
A4.7/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 of transparency. It discloses exact return fields, the match_id format, the breadcrumb behavior, the lightweight preview behavior via schema context, and the coarse-to-fine matching workflow. This is unusually detailed and useful.
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 dense but every sentence earns its place: it states the purpose, defines result/match structures, and provides a compact numbered drill-down workflow with code-style signatures. It is well-structured and front-loaded.
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?
Even without an output schema, the description gives enough information about return shapes, field types, and exact next steps for the agent to invoke the tool and continue the workflow. It also names note_html and expand as the natural follow-up tools, making the surrounding context clear.
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 coverage is 100% and the parameter descriptions are clear, so the baseline is 3. The description adds workflow context around returned fields but does not substantially extend the meaning of the input parameters themselves.
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 opens with 'Search notes by query'—a clear verb and resource. It then distinguishes search from the drill-down sibling tools by framing it as the discovery step that returns breadcrumbs, toc_path, and match identifiers.
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?
The description provides an explicit numbered drill-down workflow, telling the agent when to use search, when to call note_html, when to use expand, and mentioning section_url as an alternative for citing. This gives strong guidance on how the tool fits relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
similarBInspect
Find related notes from a known note reference. Preferred: path (a search result's note_path field). Use this after opening a promising note when you need nearby context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | Non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id — a value like ":" or "/hub/goethe.md" is a path, not a note id. Prefer path | |
| href | No | String note href, copied verbatim from a search result's href field | |
| path | No | String note path, e.g. "concepts/maska-i-glubina.md" — copy verbatim from a search result's note_path field. The default, preferred way to reference a note | |
| limit | No | Max number of results (default 10) | |
| note_id | No | Same as pid: non-negative integer (uint64) note id, copied verbatim from a search result's note_id field. Not a path, slug, or match_id. Prefer path |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full responsibility. It states 'Find related notes' but does not clarify whether it is read-only, what 'related' means, or any side effects. More explicit safety or behavioral details are needed.
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?
Two concise sentences that immediately convey purpose and preferred usage. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description lacks details about return format, behavior (e.g., ordering, pagination), and what constitutes a 'related note'. More context is needed for a complete understanding.
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 coverage is 100% with detailed parameter descriptions. The tool description adds only the preference for 'path' over other identifiers, which is minor added value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds related notes from a known note reference, with a specific verb and resource. It does not explicitly contrast with siblings like 'expand' or 'search', but the function is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions prefering the 'path' parameter and suggests using it after opening a promising note for nearby context. This gives implied usage guidance but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikiCInspect
Wiki Knowledge Base Instructions
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
C2/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool returns instructions, performs a read-only operation, or has side effects. The description carries the full burden but fails to reveal any meaningful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of only five words and does not earn its place by providing useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description fails to explain what the tool returns, how it behaves, or how it relates to sibling tools. The tool appears intended to provide instructions, but the description is completely inadequate for an agent to invoke it correctly.
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 has no parameters, so the description is not required to explain parameter semantics. Per the rules, a tool with 0 parameters receives a baseline of 4, and the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wiki Knowledge Base Instructions' is vague and tautological, essentially restating the tool name without specifying a clear verb or action. It does not differentiate the tool from siblings like 'instructions' or 'search', leaving the agent uncertain about what this tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as 'federated_instructions' or 'search'. The description provides no context for selecting this tool in a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
federated_note_html1 field changed- changed
Input schema / properties / toc_path / descriptionPrevious value: -"Breadcrumb path to a specific section, e.g. [\"Chapter 1\", \"Introduction\"]. Use toc_path from a federated_search match, or a child path from federated_expand. Without it the whole note comes back."New value: +"Breadcrumb path to a specific section, e.g. [\"Chapter 1\", \"Introduction\"]. Use toc_path from a federated_search match, or a child path from federated_expand. Wins over match_id when both are given. Without either the whole note comes back."
- Changed
note_html1 field changed- changed
Input schema / properties / toc_path / descriptionPrevious value: -"Breadcrumb path to a specific section, e.g. [\"Chapter 1\", \"Introduction\"]. Use toc_path from a search match, or a child path from expand."New value: +"Breadcrumb path to a specific section, e.g. [\"Chapter 1\", \"Introduction\"]. Use toc_path from a search match, or a child path from expand. Wins over match_id when both are given: match_id is only used when toc_path is absent."
1 tool update
- Changed
federated_note_html1 field changed- added
Input schema / properties / toc_pathAdded value: +{ + "description": "Breadcrumb path to a specific section, e.g. [\"Chapter 1\", \"Introduction\"]. Use toc_path from a federated_search match, or a child path from federated_expand. Without it the whole note comes back.", + "items": { + "type": "string" + }, + "type": "array" +}
1 tool update
- Added
wiki
1 tool update
- Removed
wiki
11 tool updates
- First observed
expand - First observed
federated_expand - First observed
federated_instructions - First observed
federated_note_html - First observed
federated_search - First observed
federated_similar - First observed
instructions - First observed
note_html - First observed
search - First observed
similar - First observed
wiki
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
MCP server for querying Forkast documentation
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Related MCP Servers
- AlicenseBqualityCmaintenanceEnables hybrid dense and BM25 search over a markdown vault, with tools for reading, writing, grepping, and managing notes through any MCP-compatible client.12MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first MCP server for retrieval over markdown wikilink vaults, offering hybrid vector+lexical search, note reading, neighbor expansion, and recent activity tracking with fully local embeddings and no network egress.MIT
- AlicenseAqualityBmaintenanceLocal MCP server for querying and maintaining a Markdown vault. Provides full-text search, backlinks, note retrieval, and optional confined write tools, without sending the whole vault to the client context.20Apache 2.0
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.