Hebrew Bible (Tanakh)

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

No annotations exist, so the description carries the full burden. It does disclose two useful behaviors: the accepted input duality (canonical subject code OR arbitrary topic tag) and the pagination contract (results are paginated; pass the returned cursor for more). It says nothing about the result shape or whether it is a pure read, leaving notable behavioral ground uncovered.

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?

Three sentences, each earning its place: purpose, valid-input sourcing with examples, then pagination mechanics. The most decision-relevant information is front-loaded and nothing is padded.

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 and no annotations, the description must stand alone, and it covers input sourcing and pagination adequately. The remaining gap is that it never characterizes what a returned study plan or article contains, which an agent browsing results would benefit from knowing.

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 the baseline is 3, but the description adds real meaning for the free-form 'subject' parameter by giving concrete valid values ("parsha", "holidays", "tehillim", "jonah", "purim", "psalm 23"), and it reinforces the cursor's round-trip usage beyond the schema text.

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 gives a specific verb and resource: 'List study plans and articles for a subject or topic', and it points at list_subjects as the source of valid subject codes. It is distinguishable from get_plan/get_chapter (which fetch a single item) and list_subjects (which enumerates subjects), though it never contrasts itself with those siblings explicitly.

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 states the triggering condition clearly (browse content for a subject code or any topic tag) and names list_subjects as the place to obtain subject codes, which is genuine routing guidance. It stops short of saying when to prefer this over get_plan for a specific plan, so there are no explicit 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. It discloses the return content (all verses of the chapter) but says nothing about authentication, rate limits, or ordering of verses. Adequate for a read-only lookup, but not rich behavioral disclosure.

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 zero waste; the core purpose is front-loaded and the prerequisite follows. Every clause 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?

No output schema exists, but the description communicates that the result is the full chapter text (every verse). Combined with the list_books prerequisite and language note, an agent has enough to call it correctly; only the exact response structure is unspecified.

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 three parameters and the enums. The description adds only the pointer that book names come from list_books and that language codes are listed in the enum, which is marginal value over 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 description gives a specific verb and resource — returns the full text of a chapter, every verse, from the Hebrew Bible/Tanach. It implicitly distinguishes from get_verse by specifying chapter-level scope, though it does not name that sibling explicitly.

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 states a concrete prerequisite workflow: use list_books first to obtain valid English book names, and points to the language enum for language choices. It gives clear context but does not explicitly compare against get_verse for single-verse retrieval.

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 full burden; 'Get' clearly implies a read operation, and it discloses a genuine behavioral trait beyond the schema — the schedule is truncated to the first 7 days. It does not say how to obtain the remaining days or what happens with an invalid id, leaving a small gap.

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, zero waste: the return contents are front-loaded, and the calling instruction follows with a concrete example. Every clause 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?

There is no output schema, and the description does cover the return shape in enough detail for an agent to know what it gets back, including the 7-day truncation. It omits what happens after the first 7 days and any error behavior, which is a minor but real omission.

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 the baseline is 3, but the description adds provenance the schema lacks: the id originates from a browse_subject link and is the final path segment, with its own example. The language parameter is left entirely to the schema enum, which is acceptable given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('Get the full detail of one study plan') and enumerates exactly what is returned: title, description, total length, and the day-by-day schedule. It is unambiguous against siblings like get_chapter/get_verse, though it never explicitly contrasts itself with them.

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 tells the agent where the required id comes from ('Pass a plan id from a browse_subject link'), which is a real workflow instruction linking it to the sibling browse_subject. It gives no when-not-to-use guidance or error/fallback conditions, so it stops short of a 5.

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 supplied, so the description carries the behavioral burden. It discloses the corpus and that the return is verse text, but says nothing about error behavior for out-of-range references, whether translations/versions can be chosen, or any limits. For a low-risk read operation this is adequate but thin.

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, no filler, with the core action front-loaded and the auxiliary hint second. 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?

With no output schema, the description does state what comes back ('the text of one specific verse'), and the schema fully covers inputs including the language default. It lacks only edge-case behavior (invalid verse, translation choices), a minor gap for a simple lookup tool.

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

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

Schema description coverage is 100% and includes a full book enum plus language enum, so the schema already documents every parameter. The description adds only the illustrative reference format ('Genesis 1:1') and the pointer to list_books, which is largely redundant with the enum.

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 ('Return the text of one specific verse') plus the corpus scope ('Hebrew Bible / Tanach'), which clearly separates it from a chapter-level fetch. However, it never names or contrasts with the sibling get_chapter, so the verse-vs-chapter distinction is only implicit.

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 gives concrete usage context (look up one verse by reference) and routes the agent to a sibling tool, 'Use list_books for valid English book names,' for the prerequisite of resolving book names. It stops short of stating when to prefer this over get_chapter or what to do for invalid references.

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 full behavioral burden. It helpfully discloses the return contents (names plus first-chapter link), but says nothing about read-only safety, ordering, pagination, or result size limits. Adequate but thin for a zero-annotation 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, no filler, with the resource and its payload front-loaded and the usage instruction second. Every clause 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?

With no output schema, the description correctly compensates by naming the returned fields and the downstream purpose. It omits any note on result size, ordering, or whether the list is exhaustive versus paginated, which is the only remaining gap.

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 the single optional 'language' enum parameter fully documented in the schema (ISO code, default 'en'). The description adds no parameter-level 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?

States a specific verb and resource ('List every book available in this corpus') and enumerates exactly what each entry contains (English name, localized name, first-chapter link). The mention of get_chapter / get_verse makes it distinguishable from sibling list tools like list_subjects and browse_subject.

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?

'Call this to discover valid book names for get_chapter / get_verse' gives explicit usage context and routes the agent to the downstream tools that consume this output. It does not state when *not* to use it or how it relates to list_subjects/browse_subject, so it falls just short of fully explicit alternative guidance.

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 behavioral burden. It discloses that the tool returns a list of subjects and that each includes a code to pass to browse_subject, which is useful workflow and return-shape context not found in the schema. It does not explicitly state read-only status, permissions, or pagination behavior, so it falls short of a 5.

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?

Three sentences, front-loaded with the tool's purpose and examples, followed by the return behavior and usage instruction. Every sentence contributes directly to selection or invocation, with no wasted text.

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 one-parameter discovery tool with no output schema, the description supplies the essential context: what it lists, example categories, what it returns (codes), and when to call it. It could be slightly more explicit about the full return shape or language curation, but it is largely 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 description coverage is 100%, and the schema fully documents the single optional language parameter, including its enum values and curated-per-language note. The description adds no parameter-level detail, 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 ('List the subjects (categories) you can browse'), provides concrete examples, and distinguishes the tool from its sibling by naming browse_subject as the follow-up action. An agent can immediately tell this is a discovery/list operation rather than a content retrieval 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?

Explicitly says when to call it ('to discover what is available before browsing') and names the alternative it feeds into (browse_subject). It lacks explicit when-not guidance or other alternatives, but the context is clear enough for correct use.

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