Skip to main content
Glama

trip2g

by io.github.trip2g

note_html

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pidNoNon-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
hrefNoString note href or absolute URL, copied verbatim from a search result's href field
pathNoString 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_idNoSame 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_idNoString 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_pathNoBreadcrumb 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_wordsNoOptional future hint for expanding focused reads

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / toc_path / description
      Previous 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."
  2. First observed

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.

All trip2g toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources