Marcus Aurelius, Epictetus and Seneca a few lines a day, and their whole books to read.
Scored across 7 tools
get_card, get_today, and get_reading all retrieve readings line by line with only minor contextual differences (voice, today's app view, specific reading/plan). An agent could easily confuse these three, leading to misselection. The boundaries are unclear enough that they appear to do nearly the same thing.
All tool names follow a consistent snake_case verb_noun pattern (get_, list_, read_, search_). The verbs are distinct and the naming is predictable throughout. No deviations or mixed conventions.
Seven tools is well-scoped for a Stoic reading application, covering retrieval, listing, and search without bloat. Each tool has a reasonable place in the surface. The count is appropriate for the domain.
The set covers reading retrieval, book listing, plan/reading listing, and search, which are the core operations for this read-only content app. Minor gaps exist, such as jumping directly to a specific book passage or explicit plan detail retrieval, but agents can work around these.
Today's reading one line at a time, for voice.. 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 |
|---|---|---|---|
| n | No | Which card, starting at 1. Defaults to 1. | |
| date | No | Optional day as YYYY-MM-DD. Defaults to today (UTC). | |
| reading | No | A reading or plan id from /readings. Defaults to today's reading. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The only behavioral hint the description adds is 'for voice,' which weakly implies an output format, while the rest of the sentence enumerates unrelated app content. It omits return shape, line pagination, and how defaults (today, first card) resolve.
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 description duplicates the title verbatim (including a doubled period), then spends its longest sentence on catalog copy that does not describe this tool. It is not wasteful in length, but it is poorly front-loaded and the second sentence does not earn its place.
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?
With zero required parameters, an optional n/date/reading trio, and no output schema, the definition should clarify the reading/card granularity and its relationship to get_reading and get_today, which remain ambiguous. Instead it substitutes app-marketing text for the information an agent needs to invoke it correctly.
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% (n, date, and reading are each documented with defaults), so the schema already carries parameter meaning. The description adds nothing about card numbering, date handling, or reading-id sourcing beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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 opening sentence largely restates the title ('Today's reading one line at a time, for voice') rather than stating a distinct verb+resource, and the second sentence catalogs the whole app's content (plans, search, Meditations, Enchiridion, letters) instead of describing what get_card returns. An agent cannot tell from this text how get_card differs from siblings like get_reading or get_today. Only the fragment 'one line at a time' hints at the granularity.
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?
There is no when-to-use, when-not-to-use, or alternative-selection guidance. The words 'plans' and 'search' appear only as content enumeration, not as routing cues, and could even mislead an agent toward search_readings or list_readings. The agent gets no signal for choosing get_card over get_reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds no behavioral context of its own — nothing about lookup failure when an id or plan name doesn't resolve, or what "line by line" output actually looks like.
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, but roughly half the text is author/catalog advertising (Marcus Aurelius, Epictetus, Seneca, Meditations, Enchiridion) that does not help an agent select or invoke the tool. The one useful clause is buried behind the restatement of the title.
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 read tool with no output schema, the minimum is met: the description implies one reading or plan is returned passage by passage. However, it omits anything about id resolution, errors, or how a plan name maps to a reading set, and no output schema compensates.
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 schema itself documents the single `id` parameter, including example values ("japji", "The Gita in 18 Days"). The description contributes no syntax or format detail beyond the schema, so the baseline of 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 largely restates the title ("One reading or plan, line by line") and then fills the rest with content marketing about Stoic authors. It never states a clear verb like "retrieve/get a reading by id," and it does not distinguish this tool from siblings such as list_readings, search_readings, or read_book.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The passing reference to "plans, search" is confusing rather than directive, given that search_readings and list_readings are siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's reading, line by line (same as the app shows today). 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 |
|---|---|---|---|
| date | No | Optional day as YYYY-MM-DD. Defaults to today (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds modest value by indicating the content is presented 'line by line' and matches the app's today view, conveying something about output structure. It says nothing about caching, timezone edge cases, or failure behavior, so it does not go far beyond the annotations.
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 first sentence merely restates the title verbatim, and the second sentence is product-positioning copy that lists unrelated app capabilities (plans, search, whole books/letters), potentially misleading the agent toward sibling tools. That copy does not earn its place in a single-parameter read tool's description.
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 low-complexity, read-only tool with one fully documented optional parameter and no output schema, the definition is minimally adequate. It hints at output shape via 'line by line' but omits the date parameter entirely and offers no selection guidance. The trailing app-level pitch fills no real gap.
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%: the single optional 'date' parameter is documented in the schema as YYYY-MM-DD defaulting to today (UTC). The description never mentions the date parameter or its default, so it adds no meaning beyond the schema. Baseline 3 applies when the schema does all the work.
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 opening clause 'Today's reading, line by line' identifies the resource and its temporal scope, so an agent can infer it returns the current day's Stoic reading. However, it isn't a clear verb+resource statement and does nothing to distinguish it from siblings like get_reading or list_readings. The second sentence largely describes the broader app rather than this tool, muddying rather than sharpening purpose.
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?
There is no statement of when to use this tool versus get_reading, list_readings, or search_readings, nor any prerequisite or exclusion. 'Same as the app shows today' is the only contextual cue and it is descriptive, not prescriptive. An agent gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole books in the Library that can be read a passage at a time. 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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and a closed-world scope, so the safety profile is covered by structured data. The description adds nothing behavioral beyond that – no note on return shape, ordering, or pagination – leaving it purely restated marketing text.
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 first sentence is front-loaded but is a verbatim echo of the title; the second sentence is promotional filler that repeats 'read a passage at a time' and lists content items irrelevant to invoking the tool. Neither sentence earns its place for a zero-argument list operation.
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 trivial zero-parameter, read-only listing tool whose safety profile is fully covered by annotations, the description is minimally adequate at naming the resource. It still omits the core fact that it returns the book collection and how it relates to the sibling listing/reading tools.
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 tool takes zero parameters and schema coverage is 100% (empty object), so there is no parameter semantics for the description to carry. Baseline 4 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 never states a verb like 'list' or 'retrieve'; it merely restates the title ('The whole books in the Library that can be read a passage at a time') and then describes the app's content. An agent cannot tell from the text that this tool returns the catalog of books, nor how it differs from the sibling list_readings.
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?
There is no when-to-use guidance, no mention of alternatives among get_reading, list_readings, read_book, or search_readings, and no conditions for selecting this tool. The second sentence is product copy about The Stoics content, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All curated daily readings and plans. 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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context at all - nothing about result size, pagination, ordering or what a 'plan' versus a 'reading' is.
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 first sentence is short and front-loaded, but the second sentence is catalogue-style marketing copy ('explained line by line', 'read a passage at a time') that consumes roughly two-thirds of the text without conveying callable information.
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?
With no parameters, no output schema and rich safety annotations, little is strictly required, and the description does convey that readings and plans are returned. It still leaves the boundary with the get_* and search_* siblings unstated, which is the main thing an agent needs here.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 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 opening clause 'All curated daily readings and plans' identifies the resource being listed, but no verb is stated and the rest of the text is promotional content description rather than function. It also fails to distinguish itself from siblings like get_reading, get_today and search_readings, even mentioning 'search' which is a separate tool.
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?
There is no guidance on when to use this tool versus get_reading, get_today, list_books or search_readings. The stray mention of 'search' as a feature could actively steer an agent toward the wrong expectation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow next for the next passage; it carries on into the next chapter. 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 |
|---|---|---|---|
| n | No | Passage within the section, starting at 1. | |
| ref | No | Optional: jump straight to a passage by its reference, for example "Havamal 139", "Meditations 4.3", "Gita 2.47", "Iliad 1.5" or "10b". Overrides section and n. | |
| book | Yes | Book id or title from /books, for example meditations, enchiridion. | |
| section | No | Chapter, book, poem, letter or daf to start at, as listed in the book (for example 5, "chapter 2", "havamal", or 10b for the second side of a daf). Defaults to the beginning; Bekhorot defaults to today's Daf Yomi page while the cycle is in it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world model, so the safety profile is covered. The description adds that reading proceeds sequentially and 'carries on into the next chapter', which is mild extra behavioral context, but says nothing about permissions, rate limits, or return shape.
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 front-loaded with a navigation aside instead of the tool's purpose, and the second sentence is an unstructured run-on list mixing content, plans, and search. Little of it earns its place as tool-selection guidance.
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 convey what is returned and how it relates to the sibling reading tools; instead it offers a vague 'read a passage at a time' and a confusing content inventory. The domain is hinted at but the agent's needs are not met.
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 itself documents n, ref, book, and section with examples, so the baseline of 3 applies. The description contributes no additional parameter meaning beyond what the schema already states.
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 first sentence is about a navigation quirk ('Follow next for the next passage') rather than what the tool does, and the second is a run-on content list that name-drops 'search' and 'plans' – which are sibling tools – without stating a clear verb+resource. An agent cannot cleanly distinguish read_book from get_reading or search_readings based on this text.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named as a routing target. Mentioning 'search' and 'plans' inside the content list muddies rather than clarifies which sibling to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the curated readings, best match first. 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 |
|---|---|---|---|
| q | Yes | Words to search for, for example anger or death. |
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 by structured data. The description's only added behavioral signal is 'best match first,' which usefully reveals that results are relevance-ordered rather than chronological. It does not mention pagination, result limits, or match semantics.
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 key fact ('best match first') is front-loaded in the first sentence, which is good. The second sentence is a rambling, grammatically broken run-on that mixes corpus enumeration with stray words ('plans, search, ... read a passage at a time') and does little to help invocation.
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 simple one-parameter search tool with no output schema and full annotation coverage, the description supplies the essential what-and-how. It tells the agent the corpus is Stoic readings (Marcus Aurelius, Epictetus, Seneca), which is the main missing piece structured fields cannot convey. Return format and pagination are absent but not critical here.
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?
There is a single parameter with 100% schema description coverage, so the schema already documents 'q' with an example ('anger or death'). The description adds no syntax, matching mode, or query-format guidance beyond the schema, so the baseline of 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 first sentence states a specific verb and resource ('Search the curated readings') plus a ranking behavior ('best match first'), so the agent knows exactly what the tool does. However, it never distinguishes itself from siblings like list_readings or get_reading, which are plausible alternatives. The second sentence drifts into corpus description rather than clarifying the core purpose.
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?
There is no guidance on when to use this tool versus list_readings, get_reading, or read_book. 'Best match first' hints that results are relevance-ranked, but no condition or alternative is named. The agent is left to infer that this is the keyword-search entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_cardget_readingget_todaylist_bookslist_readingsread_booksearch_readingsA Greek or Norse myth a day, explained, and Homer, Hesiod and the Poetic Edda to read.
Complete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
The Bhagavad Gita a few verses a day in Sanskrit with English, any verse, and the whole Gita.
Brain dump, routines, task planning, focus, and instant thought retrieval
Add one secure layer between your agents and this server.
