Gita Scroller

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 covered. The description adds only 'one line at a time, for voice', which hints at output granularity and channel but says nothing about pagination, ordering, or what the card content 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 description duplicates the title verbatim (including a stray double period), then appends a run-on sentence mixing unrelated app features. It is not front-loaded with tool-specific information and wastes its first clause on repetition.

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 0 required params, rich annotations, and full schema coverage, the structured data does most of the work, but the remaining ambiguity of what a 'card' returns and how it differs from get_today/get_reading is unresolved and no output schema compensates. The description leaves the agent unable to confidently pick this tool over 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?

Schema description coverage is 100%, so 'n', 'date', and 'reading' are fully documented in the schema with defaults and formats. The description adds no additional meaning about these parameters (e.g., how 'n' interacts with a reading), 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 first sentence is a near-verbatim restatement of the title ('Today's reading one line at a time, for voice..'), and the second is app-level marketing copy ('Bhagavad Gita: daily verses, plans, search and verse lookup; whole books from the Library') that describes the whole product rather than this tool. It never explains what a 'card' actually is, so the agent cannot clearly distinguish get_card from get_today, get_reading, or get_verse.

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 comparison against the many similarly-named siblings (get_today, get_reading, get_verse, get_chapter). The mention of 'search and verse lookup' hints at neighboring functionality but never states which tool to use for which need.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds real value by disclosing the composition of the returned content (Sanskrit plus transliteration plus English), which no annotation or schema conveys. It stops short of describing pagination or size limits, but for a single-chapter fetch that is a minor omission.

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 definition is short and the relevant content is front-loaded, but the trailing sentence about daily verses, plans, search and the Library does not earn its place in this tool's description and blurs the reader's focus.

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 usefully signals what the chapter result contains, and the safety/identity profile is covered by annotations. For a one-parameter read tool this is nearly complete, though it omits the size/format expectations of a full chapter.

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%, with 'Chapter number, 1 to 18.' fully documenting the sole required parameter. The description adds nothing beyond that baseline, so a 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 first sentence states a specific resource (a whole chapter) and its payload (Sanskrit, transliteration, English), which an agent can distinguish from get_verse's single-verse scope. The second sentence, however, reads as an app-level feature list rather than a statement about this tool, diluting the 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 explicit when-to-use guidance and no named alternative, even though get_verse is the obvious sibling for single-verse retrieval. The fragment 'verse lookup' is ambiguous domain color rather than a routing instruction, so the agent must infer when chapter-level retrieval is appropriate.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond the title phrase "line by line" — no indication of what the response looks like, whether a plan expands into multiple lines, or what happens for an unknown id. A single required id makes authorization/rate-limit notes less critical, but nothing extra is disclosed.

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?

Two sentences where the first duplicates the title outright and the second is a semicolon-and-comma clause salad mixing unrelated capabilities (daily verses, plans, search, verse lookup, library books). Nothing is front-loaded usefully and the sentence does not earn its space.

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?

There is no output schema, so the description must at least sketch what comes back and how a plan versus a reading differs — it does neither, offering only the vague "line by line". Combined with the missing distinction from the eight sibling tools taking similar identifiers, the definition is not complete enough to call the tool 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?

Schema description coverage is 100% for the single parameter, which already explains that id comes from /readings or is a plan name like "japji". The description contributes no additional syntax, format or lookup semantics, 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 first sentence is a verbatim restatement of the tool title ("One reading or plan, line by line") and never says the tool retrieves/fetches a single reading or plan by id. The second sentence then lists domain features (daily verses, search, verse lookup, whole books) that belong to sibling tools like search_readings, get_verse and read_book, muddying rather than clarifying what this tool does. No differentiation from siblings is achieved.

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 statement and no routing rule against alternatives. Naming "search and verse lookup" and "whole books from the Library" hints at sibling capabilities but is never framed as "use X instead", so the agent gets no signal for choosing get_reading over search_readings, get_verse, get_chapter 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, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds that the output mirrors what the app displays today, which is mildly useful context, but says nothing about the shape of the reading (verses? cards? passages?) or handling of a missing day.

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 and front-loads the actual purpose, which is good. But roughly half of it is an app-level feature blurb ('daily verses, plans, search and verse lookup; whole books from the Library') that does not earn its place in a single-tool definition and reads as noise.

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 tool with no output schema and full annotation coverage, the definition is close to sufficient. Still missing is any signal of what a 'reading' contains or how it differs from sibling retrieval tools, which leaves the agent to guess at runtime.

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% for the single optional 'date' parameter, so the schema already explains the YYYY-MM-DD format and the UTC default. The description adds no extra parameter meaning; 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 first sentence states a specific verb and resource ('Today's reading, line by line'), and 'same as the app shows today' pins down the exact scope. However, it does not distinguish itself from siblings like get_reading or get_card, and the trailing blurb describes the whole Bhagavad Gita app rather than this 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?

No guidance on when to call get_today versus get_reading, get_card, or list_readings, even though those siblings overlap heavily. The second sentence lists app features (plans, search, verse lookup, whole books) without tying any of them to a selection condition for this 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful output-content context (Sanskrit, transliteration, English), but says nothing about range handling, size limits, or failure behavior for out-of-range chapters.

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 core purpose is front-loaded, but the second clause is a run-on inventory of unrelated app features that does not help an agent invoke this tool; the trailing 'read a passage at a time' is especially ambiguous. Roughly half the text is noise.

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 partially compensates by naming the returned content fields, and annotations cover safety. Still missing are range semantics and edge-case behavior, so it is adequate but not complete for a 2-parameter retrieval 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?

Schema description coverage is 100% and both required parameters are documented there, including the '47-51' range example, which the description merely repeats. No additional meaning (e.g. how ranges bound the response, or whether verse accepts cross-chapter spans) is provided, 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 first sentence gives a concrete verb-less but recognizable resource: a verse or range in Sanskrit with transliteration and English, which is more than a restatement of the name. However the second sentence drifts into describing the whole Bhagavad Gita product (daily verses, plans, search, Library books) rather than this tool, and it never distinguishes get_verse from siblings like get_chapter or get_reading.

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 statement or exclusion. 'verse lookup' and 'read a passage at a time' hint at the use case, but an agent cannot tell from this text when to call get_verse instead of get_chapter 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds essentially nothing behavioral — no pagination, no result count, no ordering — beyond a faint hint that books are organized into passages.

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?

Two sentences, and the second largely repeats the first while splicing in unrelated feature names. The repetition of the title and the off-topic capability list consume the space without adding information an agent can act on.

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 should tell the agent what a call returns (all books? a catalogue? identifiers to feed read_book?). Instead it leaves the return shape unstated and spends its budget on unrelated capabilities, so an agent cannot confidently call it.

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 the schema is empty, so there is nothing for the description to document. Baseline 4 applies; no parameter meaning is withheld or contradicted.

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 a verbatim restatement of the title and labels the resource ('whole books in the Library') without ever stating the action the tool performs (list/enumerate). The second sentence then attributes capabilities that belong to other tools — 'daily verses, plans, search and verse lookup' — which muddies rather than clarifies what list_books does.

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 list_books versus siblings like read_book, get_chapter, list_readings or search_readings. Worse, name-dropping 'search and verse lookup' alongside this tool invites mis-selection toward siblings that actually perform those functions.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that—no return format, pagination, or scope limits—leaving the annotation-derived baseline as the only useful information.

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 opening sentence is a wasteful restatement of the title, and the second sentence is a semicolon-heavy run-on that lists unrelated features. It is short but not front-loaded around the tool's actual action.

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 no-parameter, no-output-schema tool, the description should at least clarify what it returns and how it differs from siblings like list_books and get_today. Instead it confuses the scope by mentioning search, lookup, and reading passages, leaving an agent without enough context to select it 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?

The tool has zero parameters, and the schema is an empty object. Per the rubric, zero parameters yields a baseline of 4, since there is nothing for the description to clarify beyond the schema.

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 repeats the tool title almost verbatim ('All curated daily readings and plans') and never states a clear verb like 'list' or 'retrieve.' The second sentence mixes in capabilities of sibling tools such as search, verse lookup, and reading passages, so the tool's actual action remains ambiguous.

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 gives no guidance on when to use this tool versus siblings like get_today, search_readings, list_books, or read_book. It mentions 'search and verse lookup' but does not frame them as alternatives or exclusions.

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, destructiveHint=false and openWorldHint=false, covering the safety profile entirely. The description contributes the notion of sequential progression ('carries on into the next chapter'), which is a genuine behavioral trait, but says nothing about return format, how 'next' is determined, or pagination limits.

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?

Structure is poor: the leading sentence looks like a stray continuation directive, and the trailing clause ('daily verses, plans, search and verse lookup') advertises the whole app rather than this tool. Much of the text does not earn its place and the actual purpose is buried.

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 4 well-described parameters and annotations covering safety, the essentials for invoking the tool are recoverable from structured data. However, for a 4-param content-reading tool with no output schema, the description should clarify what a passage response contains and how sequential reads advance; it does so only obliquely.

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%, so book, section, n and ref are all documented in the schema with examples and override/default rules. The description adds no parameter meaning 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 tool's actual job – reading whole books from the Library one passage at a time – appears only in the second half of the description. The opening sentence ('Follow next for the next passage; it carries on into the next chapter') reads like output text from a previous response rather than a statement of what this tool does, blurring its purpose against siblings like get_chapter and get_verse.

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 guidance and no alternatives are named. The phrase 'whole books from the Library, read a passage at a time' implies sequential reading, but an agent gets no signal about choosing this over get_chapter, get_verse, or get_today.

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, non-destructive, and closed-world, so safety is covered. The description adds the 'best match first' ranking behavior, which is genuine non-obvious context, but says nothing about result counts, pagination, or coverage limits.

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?

Two compact clauses with no filler, and the search intent and ranking are front-loaded. The second clause's semicolon-separated catalog of content types is dense but still short.

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 search tool with a read-only annotation profile and no output schema, this is close to adequate, but the description never characterizes the results (verse hits vs. book passages, how many, what fields) or the relationship to get_reading/read_book, leaving a real gap for an agent deciding coverage.

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 documents the single 'q' parameter with examples, so the description carries little extra burden. The description adds no query syntax guidance (multi-word handling, phrase matching, scoping) beyond what the schema states, so 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 states a specific verb and resource ('Search the curated readings') and adds scope detail (Bhagavad Gita verses/plans, whole books from the Library). It is distinguishable from siblings like list_readings and get_reading, though the second clause is compressed and reads like a content catalog rather than a statement of what search does.

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?

Usage is implied by 'search' versus the retrieval siblings (get_reading, get_verse, read_book), but the description never says when to choose search over those lookup tools or what a match on a book passage returns. The agent must infer the when-to-use boundary from sibling names alone.

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