Skip to main content
Glama
Sign In
mmm-mcp-server

mmm-mcp-server

by nhorie-canal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

read_document

Reads the Markdown content of a mind map document element using its mapId and documentId, returning updateTime for safe edits; read-only, so changes require a separate update.

Instructions

マップのMD文書の要素の中身(Markdown)を読む。読むだけで、書き込みはできない(書き換えはupdate_document)。結果のupdateTimeは、update_documentのbaseUpdateTimeにそのまま渡す。documentIdは、list_elementsが返す文書の要素のdocument.documentId。list_elementsと同じく、まずconfirmedを付けずに呼ぶ。アプリでAIからの読み取りを「常に許可」にしたマップは、そのまま実データを返す。それ以外のマップは、実データの代わりに確認を促すメッセージだけを返すので、そのときに限りユーザーに直接確認してからconfirmed: trueで呼び直すこと(同じマップでlist_elementsの確認が済んでいれば、改めて確認する必要はない)。アプリ側での直接の編集はこのツールを呼ぶまで反映されないため、記憶に頼らず必ず呼び直すこと。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mapId": "<mapId>",
      "documentId": "<documentId>"
    },
    "name": "read_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
mapIdYeslist_mapsで得たマップのID
confirmedNo最初は付けない。確認を促すメッセージが返ったときだけ、ユーザー本人に直接「中身を確認してよいか」と尋ね、同意を得てからtrueを付けて呼び直す。確認前にtrueを付けてはならない。
documentIdYeslist_elementsで得た、文書の要素のdocument.documentId

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does it well: it declares the read-only nature, the two-mode permission behavior (always-allow maps return real data, others return a confirmation prompt), the confirmation gate on `confirmed`, and the staleness caveat that app-side edits only appear after a fresh call. It stops short of describing failure modes or response shape beyond `updateTime`, keeping it at a strong 4 rather than 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?

It is front-loaded with the purpose and read-only constraint before the operational details, and nearly every sentence carries a distinct rule. It is denser than ideal, with parenthetical asides, but no sentence is 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 3-parameter read tool with no annotations and no output schema, the description covers everything an agent needs: what it returns (Markdown body plus updateTime), how the confirmation flow works, and how the result feeds update_document. Nothing material is left to inference.

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 would be 3, but the description adds chaining semantics the schema does not: `documentId` provenance from list_elements' document element, and the contract that the returned `updateTime` feeds directly into update_document's `baseUpdateTime`. That cross-tool linkage is real added meaning beyond the field-level 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?

It names a specific verb and resource (reading the Markdown content of a map's MD document element) and immediately separates the tool from its write counterpart by naming update_document. An agent can distinguish it from edit_element or update_document without opening any 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?

It gives explicit routing rules: read here, rewrite with update_document, take documentId from list_elements, and start without `confirmed`. It also states a genuine exclusion — that no new confirmation is needed if list_elements was already confirmed for the same map — plus a rule to never rely on memory and re-fetch.

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

Deploy Server

Other Tools