get_readingOne reading or plan, line by line. Bhagavad Gita: daily verses, plans, search and verse lookup; whole books from the Library, read a passage at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A reading or plan id from list_readings, or a plan name such as "japji" or "The Gita in 18 Days". |
Changes observed during successful MCP inspections.
Input schema / properties / id / descriptionPrevious value: -"A reading or plan id from /readings, or a plan name such as \"japji\" or \"The Gita in 18 Days\"."New value: +"A reading or plan id from list_readings, or a plan name such as \"japji\" or \"The Gita in 18 Days\"."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered externally. The description adds nothing beyond that — no note on how much content is returned, whether unseen ids error, or what 'line by line' delivery means in practice.
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?
It is short (two sentences), but the second sentence is a feature laundry list for the whole product rather than a statement about this tool, so its words do not fully earn their place. The opening fragment is front-loaded but not informative.
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 read tool with no output schema, the description should at least convey what comes back (a sequence of lines? a passage? a plan structure). 'Line by line' hints at chunking but is never explained, and the tool's relation to get_verse/get_chapter/read_book is left unresolved.
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 coverage is 100% and the single 'id' parameter is fully documented in the schema (id from list_readings, or a plan name like 'japji'). With one parameter and complete schema text, the baseline is 3; the description adds no format or resolution semantics on top.
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 definition never states a retrievable verb+resource clearly; 'One reading or plan, line by line' is a fragment, and the rest enumerates domains ('Bhagavad Gita: daily verses, plans, search and verse lookup; whole books from the Library') that overlap sibling tools like search_readings, get_verse, get_chapter and read_book. An agent cannot tell from this text that the tool fetches a single reading/plan by id and not a search or verse lookup.
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 when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative. The mention of 'search' and 'verse lookup' actually muddies routing rather than clarifying it, since search_readings and get_verse exist as separate tools.
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.