Gita Scroller

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds only the granularity hint 'one line at a time' and the audience note 'for voice'; it says nothing about pagination across cards, how n interacts with the reading, or what is returned.

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 short but poorly structured: it duplicates the title verbatim, contains a doubled period ('voice..'), and appends a server-level capability list that belongs elsewhere. The useful scoping information is not front-loaded ahead of the 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 read-only tool with no output schema and full schema coverage, the description should clarify the core concept ('card', one line at a time) and its relationship to the reading/plan parameters. Instead it leaves 'card' undefined and spends its budget on unrelated server features, so an agent cannot confidently distinguish it from get_today or get_reading.

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 all three parameters (n, date, reading) are documented in the schema with defaults and formats. The description adds no syntax or semantics 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 opens by repeating the title verbatim ("Today's reading one line at a time, for voice"), which is a tautology rather than an explanation of what a 'card' is. The trailing clause ('Bhagavad Gita: daily verses, plans, search and verse lookup; whole books from the Library...') describes the whole server's feature set, mapping to siblings like search_readings, get_verse, and read_book rather than this tool, so it fails to distinguish get_card from its siblings.

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-tool guidance. The description does not explain how get_card relates to get_today, get_reading, or get_chapter, and the server-wide feature blurb actively muddies the choice by implying search and book-reading capabilities.

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 safety and repeatability are covered. The description's real contribution is specifying the payload composition (Sanskrit + transliteration + English), which is useful and not in the structured fields. It adds no error, pagination, or bounding behavior (e.g., what happens for chapter outside 1-18).

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 verbatim, and the second is a run-on catalog of other features ('daily verses, plans, search and verse lookup; whole books from the Library') that does not describe this tool. Useful signal is buried rather than front-loaded; nothing here is edited for the agent's decision.

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 tool with full annotation coverage and full schema coverage, the description is minimally sufficient: it names the resource and the content of the return. However, it never says whether the chapter applies to the Bhagavad Gita specifically or to arbitrary books in the Library, which is a real ambiguity given the sibling set (list_books, read_book).

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 single 'chapter' parameter already documents range 1-18 with min/max constraints. The description adds nothing about the parameter (no defaults, no alternative identifiers like book slugs). Baseline 3 applies when the schema carries the parameter semantics.

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 describes the returned content (a whole chapter in Sanskrit with transliteration and English) but is essentially a restatement of the title rather than a specific verb+resource statement. The second sentence drifts into app-wide boilerplate (daily verses, plans, search, books) that muddles what this particular tool does. A reader can infer it fetches a chapter, but the definition never cleanly states 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 guidance on when to use get_chapter versus the obvious siblings get_verse or read_book. The phrase 'read a passage at a time' hints at a granularity distinction but never resolves it, and no exclusions or prerequisites 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, 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's only added behavioral context is that the output matches what the app displays today, which is mildly useful but says nothing about return shape, pagination, or UTC handling. A 3 reflects modest added value on top of rich 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 useful content is front-loaded in the first sentence, but the second sentence is boilerplate about the app's overall scope and does not earn its place in a tool-specific description. Two sentences for a one-parameter read tool is not egregious, but half of it is off-topic.

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-optional-param, read-only tool with no output schema, the description is minimally adequate: it establishes what 'today' returns and that the shape matches the app. It leaves unresolved how it differs from get_reading and what 'line by line' output actually contains, which is a real gap in a dense sibling set.

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 single optional 'date' parameter is fully documented in the schema, including the YYYY-MM-DD format and UTC default. The description contributes nothing about the date argument, 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 names a specific resource ('Today's reading') and notes the output mirrors the app's today view, but the verb is implicit and there is no differentiation from the sibling get_reading or get_card. The second sentence describes the whole Bhagavad Gita app rather than this tool, so it dilutes rather than sharpens 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 call get_today versus get_reading, get_card, or list_readings, even though the ambiguity between 'today's reading' and a generic reading tool is exactly what an agent needs resolved. The mention of 'daily verses, plans, search and verse lookup' gestures at the broader toolset but never routes the agent to a specific alternative.

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, so the safety profile is covered. The description usefully adds what content comes back (Sanskrit with transliteration and English), but says nothing about out-of-range verses, range size limits, or error behavior for invalid 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 first sentence is tight and front-loaded, but the second is a stream of app-level feature nouns ('daily verses, plans, search and verse lookup; whole books from the Library, read a passage at a time') that does not describe this tool's behavior and reads like scraped marketing copy.

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 only two fully-documented parameters, strong annotations, and no output schema, the core facts an agent needs are present plus the return-content note. Still missing are boundaries the description should supply, such as maximum range width, behavior across chapter boundaries, and what happens on an invalid reference.

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 schema already documents 'chapter' as 1-18 and gives '47-51' as the verse example. The description repeats the same range example without adding syntax rules such as whether ranges may span chapters or how a single verse should be passed. Baseline 3 applies when the schema carries the parameter burden.

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 identifies the resource (a verse or a range such as 47-51) and its payload (Sanskrit, transliteration, English), but there is no explicit verb and no differentiation from siblings like get_chapter or get_reading. The second sentence drifts into describing the whole Bhagavad Gita app (daily verses, plans, search, Library books) rather than this tool, which muddies rather than sharpens 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?

The phrase 'verse lookup' hints at when to use it, but there is no comparison to get_chapter (whole chapter), get_reading, or search_readings, and no stated conditions for choosing a range versus a single verse. An agent gets no routing guidance from this text.

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 structurally. The description adds only the domain nuance that books are consumed "a passage at a time," which hints at reading granularity but says nothing about result size, pagination, or what a "book" entry contains. With annotations carrying the load, this modest addition justifies a 3.

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 two sentences are redundant, both ending with the phrase "read a passage at a time," and the second sentence pads with unrelated feature marketing. Little of the text earns its place, and the actual purpose is not front-loaded clearly.

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 minimally sufficient to indicate it returns books, but it omits any indication of what the returned list looks like or how it relates to the read_book sibling. It is adequate but leaves real gaps given how simple this tool is to describe well.

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 per the rubric the baseline is 4. There is nothing for the description to clarify on this axis.

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 verbatim ("The whole books in the Library that can be read a passage at a time") rather than stating a clear verb+resource like "list books". The second sentence mixes in Bhagavad Gita feature copy (daily verses, plans, search, verse lookup) that describes an app rather than this tool, and it never distinguishes this tool from siblings such as read_book or get_chapter.

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 alternatives like read_book, get_chapter, or list_readings. An agent must infer that this enumerates available books, and nothing indicates prerequisites, ordering, or scope.

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 openWorld, so the safety profile is covered. The description adds only the content scope (Bhagavad Gita plus whole Library books), which is modest value, and it blurs that scope with operations performed by other tools.

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 the second sentence crams four unrelated capability names into one clause, which obscures rather than front-loads the tool's actual function. Sizing is fine; structure and focus are not.

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 definition should at minimum say what list is returned and how it relates to the other get_* and list_* siblings. The description gestures at scope (Gita readings, plans, Library books) but leaves the return content and sibling routing 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?

The tool takes zero parameters, so there are no parameter semantics to explain; schema coverage is 100% and additionalProperties is false. Baseline 4 is appropriate for a no-argument tool.

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 simply restates the tool title ('All curated daily readings and plans'), giving no verb+resource beyond the name. The second sentence is a jumble of feature names that actually belong to siblings (search_readings, get_verse, read_book) rather than describing what this tool itself returns, so an agent cannot cleanly distinguish it from those tools.

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_today, get_reading, search_readings, or list_books. Worse, mentioning 'search and verse lookup' inside a list tool's description points the agent toward sibling capabilities without telling it which tool to actually call for those tasks.

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 does add genuine behavioral context: reading proceeds passage by passage and 'carries on into the next chapter', i.e. sequential continuation semantics. It says nothing about output shape, ordering, or what happens at the end of a book, so it is useful but incomplete.

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 the first sentence is a confusing continuation instruction rather than a statement of purpose, and the second sentence spends words on unrelated app features (daily verses, plans, search). Some sentences do not earn their place, though nothing is bloated.

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 a 4-parameter schema, full schema coverage, annotations, and eight sibling reading tools, the description should clarify the division of labor among read_book, get_chapter, get_verse and get_today, and explain the 'next passage' mechanic. It does neither, leaving the agent to infer the tool's niche from the name.

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 already documents n, ref, book and section in detail, including defaults and reference formats. The description adds nothing about parameter usage (e.g. how 'next' maps to n/ref), 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 name gives a clear verb+resource (read_book), but the description opens with a UI-ish continuation hint ('Follow next for the next passage') and then drifts into app-level scope ('Bhagavad Gita: daily verses, plans, search and verse lookup'), which describes the product rather than this tool. Only the clause 'whole books from the Library, read a passage at a time' actually states the purpose, and it does not distinguish read_book from get_chapter, get_verse or get_today.

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 sibling is named as an alternative. The phrase 'read a passage at a time' only implies usage. An agent must guess how read_book differs from get_chapter/get_verse/get_today from the name alone.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the 'best match first' ordering, which is genuine behavioral context, but it says nothing about result format, limits, or pagination.

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 tight and well front-loaded, but the second sentence is a semicolon-and-colon run-on ('daily verses, plans, search and verse lookup; whole books from the Library, read a passage at a time') that is hard to parse and mixes content scope with capability.

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, no-output-schema tool with rich annotations, the description is minimally viable but leaves the key gap: among nine sibling tools it never clarifies selection criteria, which is exactly the context an agent needs most 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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'q' fully (words to search for, with examples). The description adds no query syntax or matching semantics beyond what the schema supplies, 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 gives a specific verb (search) and resource (curated readings) plus the ranking behavior (best match first), which distinguishes it from siblings like list_readings and get_reading. However, it never names those siblings or frames the tool against them, and the second sentence muddies rather than sharpens 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?

There is no when-to-use guidance and no routing against the nine siblings (list_readings, get_verse, read_book, etc.). The phrase 'daily verses, plans, search and verse lookup; whole books from the Library' gestures at content scope but does not tell an agent when to pick this tool over an alternative.

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