Crossload

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

With no annotations, the description carries the behavioral burden. It discloses that results are capped, that topics carry full paths to disambiguate names, and that 'detail' adds biography/picture for authors. This is solid read-only behavioral context, though it does not discuss pagination or return shape, which the output schema may cover.

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 tightly packed sentences with no filler. The core action is front-loaded, then usage guidance, then parameter-specific notes. 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 simple browse/list tool with a full output schema and complete parameter descriptions, this is fully sufficient. It explains when to use it, what the quirks are, and how parameters behave.

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 meaningful semantic context beyond the schema: a concrete example of substring matching, the disambiguation value of full topic paths, and the conditional behavior of 'detail' for authors only. This materially helps an agent use the parameters correctly.

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 ('List') and resource ('topics, authors or series'), with an optional substring filter. It also distinguishes itself from search filters by noting exact names are required for filtering, so an agent can tell this is the vocabulary-browsing 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 to use this tool before filtering a search by topic, author, or series, and explains the exact-name requirement. It does not name sibling tools outright, but the usage guidance is clear and actionable.

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 exist, so the description carries the full burden, and it delivers: it discloses case-insensitivity, exact-match behavior with fallback suggestions, unranked suggestion lists, cross-reference entries, multi-word matching, cursor ownership, and the security note about third-party instructions. This is far beyond typical 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?

The description is long but every sentence earns its place, covering unique quirks and security. It front-loads purpose and usage, then logically progresses through matching, suggestions, caveats, pagination, and trust. No filler.

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 tool with this many edge cases, the description is exhaustive. It explains fallback behavior, ranking absence, cross-reference handling, multi-word matches, cursor lifecycle, and content trust. An agent can call it correctly without ambiguity.

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?

Although schema covers both parameters at 100%, the description adds critical meaning: it explains that 'term' may match a different entry than asked for and that 'title' names the actual entry, and clarifies cursor ownership. These nuances are not in the schema and materially change how parameters are used.

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 ('look up') and resource ('the Calwer Bibellexikon (1912)') and explicitly differentiates from the sibling tool crossload_search ('use crossload_search instead for what preachers and authors have said about a topic'). This makes the tool's role unmistakable.

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 explicit when-to-use guidance ('Use it for 'what is/who was X' questions') and when-not-to-use with a named alternative. It also explains edge cases like missing entries and pagination, covering practical usage scenarios.

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 of behavioral disclosure. It clearly conveys sequential/partial reading through cursors, the inability to jump to a position, and the critical warning that returned text is third-party content whose instructions must not be followed. This gives an agent robust expectations beyond the schema.

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?

Every sentence earns its place: a clear one-line definition, parameter usage, a rationale distinguishing it from search, and a security warning. The core purpose is front-loaded, and there is no filler.

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 description fully covers how to initiate, how to continue, when this tool is necessary, and a content-safety caveat. Since an output schema exists, not explaining return values is acceptable. Nothing an agent needs to call this correctly 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 coverage is 100%, with both uid and cursor already described in the input schema. The description reiterates that uid comes from a crossload_search hit and that nextCursor continues from the previous response, but adds no meaningful semantics beyond what the schema already provides. 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 uses a specific verb ('Read') and resource ('transcript of one content item'), and specifies the sequential, portion-based mode. It distinguishes itself from crossload_search by stating that search returns items but never a position within one, making the tool's unique purpose clear.

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 explicitly explains how to use the tool: pass the uid from a crossload_search hit and pass nextCursor from the previous response to continue. It also gives a clear when-to-use rule — this is the only way to locate a particular sentence inside a long item — while contrasting with what search cannot do.

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, and it does so richly. It discloses non-literal semantic matching, the exact-name no-run behavior, the bibleRef range-filtering semantics, the withExcerpts literal-matching trade-off, and the uids limitation of returning items rather than passage positions.

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 dense but every clause earns its place, front-loading the result type and the primary use case before edge cases. It packs substantial guidance into a compact paragraph without repeating schema mechanics.

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 an 18-parameter tool with no annotations and an output schema that already covers return values, the description is remarkably complete. It covers when to use it, when not to, sibling routing, semantic pitfalls, filtering behaviors, and special parameter interactions.

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?

Although schema coverage is high at 89%, the description meaningfully adds cross-parameter behavior: 'query' is semantic and not literal, natural-language questions trigger stronger semantic matching, bible references inside the query skew results, and exact names are resolved server-side. These facts are not fully evident from individual 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 opens with a specific verb and resource: 'Search the Crossload catalogue of German Christian content' and lists the returned fields (title, author, licence, duration, teaser). It also distinguishes itself from siblings by pointing to crossload_browse for exact names and crossload_read_content for passage location, so an agent can tell it apart immediately.

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 an explicit trigger: 'Use it whenever the question is what was preached, written or said about a topic, a bible passage, by an author, or within a length limit.' It also provides routing guidance and exclusions, such as calling crossload_browse when exact spelling is unknown and using withExcerpts when quoting a passage is needed.

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, and it delivers: it reveals server-side counting (no client-side paging), exact-match requirement with rejection of guessed spellings, the 'withoutBibleRef' caveat, and that distributions are truncated to most-frequent entries and say when they omit data. No hidden surprise about what gets counted or omitted is left unstated.

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 front-loaded with the most important distinction ('counts only, never the items themselves') and uses compact sentences. It is a little dense and re-states the exact-match rule already in the schema, but every sentence contributes either behavior, usage guidance, or a caveat, so nothing feels wasted.

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 that an output schema exists and there is only one parameter, the description is complete: it states what the tool returns, what it does not return, its caveats, its prerequisites, and when to choose it over a sibling. An agent has everything needed to invoke it correctly and interpret its results.

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 already explains that 'topic' must be exactly as listed by crossload_browse with the rejection consequence. The description repeats this rather than adding new parameter-level meaning, so it stays at the baseline: useful reinforcement, but no substantial semantic addition 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 description explicitly states the tool 'returns counts only, never the items themselves' and then enumerates the exact distribution dimensions (bible books, authors, series, years, etc.). It also names the sibling tool crossload_search as the place to go for the actual items, making the tool's scope unmistakable.

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 use cases: answering which passages/authors/years a topic spans, finding related topics by evidence, and summarizing a topic before writing. It also names the alternative (crossload_search for item-level results) and states a prerequisite: the topic name must match crossload_browse exactly.

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