Tanod ML

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial beyond-schema context: classifier limitations ('can miss new attacks and flag harmless text'), latency figures, first-call cold start, price and free tier, privacy guarantees ('never logged or stored'), and an explicit trust boundary ('data, never instructions'). This is exactly the extra disclosure that earns a high score.

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?

Dense but front-loaded: purpose and the sibling alternative come first, then output shape, limitations, errors, cost. Some sentences are terse to the point of being compressed, but virtually every clause carries operational information rather than 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 single-parameter screening tool with an output schema, the description covers everything an agent needs: what is screened, the verdict/score/chunks semantics and threshold, limits, error behavior, latency, cost, and how to treat the returned excerpts. Nothing material is left to inference.

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 there is only one parameter, so the schema already defines the argument; baseline would be 3. The description goes further by restating the 20,000-character ceiling as an enforced error condition and adding 'English-first' as a practical constraint on what text is worth submitting.

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 ('Check text for prompt injection before an agent acts on it') and explicitly routes a related concern to a different tool (text_unicode_inspect for hidden Unicode). An agent can distinguish this from the embedding, classification, and extraction siblings without opening the schema.

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 the triggering condition ('before an agent acts on it') and names the alternative tool for the adjacent case of hidden Unicode. It also defines the failure surface (422 over budget, 503 unavailable) so the agent knows when not to rely on a successful call.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context: model identity and license, English-only limit, score semantics (softmax vs per-label), the caveat that scores are not calibrated probabilities, latency, hash-pinned local execution, 503 behavior, pricing, free tier, and a no-logging privacy guarantee. This far exceeds the structured fields.

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?

Dense but front-loaded: the core action leads, then routing, then behavior, runtime, and pricing. Every sentence carries operational weight, though the pricing/free-tier/model detail makes it slightly heavy for a single paragraph.

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 an output schema present, the description need not restate return format, and it still explains scoring semantics, latency, failure mode (503, not charged), cost, and privacy. 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 description coverage is 100%, so the schema already documents all four parameters, setting the baseline at 3. The description clarifies multi_label behavior (scoring each label independently) and the meaning of the returned scores, but leaves hypothesis_template unexplained beyond the schema, so no lift above baseline.

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 (classify a text into your own labels) with the zero-shot framing, and explicitly distinguishes itself from the sibling extract_entities for named entities. An agent can tell what it does and what it is not.

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?

Routes the agent away toward extract_entities when the task is named-entity recognition, giving a clear conditional alternative. It does not contrast with adjacent siblings like text_sentiment or embed_texts, so exclusions are partial rather than exhaustive.

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?

Goes well beyond the readOnly/idempotent annotations: defines the `reliable` flag threshold (20 letters, confidence >= 0.6), the 422 no_text error and that it is not charged, latency expectations including cold-start, price, free daily quota, and that text is never logged or stored. This is unusually 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?

Front-loaded with purpose and alternative routing, then return shape, then edge cases, then operational facts. Dense but every clause carries actionable information; 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?

Despite an output schema existing, the description still summarizes the return payload (ISO codes, name, confidence, 3 alternatives), plus error, cost, latency, and privacy behavior. 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% and the schema already documents the 20,000-character limit. The description adds input semantics the schema lacks: letterless text yields 422 no_text and short text is often flagged unreliable, which helps the agent predict outcomes from the input.

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 (detect) and resource (language of a text) and explicitly distinguishes itself from the sibling translate_text. An agent can tell instantly what this does and what it is not.

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?

"To translate use translate_text" gives an explicit alternative for the adjacent use case. It does not state when detection is inappropriate (e.g., very short strings), though the reliability note partially covers that. Clear context, but no explicit when-not 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: per-image count caps by detail level, 10 MB and public-URL restrictions, 4,096-token cutoff, 422/503 failure semantics ('none charged'), latency ranges, per-item pricing, free-tier rate limit, and the privacy guarantee that text is never logged.

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?

Front-loaded with purpose and the text-only alternative before any constraints. It is a dense block of parentheticals (limits, errors, latency, pricing) but nearly every clause carries operational information an agent needs; only mild redundancy with the schema keeps it from a 5.

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?

