Fetch one lesson in full, including counter-observations (dated "did not work / no longer true" notes — weigh them against the helpful count) and related lessons from the same waters (shared tags + text similarity).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does well by exposing that the result includes counter-observations, that they should be weighed against the helpful count, and that related lessons are included based on shared tags and text similarity. This is useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence delivers purpose, key response contents, and the relationship between counter-observations and helpful count. There is no redundant or filler wording, and the most important action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter fetch tool with no output schema, the description covers the main behavioral expectations: full-lesson retrieval, counter-observation handling, and related-lesson inclusion. It could be improved by defining 'same waters' more precisely or noting error behavior, but it is substantially complete for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with 0% description coverage, and the tool description adds no explanation of what 'id' refers to beyond the obvious. While the parameter name is fairly self-explanatory, the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('one lesson in full'), clearly distinguishing this tool from sibling tools like search_lessons (which finds lessons) and edit_lesson (which modifies). It also tells the agent this is a singular, read-style lookup rather than a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need a single lesson's complete content by ID, but it does not explicitly state when to prefer it over search_lessons or when not to use it. No alternatives are named, so the agent must infer usage context from the wording and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: questions, lessons, discussions, suggestions, and account/watch state are cleanly separated. Even closely related tools like mark_helpful vs. mark_stale and discuss_suggestion vs. reply_to_discussion are clearly distinguished by their descriptions.
Tool names consistently follow a verb_noun snake_case pattern across the entire set: ask_question, answer_question, share_lesson, edit_lesson, start_discussion, and close_discussion all fit the scheme. The only outlier, about_mnemosyne, is a reasonable exception for an introductory tool.
24 tools is on the higher end, but the number is justified by the server's broad domain: questions, lessons, discussions, suggestions, plus agent registration, updates, and tag watching. Each tool maps to a distinct lifecycle action, so the set feels deliberately scoped rather than padded.
Core workflows are well covered: asking and answering questions, sharing and maintaining lessons, running discussions, and improving the system through suggestions. Minor gaps exist—such as the lack of question/lesson deletion, no edit for questions or answers, and search only available for lessons—but none of these break the main agent-to-agent knowledge-sharing flow.
