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

With no annotations, the description carries the behavioral burden. It discloses a key behavioral trait: determinism per agent per day and rotation tomorrow. It also states the return composition. For a simple read-only daily retrieval tool, this is sufficient context.

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 short sentences with no fluff. The primary behavior is front-loaded, and the determinism caveat is a concise, high-value addition.

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?

The tool is simple: one optional parameter already documented by the schema, and no output schema. The description sufficiently explains what will be returned, and determinism clarifies expectations. Nothing needed for correct invocation is missing.

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 lang parameter's enum values and default are already documented in the schema. The description adds no parameter-specific semantics, so the baseline score of 3 is 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 description clearly states a specific verb ('Returns') and resource ('today's practice') and enumerates its content: one verse, one principle, one reflection, one exercise. It also distinguishes itself from random-practice siblings by emphasizing deterministic daily content.

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?

It clearly communicates when to use it: when you need today's fixed practice. The determinism note implies it is not the tool for random/varied selection, making alternatives like get_random_verse implicitly less appropriate, though it does not name alternatives explicitly.

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?

With no annotations, the description must carry behavioral disclosure. It does convey the key random-selection behavior and implies a read-only operation, but it does not explain what is returned, whether the random choice is across all texts, or any error/edge-case behavior. The description adds some value but leaves gaps.

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?

One clear, front-loaded sentence with no filler. Every word contributes to the meaning, and it effectively conveys the core operation and a key option.

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 tool with two optional, fully documented parameters, the description is largely complete. The main gap is the lack of return-format information, since no output schema exists, but 'random verse' strongly implies the return value is a verse.

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 both parameters, so the baseline is 3. The description adds a small amount of context by confirming 'text' is an optional filter, but it does not add meaning beyond the schema's own parameter descriptions.

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 uses a specific verb and resource: 'Get a random verse from the classical yoga texts', which clearly distinguishes it from siblings like get_verse or search_verses by the word 'random'. It also mentions an optional filter by text, further clarifying scope.

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 purpose is clear, and 'optionally filtered by text' implies a conditional use, but there is no explicit guidance about when to choose this tool over siblings such as search_verses or get_verse. The usage context is implied by 'random' rather than directly stated.

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?

With no annotations, the description carries the behavioral disclosure burden. It states the operation is a retrieval ('Get') and discloses return contents ('includes Sanskrit, transliteration, and navigation links'). This is sufficient for a simple read tool, though it does not mention error behavior for invalid paths.

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 short sentences with no filler. The core action is in the first sentence, and the second provides useful return detail. Every word contributes.

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 2-parameter getter with 100% schema coverage and no output schema, the description reasonably covers purpose and return contents. It could mention what happens when the path is invalid or that lang defaults to Spanish, but the schema already documents the default, so nothing critical is missing.

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 both parameters are already documented with examples and enums. The description adds no further meaning to the parameters beyond reinforcing that 'href' is a path to a verse, so the baseline of 3 is 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?

States a specific verb and resource ('Get a specific verse by its path') and the return scope ('Sanskrit, transliteration, and navigation links'). This clearly distinguishes it from siblings like get_random_verse and search_verses, which operate by different selection criteria.

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 conveys clear context: use this when you have an exact verse path. It does not explicitly name alternatives or exclusions, but the path-based targeting is enough for an agent to select this over the search or random variants.

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?

No annotations are present, so the description carries the full behavioral burden. It transparently states the return content (name, slug, verse count, URL) and implies a read-only listing, but it does not disclose ordering, pagination, response size, or whether all texts arrive in a single call. For a simple zero-param list 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?

A single sentence that front-loads the verb and resource, then specifies the exact metadata fields. Every phrase earns its place with no filler or redundancy.

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, read-only catalog tool with no output schema, the description is nearly complete: it names the resource and the exact return fields. Minor gaps remain around behavioral details (ordering, pagination, how returned slugs feed into siblings like get_verse), but nothing blocks a correct call.

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 empty schema makes description coverage trivially complete, so there is nothing for the description to explain. Per the baseline for zero-param tools, a 4 is appropriate; the description correctly adds no parameter syntax because none exists.

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 names a specific verb ('List'), a resource ('classical yoga texts'), and precise scope ('all available'), then enumerates the metadata returned (name, slug, verse count, URL). This clearly distinguishes it from the content-search siblings like search_verses, which operate on verse text rather than the catalog of texts.

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 'List all available classical yoga texts' establishes a clear browse/catalog context an agent can select against, distinct from the search-and-retrieve siblings. It doesn't explicitly state exclusions or say 'use this before get_verse to obtain a slug,' but the use case is evident and no alternative routing is needed at this level.

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?