An output schema exists, so return-format details are unnecessary, and the description still covers limits, error codes, cost, rate limiting and privacy. For a paid multimodal tool with hard per-call caps, nothing an agent needs to call it 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 description coverage is 100%, so every parameter including enum values, defaults and per-detail image caps is already documented in the schema. The description restates dimensions, input_type and image_detail almost verbatim, adding little beyond what the structured fields provide; 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 ('Create multimodal embeddings: images and text in one vector space') and immediately names the sibling it is not ('For text only use embed_texts'). An agent can distinguish it from embed_texts without opening either schema.

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?

Explicit routing rule: use embed_texts for text-only work, this tool when images are involved in the same shared space. The condition that selects the alternative is stated outright rather than left 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: token-window truncation with per-text reporting, the 422 too_many_tokens and 503 unavailable error cases, pricing per call, the 5-free-calls-per-day limit, latency ranges, and a privacy guarantee that text is never logged or stored.

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?

Purpose and sibling routing are front-loaded, followed by return facts, then operational details (errors, pricing, limits). Despite its length, each sentence carries distinct, non-redundant information justified by the tool's pricing and rate-limit complexity.

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?

Even though an output schema exists (so return values need not be explained), the description covers model choice, dimensions, truncation, encoding, error codes, cost, and privacy — everything an agent needs to invoke this paid, rate-limited embedding tool 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 description coverage is 100% with clear enum descriptions, so the schema does the heavy lifting (baseline 3). The description adds a little context by restating that outputs are normalised by default and that input_type applies the model's query/passage prefix, which helps consolidate meaning across params.

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 ('Create text embeddings') and explicitly distinguishes itself from siblings: 'For images too use embed_multimodal; for pair scores use text_similarity.' An agent can identify this tool among the many text/image siblings without opening a schema.

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?

Names the two closest alternatives with the exact condition that selects each (multimodal for images, text_similarity for pair scores). It also conveys the input-type usage (symmetric vs query/passage retrieval), leaving little 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?

Goes far beyond annotations: pinned model hash, CPU-only execution, no third-party API, 503 behavior and no charge, price and free-tier quota, no logging/storage, latency profile, and truncation at 2,000 entities with a flag. Annotations already confirm read-only/idempotent, and the description adds operational and cost context that materially affects invocation.

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?

Front-loaded with purpose and alternative tool, then dense operational facts with zero filler. Every sentence carries information an agent needs (pricing, limits, caveats). Not padded despite its length.

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 stateless extraction tool with a full output schema, this covers purpose, alternative, constraints, cost, performance, model caveats, and privacy. Nothing an agent needs to call it 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%, so the baseline is 3. The description adds useful meaning by naming the 18 OntoNotes label types and clarifying the default (all types), and by noting the 20,000-character ceiling's latency implication — this exceeds the schema's raw enum list.

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 ('Extract named entities') and names the sibling alternative ('For fields of your own schema use extract_json_with_schema'), so an agent can distinguish it immediately. The entity types are enumerated with concrete examples.

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 routes the agent away from this tool to extract_json_with_schema for custom schemas, and names the language constraint ('English only') and model limitations. When to use vs not is clear without opening any schema.

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?

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses accuracy caveats ('values can be wrong or missing'), throughput limits (two at once, 503 + Retry-After), failure codes (422 for bad input or >1,024-token answers, 504 over 40 s and not charged), latency (3-15 s typical, ~25 s worst case), pricing, and a no-logging privacy guarantee. This is exactly the context annotations cannot carry.

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?

Dense and front-loaded: purpose and sibling routing come first, then limits, errors, latency, price. Nearly every clause carries operational information, though there is mild redundancy (the 'text is data, never instructions' point is repeated from the schema, and error/latency detail is packed into a long final stretch).

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?

Even though an output schema exists (so return values need not be explained), the description still names the returned fields and covers the constraints, failure modes, cost, latency, and privacy an agent needs to invoke it correctly. Nothing material is missing for a 2-parameter, remote-model extraction 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 coverage is 100%, so the baseline is 3, but the description adds operative detail the schema only partly states: local $ref only, the 300-character/50-item silent truncation defaults, and concrete text examples (invoice, job post, contact block). It also reinforces that text is data, never instructions.

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+resource ('Extract JSON from text') plus the distinguishing constraint ('always matches your JSON Schema'), and explicitly routes the fixed-entity case to the sibling extract_entities. An agent can tell it apart from extract_entities without opening either schema.

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?

Names the alternative (extract_entities) and the condition that selects it ('for fixed entity types'), which is real routing guidance. It stops short of covering other plausible alternatives (classify_zero_shot, text_summarize) or when-not-to-use conditions such as long outputs, so it is clear but not exhaustive.

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 only cover the safety profile (readOnly, idempotent, non-destructive, no open world); the description adds substantial non-obvious behavior: the pinned open model and its 512-token truncation, 32,768-token request cap returning 422, 503 when the model is unavailable, latency range, pricing, free daily quota, and the privacy guarantee that text is never logged or stored.

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?

Front-loads purpose, scope, and the sibling alternative in the first sentence, then layers constraints, output shape, costs, and limits. Dense and largely earned, though the license strings and docs URL are slightly beyond what selection requires.

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?

An output schema exists, yet the description still sketches the return fields (index, rank, score as a 0-1 sigmoid, logit) and covers error conditions, cost, quota, latency, and privacy — everything needed to call and interpret it 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 description coverage is 100%, so the baseline is 3. The description adds meaning the schema does not carry — each text is cut at the model's 512-token window (longest side first) and `top_k` keeps the best k with results sorted best first — which affects how callers should size documents.

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 (rerank documents against a query), fixes the scope (up to 100 documents), and names the sibling it is not — 'For pair scores use text_similarity.' An agent can separate it from text_similarity/embed_texts without opening any schema.

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?

Names the alternative explicitly and the condition that selects it (pair scores → text_similarity), which is the primary confusion point in the embed/similarity/rerank family. No further when-to-use inference is required for the common decision.

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 and destructiveHint=false, so the safety profile is covered. The description still contributes real behavioral context beyond them: the RAKE scoring method, the sub-0.3 s latency expectation, the per-call price and free daily quota, and the privacy guarantee that submitted text is never logged or stored.

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?

Front-loaded with purpose and disambiguation, then layered with algorithm, performance, cost and privacy in one dense block. Every sentence earns its place for an agent deciding whether to spend a call, though the price/quota/docs tail makes it longer than strictly minimal.

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?

An output schema exists, so return values need not be explained here, and the description still notes the 'score and count' fields. Combined with cost, latency and privacy disclosures, an agent has everything needed to select and invoke it 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 description coverage is 100%, so all four parameters (text, top_n, language, max_words) are already documented with ranges, defaults and enum values. The description's mention of phrases 'between stop words and punctuation' hints at why the language parameter exists but adds no syntax or constraint detail beyond the schema. 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 ('Extract the keywords and keyphrases of a text') and immediately distinguishes itself from the two nearest siblings, text_frequency and extract_entities. The RAKE gloss clarifies what kind of keyphrases come back.

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 routes the agent: raw frequencies go to text_frequency, names and places go to extract_entities. That is a concrete when-to-use-this vs when-to-use-alternatives statement, not merely implied context.

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?

Goes well beyond the annotations: it discloses the VADER lexicon-heuristic limitation (misses sarcasm and domain jargon), expected latency (under 1 s), cost (USD 0.001), a free-tier rate limit (10 calls per IP per UTC day), and a privacy guarantee ('never logged or stored'). These are exactly the operational traits annotations cannot convey.

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?

Front-loaded with purpose, then alternatives, then output shape, then caveats/limits. Every sentence carries information, though it is denser than strictly needed and re-states the 'utilpeek' prefix already in the title.

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 read-only scoring tool with an output schema and full annotation coverage, the description adds limitations, latency, cost, rate limits, privacy, and a docs link. Nothing an agent needs before calling it 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%, so the baseline is 3, but the description adds meaning: it pins the scope to English input and explains that per-sentence scoring is optional output shaping. The VADER thresholds (positive ≥ 0.05, negative ≤ -0.05) describe the returned label rather than the parameters, so the gain is real but modest.

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 ('Analyze the sentiment of an English text') and explicitly disambiguates from the two nearest siblings ('For your own labels use classify_zero_shot; for counts use text_stats'). An agent can pick this tool over classify_zero_shot or text_stats without opening any schema.

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?

Names both alternative tools and the exact condition that selects each (custom labels vs. counts). It also scopes applicability by language ('English text') and states the underlying method, so the agent knows when results are appropriate.

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, yet the description adds substantial behavior beyond them: 512-token truncation with a `truncated` flag, a 422 on >16,384 tokens, a 503 for unavailable models (both not charged), latency expectations, pricing, per-IP free quota, and a no-log/no-store privacy guarantee. This is rich disclosure of what actually happens at runtime.

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 dense and parenthetical-heavy, but well front-loaded: purpose, alternative, return value, input shape, then limits/cost/privacy in descending priority. Every sentence carries information, though the phrasing could be tightened.

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 4-param scoring tool with an output schema present, the description covers return format, input constraints, model selection, failure modes, cost, and privacy. An agent has everything needed to call it correctly and interpret 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 coverage is 100%, so the baseline is 3, but the description adds value by mapping the opaque enum values (`small-en`/`multilingual`) to concrete models (bge-small-en, multilingual-e5-small) and clarifying the `pairs` vs `a`/`b` alternative plus its pricing model. This goes beyond the schema's terse field 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+resource ('Score the semantic similarity of one or up to 50 text pairs') and immediately names the sibling it is not ('To rank documents against a query use rerank_documents'). An agent can distinguish it from rerank_documents, embed_texts, and embed_multimodal without opening any schema.

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 routes the agent: use this for scoring similarity of text pairs, use rerank_documents to rank documents against a query. It also gives per-call scale guidance (1-50 pairs) and free-tier limits, so the when-to-use decision is unambiguous.

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, so the bar is lower; the description still adds substantial context: LexRank extractive method, verbatim sentences kept in original order, no paraphrasing/shortening/fact-checking, typical latency under 0.5s, pricing, free-tier limit, and a no-logging/no-storage privacy guarantee. No contradiction with 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?

Front-loads purpose and routing in the first sentence, then layers behavior, performance, cost, and privacy in tight clauses. Every sentence (including pricing and the docs URL) carries information an agent or caller would want; 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?

With an output schema present, return values need not be enumerated, and the description still notes per-sentence scores and original ordering. Combined with the alternatives routing, cost, limits, and privacy disclosure, nothing an agent needs to select or invoke this tool 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%, so baseline is 3; the description adds meaning by framing `sentences` and `ratio` as alternative selection mechanisms ('the most central `sentences` (or `ratio` of them)') and characterizing the selection as centrality-based (LexRank). It leaves the mutual-exclusion detail ('ignored when ratio is set') to the schema, but contributes real semantic framing.

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+resource ('Summarize a text by picking its key sentences') and immediately differentiates itself from siblings paper_digest (abstracts) and text_stats (counts). An agent can identify this as the extractive-summarization tool without opening the schema.

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 names the two nearest alternatives and the condition that selects each ('For paper abstracts use paper_digest; for counts use text_stats'). This is exactly the when-to-use-this-vs-siblings guidance the dimension asks for.

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?

Goes well beyond the annotations: cost (USD 0.005), free tier (5 calls/IP/UTC day), character cap, latency expectations (4-10 s for 200 chars, ~1 min for 2,000), and mapped error codes (422 bad input, 503 busy, 504 timeout, none charged). It also discloses data handling — submitted text not logged, results retained only for the url option — which the annotations' readOnlyHint=false/openWorldHint=true cannot convey.

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?

Front-loaded with purpose and the sibling call-out, then limits, then cost/latency, then data handling — a sensible ordering with no wasted lead-in. There is minor redundancy ("41 voices" and the 6-language list appear twice, and the docs URL is a tail append), but every distinct operational fact 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 five parameters, an output schema already present, and 100% schema coverage, the description supplies exactly the missing operational layer: cost, quota, timeouts, size cap, latency, and retention. Nothing an agent needs in order to call this correctly or to decide between base64 and url is absent.

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 per-parameter meanings are already documented; the description still adds value by explaining the voice/language coupling (the voice dictates the language, so text must match it) and the practical consequence of `output` (save data_base64 to a file, or get a 24 h link). It stops short of adding anything new on speed or format beyond what the schema says.

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 ("Speak text aloud") with the concrete scope of 41 voices across 6 named languages and the offline Kokoro-82M engine. It explicitly distinguishes itself from the audio-to-text sibling by naming transcribe_audio, so an agent can route without opening a schema.

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?

Names the inverse tool explicitly ("For audio to text use transcribe_audio") and gives concrete decision criteria for the output parameter (inline base64 vs. 24 h url). It also tells the caller to write the text in the voice's language, which is a real usage prerequisite rather than a restatement.

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 open-world, so the safety profile is covered. The description nonetheless adds substantial operational detail beyond them—failure codes (422/413/502-504, none charged), typical latency, privacy ('never logged or stored'), and an injection warning about third-party audio. That exceeds the annotation bar rather than merely repeating it, though the opening restates the title verbatim.

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?

Purpose and routing are front-loaded, and almost every sentence carries distinct information (limits, cost, errors, timing, privacy). Minor waste: the leading 'mlpeek: Speech to text and subtitles:' duplicates the title, and the price/timing block is dense enough to slow scanning.

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 7-parameter tool with an output schema, the description covers everything an agent needs to decide and call correctly: routing to siblings, size/duration constraints, cost per option, failure modes, and data-handling posture. Nothing material 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 the baseline is 3; the description still adds meaning by tying `speakers`, `chapters` and `translate_to_english` to both their output effects and their price tiers, which the schema handles only partially. It says little extra about `url`, `file_base64` and `language`, but those are already fully documented.

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 ('transcribe audio to text, timed segments, SRT and WebVTT') and immediately distinguishes itself from the two nearest siblings, transcribe_podcast_episode and translate_speech. An agent can identify the right tool without opening any schema.

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 routes away from itself: 'For a podcast episode use transcribe_podcast_episode; to translate use translate_speech.' It also gives when-to-choose signals for the optional modes (translate_to_english, speakers, chapters) and states hard eligibility limits (10 min, 25 MB), so no inference is required.

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 read-only, idempotent, non-destructive, open-world, so the safety bar is low, yet the description adds substantial context: 4xx/503/504 error semantics with charge implications, latency expectations (~25-45s, measured 42s), pricing (USD 0.02, no free tier), and a prompt-injection caveat for returned text. This is behavior well beyond the structured fields.

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?

Front-loads purpose and scope, then routing, then operational detail. It is dense but nearly every sentence carries load (errors, pricing, safety); a small amount of redundancy exists between the prose and the schema's parameter restatements.

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 9-parameter, open-world transcription tool with an output schema present, the description covers purpose, routing, continuation, failure modes, cost, and safety. Nothing an agent needs to call it correctly is missing, and return-value detail is appropriately delegated to the output schema.

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 every parameter (guid, season, start_s, duration_s, language, translate_to_english, etc.) is documented in the schema itself, so the baseline of 3 applies. The description enumerates the same parameter set and adds only the window.next_start_s continuation idiom, which is marginal added meaning.

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 ('Transcribe a podcast episode from its RSS feed') with explicit scope ('a window of up to 10 minutes as text, timed segments, SRT'). It also names the sibling to use for a different case ('For your own audio use transcribe_audio'), so an agent can route without opening either schema.

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?

