Hebrew Bible (Tanakh)

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

No annotations are provided, so the description carries the full burden. It states it lists items (read-only behavior implied) and is paginated. It does not mention any side effects, permissions, or rate limits, but for a read-only browsing tool this 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?

The description is two sentences: first states purpose, second gives usage details and pagination. No redundant words, clearly structured, and easy to parse.

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 explains the return type (paginated list of study plans and articles), which is sufficient for an agent to understand what to expect. It could be improved by mentioning return fields, but the context of browsing content makes it complete enough.

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%, but the description adds value by giving concrete examples for the subject parameter (e.g., 'parsha', 'holidays', 'jonah') and clarifying the cursor's role. This goes beyond the schema's generic 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 clearly states the tool lists study plans and articles for a subject or topic, using a specific verb ('List') and resource. It distinguishes from siblings like list_subjects (which only lists subject codes) and get_plan/get_chapter (which fetch single items).

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 tells when to use it: pass a subject code from list_subjects or any topic tag. It also explains pagination. It does not explicitly list alternatives or when not to use, but the context makes it clear this is for browsing content under a subject.

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 provided, so description carries the full burden. It states the tool returns full text, implying a read-only operation with no side effects. However, it does not disclose error handling, performance, or any limitations beyond the scope. Adequate for a simple read tool.

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, front-loaded with the core functionality. No wasted words. Every sentence serves a purpose: describing the output and providing usage hints.

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?

Schema fully describes parameters, and the description covers the return type (full text), prerequisite (list_books), and language options. For a relatively simple tool with no output schema, this is sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The description adds value by guiding the agent to use 'list_books' for valid book names and to refer to the language enum, which helps in selecting correct enum values beyond the schema's basic description.

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 specific verb 'Return' and resource 'full text of a chapter', clearly differentiating from sibling tools like 'get_verse' (single verse) and 'list_books' (book names). It explicitly states the scope (Hebrew Bible/Tanach) and includes 'every verse' for clarity.

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?

Explicitly instructs to use 'list_books' first for valid book names and to check the language enum. This provides clear prerequisite and context for using the tool, though it doesn't explicitly exclude use cases or mention alternatives like 'get_verse' for single verses.

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 provided, so the description must carry the full burden. It implies a read-only retrieval by stating 'Get the full detail', but does not explicitly confirm it is non-destructive or mention side effects, rate limits, or auth requirements. Adequate for a simple fetch, but could be more explicit about safety.

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, each serving a distinct purpose: first describes the tool's output, second explains how to form the input. No unnecessary words, well-structured, easy to parse.

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 adequately describes the return value (title, description, length, schedule first 7 days). The parameter guidance is complete. The tool fits well into the workflow implied by siblings. Could mention if the full schedule is available via another tool or pagination, but not required.

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%, but the description adds value beyond the schema: it explains where to obtain the plan id (from a browse_subject link) and gives a concrete example. The language parameter is not elaborated beyond the schema enum, but the plan parameter guidance is helpful.

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 the verb 'get' and the resource 'study plan', and specifies exactly what is returned (title, description, total length, day-by-day schedule with first 7 days). This distinguishes it from siblings like browse_subject which lists plans, and get_chapter/get_verse which focus on different granularity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool: after browsing subjects with browse_subject, by passing the plan id from the link. It gives an example of the id format ('jonah_and_the_whale'). While it doesn't explicitly say when not to use, the context and sibling names provide clear guidance. Lacks explicit 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the basic operation (returning text) without mentioning any side effects, authentication requirements, rate limits, or error handling (e.g., what happens if the verse is not found).

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 concise sentences, front-loaded with the primary purpose and an example. Every sentence provides value without redundancy or unnecessary fluff.

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 clarify the return format (e.g., plain text, JSON). It does not mention coverage scoping (only Hebrew Bible) or error scenarios. Given the tool has 4 parameters (including an enum for language), the description is insufficiently 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?

The schema covers 100% of parameter descriptions, so the baseline is 3. The description adds marginal value by reinforcing the example usage but does not explain the language parameter or provide syntax details beyond what the schema already includes.

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 the tool returns text of one specific verse from the Hebrew Bible, with an example (Genesis 1:1). The verb 'return' and resource 'text of one specific verse' are specific, and it distinguishes itself from sibling tools like list_books by referencing it for valid book names.

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 includes a helpful hint to use list_books for valid English book names, providing some usage context. However, it does not explicitly differentiate when to use get_verse versus the sibling get_chapter (which returns whole chapters), nor does it state when not to use 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?

No annotations provided; description covers basic action and return fields but omits any behavioral traits (e.g., pagination, rate limits). Adequate for a simple list.

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, front-loaded with action and output, no redundancy. Every sentence serves a purpose.

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 list with one optional parameter and no output schema, description fully covers return values and usage intent.

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 describes language parameter fully (enum, default). Description adds no additional meaning beyond schema; baseline 3 due to 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?

Description specifies verb 'list every book', resource 'corpus', and output fields (English name, localized name, link). Clearly distinguishes from sibling tools 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?

Explicitly states 'Call this to discover valid book names for get_chapter / get_verse,' indicating when to use. No explicit when-not-to-use, but sibling tools cover distinct purposes.

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 full burden. It states the tool returns codes for browsing, implying a read-only operation, but does not explicitly declare safety, idempotency, or side effects. Adequate for a simple list tool.

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, front-loaded with main action, no redundant information. Every sentence adds value.

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 one optional parameter and no output schema, the description sufficiently explains the tool's purpose and how to use the result. Could be slightly more explicit about output structure, but overall complete for complexity.

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 description adds context that subject browsing is curated per language, explaining the parameter's significance beyond the enum values.

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 the tool lists subjects (categories) and gives specific examples. It explicitly notes the output includes a code for each subject to pass to browse_subject, distinguishing it from siblings like browse_subject and 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?

The description explicitly instructs to call this tool to discover available subjects before browsing, providing clear when-to-use guidance. It implies not to use it if you already know subject codes, but does not explicitly exclude scenarios.

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