trip2g

expand

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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
`last`	No	List only this many of the newest subsections instead of all of them. A note that gains a dated section a day has hundreds of them after a year, and reading the whole listing to reach the latest few is the cost this avoids. The summary, total_children and omitted say what was left out, so a bounded listing never reads as a complete one. Bounds that meet or overlap return everything rather than repeating a run.
`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
`first`	No	List only this many of the oldest subsections. Pair it with last to get how a subject started and where it stands now, leaving out the middle; the summary marks the gap where it falls.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026
- removedInput schema / properties / last / items
```
Removed value: -{
-  "type": "string"
-}
```
- addedInput schema / properties / toc_path / items
```
Added value: +{
+  "type": "string"
+}
```

Changed3 schema fields changedSep 29, 2026

addedInput schema / properties / first

Added value: +{
+  "description": "List only this many of the oldest subsections. Pair it with last to get how a subject started and where it stands now, leaving out the middle; the summary marks the gap where it falls.",
+  "type": "number"
+}

addedInput schema / properties / last

Added value: +{
+  "description": "List only this many of the newest subsections instead of all of them. A note that gains a dated section a day has hundreds of them after a year, and reading the whole listing to reach the latest few is the cost this avoids. The summary, total_children and omitted say what was left out, so a bounded listing never reads as a complete one. Bounds that meet or overlap return everything rather than repeating a run.",
+  "items": {
+    "type": "string"
+  },
+  "type": "number"
+}

removedInput schema / properties / toc_path / items
```
Removed value: -{
-  "type": "string"
-}
```

First observedJul 19, 2026

TDQS

A4.1/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 progressive-disclosure semantics, that a leaf section is returned in full (so no second call is needed), that leaf expansion cannot be turned off, and how has_children signals where descending becomes reading. It stops short of covering auth, limits, or error behavior.

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?

Purpose and the canonical call are front-loaded, and most sentences earn their place by clarifying behavior. The closing sentence about not being turnable-off is dense and slightly convoluted, but overall it is well-organized rather than padded.

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 annotations and no output schema, the description supplies the return shape (title, level, path, has_children) and leaf/child semantics. It is largely self-sufficient, with only minor gaps around edge cases and limits.

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 every parameter is already documented, making 3 the baseline. The description reinforces the canonical call (path from note_path, toc_path omission) but adds little syntax or meaning beyond what the schema provides, including for first/last pairing which the schema already explains.

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+resource — walking a note's table of contents level by level — and gives the canonical call shape. It explicitly contrasts itself with note_html ("what note_html gives for that toc_path"), letting an agent separate it from the structure-vs-reading siblings.

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?

It gives clear context on when to omit toc_path (top level) vs pass one (descend into a section), and states that a structure-only client never needs the leaf behavior. It references note_html but doesn't fully spell out when to prefer expand over note_html or search, leaving some inference.

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

All trip2g tools Inspect

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.

expand

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources