Scroll the Lore

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

Annotations already establish readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context that output is intended 'for voice' and is delivered 'one line at a time', but it does not clarify response format, pagination, or other operational behavior beyond that.

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 duplicates the title and has a double period, wasting the opening position. The second sentence is a long content inventory that does not front-load the tool's actual operation, so the structure is not appropriately focused.

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 three optional parameters, no output schema, and rich annotations, the description still needs to explain what a 'card' is and how get_card differs from siblings such as get_reading and get_today. It instead gives broad domain context, leaving the core tool-specific behavior incomplete.

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%, so the schema fully documents n, date, and reading with defaults and formats. The description adds no parameter-level meaning beyond what the schema already provides, making the baseline 3 appropriate.

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 restates the title verbatim, including the doubled period, so it adds no purpose beyond the tool name. The second sentence lists content domains but never states the action or return type clearly enough to distinguish get_card from siblings like get_reading, get_today, 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 guidance on when to use this tool versus alternatives, and no prerequisites or exclusions are mentioned. The content list suggests broad relevance but does not route the agent among get_reading, get_today, list_readings, or read_book.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond the vague 'line by line' hint — no note on what is returned, whether missing ids error, or how plans vs readings differ.

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 clause is front-loaded and on point, but the second sentence is padded with content-catalogue language ('Greek and Norse myth', 'Theogony, Iliad, Odyssey and Poetic Edda') and a stray 'search' reference that doesn't 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 no output schema, the description carries some of the return-value burden, and 'line by line' gives a partial sense of the response. However, it never explains the shape of the returned reading/plan or how a plan differs from a reading, leaving a gap for a lookup 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?

There is a single parameter with 100% schema description coverage, and the schema already explains that id comes from list_readings or may be a plan name like 'japji'. The description adds nothing about the id format, 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 title/opening phrase 'One reading or plan, line by line' conveys that it fetches a single reading or plan entity, but the verb is implicit and the body drifts into marketing copy about Greek and Norse myth and even mentions 'search', which is a different sibling. An agent can infer retrieval-by-id, but sibling differentiation is weak rather than explicit.

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 and no mention of the obvious alternative list_readings (which the schema itself references) or search_readings/read_book. The description never states when to pick this tool over its siblings.

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

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 fully covered. The description adds only 'same as the app shows today', giving no extra behavioral context such as return shape, ordering, or behavior when the date has no reading.

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 a tight, front-loaded statement of purpose, but the second sentence is app-level marketing ('plans, search, and the whole Theogony, Iliad, Odyssey and Poetic Edda') that says nothing about invoking this specific tool and 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?