Gives explicit when-to-use versus the alternative (transcribe_audio), continuation guidance ('Step start_s by window.next_start_s for more'), exclusions ('No Spotify-exclusive or YouTube content'), and retry behavior under load ('retry with a shorter duration_s'). Nothing about selecting this tool is left 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: error semantics (422 for no text/unsupported language, 503 for a missing model, not charged), latency 3-30 s, price USD 0.02 with no free tier, no logging/storage of submitted text, and an explicit prompt-injection caution on returned text.

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?

Purpose and sibling routing are front-loaded, and the semicolon-chained detail is dense but ordered. It loses a point for a stray, irrelevant 'on-chain strings' reference and for retreading 'digital or scanned' already present in the title.

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 an 8-parameter, paid, network-dependent tool with an output schema, the description covers everything an agent needs: limits, error codes, cost, latency, privacy, untrusted-data handling, and a docs link. Return-value structure is even explained despite the output schema shouldering that burden.

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 already 100%, so the baseline is 3; the description adds genuinely new constraints not in the schema, notably the 30,000-character per-call limit and the aggregated language code list, and reiterates that `source` should be supplied for scans. Some of this duplicates existing param descriptions, keeping it below 5.

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 precise verb+resource ('translate a PDF document, digital or scanned') plus the output format (Markdown) and language set, which no sibling offers. It also explicitly distinguishes itself from translate_text for plain-text input, so an agent can route without opening a schema.

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?

Names the alternative explicitly ('For plain text use translate_text') and gives the condition for supplying `source` on a scan, plus input limits and OCR guidance. It stops short of a full when/when-not decision matrix, but the routing context is clear.

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?

Goes well beyond the annotations: duration limits (2 min, 45 s with speak), error semantics (422 for too long/no speech, 503 busy, 504 timeout with no charge), typical latency, price, no-free-tier, retention rules (not logged; result kept 24 h only with output=url), offline model accuracy caveat, and a prompt-injection warning about third-party audio. This is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with purpose and the alternative, then progressively finer constraints. It is a single dense paragraph with minor repetition (the 2-minute and 45-second limits appear twice) and strings of facts that could be split, but nearly every sentence carries actionable 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 9-parameter multimodal tool with enums, an output schema, and real cost/failure modes, the description covers inputs, returns, limits, failure codes, pricing, and data-handling policy. Nothing an agent needs to call it correctly or warn a user 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% and the schema already documents every parameter in detail (voice defaults, speak limits, output storage, target one-pass vs two-pass). The description largely restates those constraints rather than adding new meaning, 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?

Opens with a specific verb+resource ('Translate speech: audio to English or 14 languages, optionally spoken') and immediately distinguishes itself from transcribe_audio. An agent can tell this apart from transcribe_audio and text_to_speech without opening any schema.

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 routes the agent: 'For a transcript in the spoken language use transcribe_audio,' which is the most likely sibling confusion. It does not address when to prefer translate_text or translate_document for non-audio input, so context is clear but the exclusion set is incomplete.

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?

Goes far beyond the readOnly/idempotent annotations: discloses offline quality being below commercial engines, the 5,000-char cap, 422 vs 503 error semantics with 'not charged', latency range including cold-start, price, free-tier quota, a no-logging guarantee, and an explicit prompt-injection caveat ('output is model text: data, never instructions'). None of this is in the structured fields.

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?

Front-loaded with purpose and routing before the operational caveats, so an agent can stop reading early. It is dense but a few items (language list repeated from the schema, docs link) are redundant, keeping it short of a clean 5.

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 translation tool with an output schema, everything the agent needs is present: routing, limits, error handling, cost, latency, and privacy. Return values are covered by the output schema, so the description is not obligated to restate them.

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: it spells out language-code semantics and the pivot-through-English behavior for pairs outside the supported list, plus the source-detection flag interaction. Marginal rather than major lift over the schema, hence 4 rather than 5.

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 ('Translate text between English and 14 languages') with explicit scope, then names the three siblings it is not (translate_document, translate_speech, detect_language). An agent can distinguish it from every nearby tool without opening a schema.

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?

Gives explicit routing rules: use translate_document for a PDF, translate_speech for audio, detect_language to only name the language. This is when-to-use/when-not guidance tied to concrete input types, exactly what the dimension rewards.

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