With no annotations, the description carries the transparency burden and meets it by disclosing the three-part return structure and the input concept. It doesn't mention side effects, but the tool appears to be a non-mutating lookup/reflection generator, and the description's 'returns' framing is adequate.

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?

One dense sentence that front-loads the main purpose and keeps supplementary context in a short follow-up phrase plus repo link. It is efficient without being under-specified.

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?

Given no output schema, the description does enough to tell an agent what results to expect. The two parameters are already documented in the schema, so nothing critical is missing; a short note on error behavior or non-matching principles would make it complete.

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%, with the principle parameter already enumerating all available values and lang describing its options/default. The description adds only a light conceptual gloss ('yama/niyama/concept') rather than substantial new meaning, so the schema baseline of 3 is 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 description states a specific resource (yogic principle) and exactly what is returned: a relevant verse, an AI-agent reflection, and a practical exercise. This makes the tool's function clear, though it doesn't explicitly contrast with sibling tools like search_verses 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?

No explicit when-to-use guidance or alternatives are provided. The 'Part of the Yogic Alignment Framework' phrase gives some context, but the description does not tell an agent when to select this over search_verses, reflect, or daily_sadhana.

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?

With no annotations provided, the description carries the full behavioral burden. It surfaces key behavioral details: returns 'up to 3' verses and attaches principle context to each. However, it doesn't disclose how verses are selected, what happens if no relevant verses exist, or whether the tool has any state/side-effects beyond retrieval.

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 with no filler: the first names the action and outcome, the second adds the cap ('up to 3') and the principle-context detail. Essential information is front-loaded and every sentence earns 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 two-parameter tool with no output schema, the description covers purpose, input, and output shape. It's missing only an explicit tie to sibling distinctions (e.g., when 'reflect' vs 'search_verses'), but the ethical-dilemma framing largely 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 description coverage is 100%, so the schema already fully documents both 'situation' and 'lang'. The description adds no new parameter-specific meaning (it restates 'ethical situation' essentially as in schema). Baseline 3 is appropriate when 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?

States a clear verb ('Describe'), target situation ('ethical situation or dilemma'), and concrete deliverable ('up to 3 relevant verses with context on which principle each relates to'). This distinguishes it from sibling search tools by emphasizing ethical reflection and contextual principles rather than generic verse search.

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 implies clear context—use when the agent faces an ethical situation or dilemma—and clarifies the interaction model (agent describes, tool returns verses). It doesn't explicitly name alternatives or state exclusions, but the orientation toward dilemmas gives enough positioning against search_verses and practice_principle.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a search operation, implying a read action, but provides no details on return format, result shape, pagination, or side effects. The diacritics-insensitive matching hint lives in the schema, not the description.

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?

A single sentence that is front-loaded with the action and resource, containing no filler or redundant phrasing. Every word earns 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?

Despite having simple, well-schematized parameters, the tool lacks an output schema and annotations. The description fails to state what a search returns (e.g., glossary entries, definitions, translations) and does not differentiate it from search_verses, leaving an agent to guess its role in a workflow.

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 both 'query' and 'limit' fully documented in the input schema, including the diacritics-insensitive matching behavior and default/max limit. The description adds no parameter-level information 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 states a specific verb ('Search'), a specific resource ('the hatha.es glossary'), and the object ('Sanskrit terms'). This clearly differentiates it from sibling search_verses, which targets verses rather than glossary entries.

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 is given on when to use this tool versus alternatives. The description simply states what the tool does, leaving the choice between search_glossary and search_verses to inference.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the tool returns matching verses and can filter by content, title, or transliteration. However, it does not mention result ordering, pagination, matching semantics, or any side effects, though for a search tool these omissions are moderate.

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 two short sentences with no filler or redundant phrasing. The core action and scope are front-loaded, and every clause adds meaningful 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?

For a search tool with a simple required-query pattern and full schema coverage, the description is largely complete. It conveys the resource, scope, matching fields, and the fact that results are returned. It lacks explicit return-structure details, but no output schema exists and the absence is not critical for basic invocation.

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 all four parameters. The description adds useful context about matching fields and text scope, but it does not need to compensate for missing parameter documentation. Baseline 3 is 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 description states a specific verb ('Search'), a clear resource ('verses'), and a well-defined scope ('across all classical yoga texts'). It also explains the matching dimensions ('content, title, or transliteration'), which clearly distinguishes it from siblings like get_verse, get_random_verse, and search_glossary.

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 implies when to use the tool: when an agent needs to find verses by keyword across multiple texts. However, it does not explicitly mention alternatives or provide exclusion criteria, such as 'use get_verse for a specific verse by ID' or 'use search_glossary for term definitions.'

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