For a zero-required-parameter, read-only lookup with full schema coverage and no output schema, the definition is adequate but minimal. It leaves the return structure (what 'line by line' actually yields) and the no-reading-for-date edge case unaddressed.

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 single 'date' parameter already has complete schema documentation including the YYYY-MM-DD format and UTC default. The description adds nothing about the parameter, so the schema does all the work — the baseline for 100% coverage.

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 states a concrete verb+resource: it returns today's reading 'line by line', matching what the app displays. However, it never distinguishes itself from the sibling tools get_reading or list_readings, which a 'today's reading' tool arguably overlaps with.

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 versus get_reading, get_card, or list_readings; the only usage cue is implicit in the name 'get_today'. The second sentence describes the app's overall content rather than when this tool applies.

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

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. The description adds nothing behavioral on top — no return shape, no pagination, no note that the catalog is fixed or how editions differ — and is largely a restatement of the title.

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 scoping phrase is front-loaded, but the second sentence is a dense pile of promotional nouns ('plans, search, and the whole Theogony, Iliad, Odyssey and Poetic Edda') that consumes space without conveying invocation-relevant facts.

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 zero-parameter list tool with no output schema, the description is technically enough to call the tool, but it never says what the agent gets back (a list of book identifiers? titles? reading plans?) or how it relates to the sibling read/search 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, so the baseline is 4. The description correctly implies an unfiltered catalog with no parameter surface, though it doesn't explicitly say no filters are accepted.

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 identifies the resource ('the whole books in the Library that can be read a passage at a time') but never states the verb or what listing returns — it reads as a content blurb rather than a statement of what the tool does. It hints at the domain (Greek/Norse myth, Theogony, Iliad, Odyssey, Poetic Edda), which loosely separates it from read_book or search_readings, but doesn't cleanly distinguish the action.

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 indication of when to call list_books versus list_readings, read_book, get_reading, or search_readings. The words 'plans, search' appear as feature marketing, not as routing guidance, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds content domain but no operational behavior such as pagination, return format, or authentication requirements. It does not contradict 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 description is short but the first sentence is a verbatim repeat of the title, wasting space. The second sentence is a run-on list that mixes content categories and features, though it is not excessively long overall.

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 input parameters and no output schema, the description should clarify what the tool returns. It partially does so by naming curated daily readings, plans, and epic passages, but it remains vague about the return structure and does not distinguish this list tool from its siblings.

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 has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for zero parameters is 4, and the description does not need to compensate for any schema gap.

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 and tool name: 'All curated daily readings and plans' does not give an explicit verb like 'list' or clarify the action. The second sentence enumerates content domains (Greek/Norse myth, epics) but not what the tool actually returns or how it differs from siblings such as search_readings, get_reading, or list_books.

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 alternatives like search_readings or get_today. The mention of 'search' as part of the content is potentially misleading because search is a separate sibling tool.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is low. The description does add one genuine behavioral trait: sequential reading, where the next passage carries into the next chapter. It says nothing about auth, rate limits, or how passage boundaries are determined.

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 duplicates the title, and the second is a comma-spliced list mixing corpora with features that belong to other tools. The material is not front-loaded with a purpose statement, so an agent must parse noise before learning anything useful.

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 four parameters, no output schema, and six sibling tools, the description should at minimum state what is returned and how this differs from get_reading/search_readings. Instead it spends its budget on a duplicate title and a corpus list, leaving the tool's role in the toolkit ambiguous.

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%, so book, section, n and ref are all documented by the schema itself (including the ref override and the Bekhorot Daf Yomi default). The description adds nothing about parameters, and its 'next' phrasing could even be confused with the n parameter. Baseline 3 is correct.

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 name plus 'the whole Theogony, Iliad, Odyssey and Poetic Edda read a passage at a time' lets an agent infer this returns a passage of a text, but the description never states the verb+resource plainly. The lead sentence is a pagination hint rather than a purpose statement, and the list of features ('daily readings explained line by line, plans, search') overlaps sibling tools like search_readings and get_today, muddying rather than sharpening the 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?

'Follow next for the next passage; it carries on into the next chapter' gives some continuation guidance, but there is no statement of when to use read_book versus get_reading, list_readings, get_today or search_readings. No prerequisites or exclusions are given despite six closely related siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful ordering trait (results come back best-match-first) but says nothing about result count, pagination, or what happens with a query that matches nothing. With annotations carrying the safety burden, this is adequate but not rich.

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 and efficient. The second sentence is a long, comma-spliced list of site features ('daily readings explained line by line, plans, search, and the whole Theogony...') that buries the only real added information, the corpus scope, in promotional filler.

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 one-parameter read-only search with no output schema, the definition covers purpose, ranking, and corpus scope, which is close to sufficient. It still omits return shape and empty-result behavior, and gives no hint that a query is the only input, so an agent gets by but not confidently.

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?

With a single parameter at 100% schema description coverage, the schema already explains q as 'Words or a name to search for, for example Loki or Persephone.' The description's corpus list (Theogony, Iliad, Odyssey, Poetic Edda) indirectly hints at what terms may match, but adds no matching syntax, multi-word, or partial-match semantics. Baseline 3 applies when the schema does 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 first sentence states a specific verb and resource (search the curated readings) plus the ranking behavior (best match first), which is more than the bare name conveys. However it never distinguishes itself from the sibling list_readings, so an agent must infer that one searches by query and the other enumerates. The trailing line about Greek/Norse myth reads more like a content blurb than a purpose statement.

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 and no mention of alternatives such as list_readings, get_reading, or read_book. The only signal in the description itself is the word 'search' plus the ranking note, which implies query-driven retrieval but never states the condition for choosing this tool over its siblings.

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