stoics_get_readingStoic Scroller. One reading or plan, line by line. The Stoics: daily readings from Marcus Aurelius, Epictetus and Seneca explained line by line, plans, search, and the whole Meditations, Enchiridion and Seneca's letters read a passage at a time
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A reading or plan id from /readings, or a plan name such as "japji" or "The Gita in 18 Days". |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The phrase 'line by line' / 'read a passage at a time' adds a little granularity about the return shape, but nothing about format, error behaviour, or what a plan vs a reading returns.
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?
The text is fragmented and front-loads a restated title rather than the purpose, then closes with a catalogue of the entire product's content ('plans, search, and the whole Meditations, Enchiridion and Seneca's letters'). That closing clause is irrelevant to a one-id getter and dilutes the signal.
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?
Complexity is very low (one required id parameter, full schema coverage, rich annotations, no output schema), so the description is nearly sufficient. However, for an agent the only real open question — what a caller gets back for a reading versus a plan — is left to the ambiguous 'line by line' phrasing.
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?
Schema description coverage is 100% and the schema already explains that id comes from /readings or may be a plan name like 'japji'. The description adds no syntax, format, or lookup detail beyond that, so the baseline 3 applies.
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 is a noun phrase ('One reading or plan, line by line') that largely restates the title, and the rest is app-level marketing listing features (search, whole books, letters) that this single-item getter does not perform. It never states a verb such as 'fetch a single reading by id', so an agent must infer the action from the tool name.
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?
No routing guidance at all against the many siblings (stoics_get_card, stoics_get_today, stoics_read_book, stoics_search_readings). 'One reading or plan' hints at single-item granularity but never says when to use this versus listing, searching, or reading a whole book. The mention of 'search' is especially unhelpful given a dedicated search tool exists.
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.