Spring Prompt

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

No annotations are supplied, so the description carries the burden. It discloses that this is a free status read and what information is returned, but does not explicitly state read-only/no side effects, auth needs, or whether it changes account state.

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 definition is a single compact sentence with a front-loaded list of returned information. 'Free' is terse but useful, and no wording is 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?

For a zero-parameter tool with no output schema, enumerating the returned fields makes the definition largely complete for invocation. It could be stronger by clarifying read-only behavior and response shape, but there are no material gaps.

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

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

The tool has zero parameters, which establishes a baseline of 4 under the scoring rules. The description adds no parameter details, and none are needed.

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 the resource (account status) and enumerates the returned signals—credit, free-credit expiry, pending prompts, tests so far, and next steps—so an agent can distinguish this overview from list_tests or get_test. It does not explicitly name those siblings, keeping it at 4.

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?

Implied use is checking account status before choosing an action ('what to do next'), and 'Free' signals no cost. There is no explicit when-to-use versus 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?

With no annotations, the description carries the full burden and does disclose a real behavioral trait: results are partial until the test is done, then the full comparison (best model, per-model pass rate and cost, sample failures) appears. It stops short of noting error behavior for unknown IDs or that completion is what unlocks results, and says nothing about side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the core ('A test's status') and then enumerates the payload via a colon. No filler, though the result enumeration is dense enough to read as a list rather than prose.

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 must explain the return shape; it names the key fields but not the possible status values, and it omits how a caller should poll or use wait_seconds to reach the 'done' state. Adequate for a simple two-parameter read tool, but with clear gaps.

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 only 50%: wait_seconds is documented in the schema, but test_id is bare. The description gives no hint about what a test_id is or where to obtain it, so it does not compensate for the undocumented required parameter; only the phrase 'when done' loosely gestures at the waiting semantics already covered by 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 states the resource (a test) and precisely what is returned: status, best model, per-model pass rate and cost, and sample failures. It is distinguishable from siblings like list_tests or test_prompt, though the retrieval verb itself is only implied by 'get' in the name rather than stated.

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?

Usage is only implied: check a test's status, and read results once it is done. It never says when to prefer this over list_tests (to enumerate tests) or test_prompt (to create a run), and it does not mention that test_id must come from a prior create/list 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?

With no annotations, the description carries the full burden. It usefully discloses that this is a mutating operation and that it "Spends credit" (a cost signal), plus that it re-runs on the same cases/checks/models. It does not say whether the rewritten prompt replaces the original, whether the change is reversible, or what the call returns.

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 tight sentences, front-loaded with the core action and ending on the cost warning, which is exactly the detail that should not be buried. No filler or restatement of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a credit-spending mutation with no output schema, so the description should hint at the result (new prompt, new scores, comparison?). It covers the action and cost well but leaves the return value and persistence semantics unaddressed.

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 0% for the single test_id parameter, so the description must compensate. It adds one meaningful constraint — the referenced test must be "finished" — but says nothing about identifier format or what happens if the test is unfinished.

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 pairs a specific verb ("Rewrite") with a specific resource ("a finished test's prompt") and adds the follow-up action of re-testing on the same cases, checks and models. It is clearly distinguishable from a plain test-runner like test_prompt, though it never names 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?

"a finished test's" implies the precondition that the test must already be complete, which is useful gating. However, there is no explicit when-to-use vs when-not guidance and no named alternative (e.g., use test_prompt to evaluate without rewriting), so the agent must infer the routing.

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 full disclosure burden. It does add real information beyond the name by saying the output pairs each judge with its agreement rate against its rater, which hints at a read-only listing. It says nothing about ordering, pagination, or what 'account' scoping means in practice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler, and the most important noun (trained judges) is front-loaded. It is slightly under-specified as a fragment rather than a complete sentence, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no annotations and no output schema, the description does give a rough sketch of the return contents (judges plus agreement frequency). It stops short of describing the response shape or whether the list is exhaustive, which the absence of an output schema makes more important.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and it introduces no misleading parameter claims. Baseline 4 applies for a parameterless signature.

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 is a noun phrase naming the resource ('this account's trained judges') plus the extra data returned ('how often each agreed with its rater'), but it never states the verb 'list' explicitly. It is distinguishable from the sibling train_judge by framing judges as already trained, yet the phrasing reads as a data fragment rather than a stated action.

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?

There is no explicit when-to-use guidance, no mention of when not to call it, and no reference to alternatives. The only implied usage is that this is for inspecting judges after training via train_judge, which the agent must infer.

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 implies a read-only lookup and discloses that the response includes pricing and remaining account credit, which is genuinely useful given there is no output schema. It does not state permission requirements, whether credit is account-wide or scoped, or whether the model list can vary by account tier.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no padding, and the resource (models) is front-loaded ahead of the return details. The grammar is slightly awkward with the comma splice, but nothing is 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?

For a zero-parameter, no-output-schema tool the description should at least pin down what comes back, and it does mention models, prices, and remaining credit. It stops short of clarifying model scoping or the shape of the pricing/credit fields, leaving the agent to discover the response structure on first call.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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 conveys that this returns available models along with prices and remaining account credit, which implies a listing operation matching the name. However, it never states an explicit verb such as 'list' or 'retrieve', and the phrase 'Models a test can use' is ambiguous about whether models are scoped to a particular test or globally available.

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?

There is no guidance on when to call this versus siblings such as list_judges or list_tests, nor any prerequisites or exclusions. The agent must infer from the name alone that this is the discovery call for model selection before using test_prompt or score_answers.

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?

The description adds a temporal behavioral trait by specifying 'recent,' which guides the agent on the scope and freshness of the data being retrieved. Since there are no annotations, the description carries the full burden of providing this necessary context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is maximally concise, providing all necessary context in one direct and efficient sentence without any superfluous language.

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 parameter-less list tool, the definition is adequate. It clearly identifies the resource ('prompt tests') and the scope ('recent') without needing to detail the output format, which is generally left to the output schema or execution environment.

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?

With zero parameters and 100% schema coverage, the schema handles all structural definition. The description provides no semantic meaning beyond defining the resource itself, adhering to the baseline score for parameter-less tools.

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 resource being accessed ('prompt tests') and the action ('list'), distinguishing it from singular retrieval tools like 'get_test' by implying a collection of 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 usage is implied by the function name and resource description, but there are no explicit instructions on when to use this list function versus other potential list functions from the sibling set.

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, and it does disclose two useful traits: the call is free ('Spends nothing') and it returns a link for review, so the agent knows this is a non-executing, non-billable staging step. It does not say whether re-loading duplicates existing entries, what permissions are needed, or how the loaded prompts persist in the account, which matters for a write-shaped 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?

Three short sentences, front-loaded with the action and resource, with the cost disclaimer and return value following. 'Returns a link to show them' is slightly elliptical about what the link points to, but nothing is 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?

There is no output schema, and the description covers the return value at a high level (a link), and the single parameter is fully documented in the schema. Gaps remain around re-load behavior, persistence semantics, and limits beyond the schema's 'up to 40 prompts', which an agent would need before calling a mutating load 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?

The schema has 100% description coverage, including per-field notes for file, name, cases, model, checks, prompt, and system, so the baseline is 3. The description only restates 'prompts and their examples' and adds no meaning beyond what the nested schema already 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?

The verb 'load' plus the resource 'prompts and their examples' is specific, and 'into the account' marks it as a staging/upload operation rather than an execution one, which separates it from run_loaded_prompt and test_prompt. It stops short of naming any sibling explicitly, so the differentiation is inferred rather than stated.

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?

'for the person to review and run' implies this tool stages prompts for human review instead of executing them, and 'Spends nothing' hints that costlier execution tools exist. However, there is no explicit when-to-use/when-not guidance and no named alternative such as test_prompt or run_loaded_prompt, leaving the agent to infer the workflow position.

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 and does good work: it discloses that no account is required, that models are hidden from raters, and — critically — that anyone holding the link can read the answers and inputs, prompting a consent check. It omits link lifecycle details (expiry, revocation, whether it is reusable) and does not say the call returns the URL, which matters since there is no output 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?

Three short sentences, front-loaded with the payload's nature, then the audience, then the privacy caveat. Some value is lost because the opening is a noun phrase rather than an action, so the first read doesn't make clear that this is a call the agent performs.

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 tool this covers purpose, audience, and the main security implication well. It falls short on the return value (the link itself, unstated and no output schema) and link lifetime/revocation behavior, both of which an agent needs before promising a shareable artifact.

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 0% and the single required parameter test_id is never named or explained in the description; the agent must infer that the exposed answers and inputs belong to the referenced test. The prose implies the link is scoped to one test but adds no format or validity guidance beyond the field name.

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

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

The description names a concrete deliverable — a shareable rating link for a test's answers — and distinguishes its mode from siblings like score_answers by noting it is phone-based, accountless, and model-blind. It never states an explicit action verb ("generate/create"), so the agent must infer that calling it produces the link, but the resource is unambiguous.

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?

"Send it to whoever knows what good looks like" gives an implied when-to-use, and "ask before sharing" adds a sharing precondition. There is no explicit routing versus alternatives such as score_answers or list_judges, and no statement of when not to use it.

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 and does well: it discloses that the operation spends credit, is capped by max_spend_usd by estimate, and may draft missing cases/checks. It does not clarify whether drafted cases/checks are persisted or whether the test is asynchronous beyond directing the agent to call get_test.

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 three tight sentences with no wasted wording. It front-loads the core action, then cost behavior, then result retrieval, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no annotations or output schema, the description covers the key needs: source of prompt_id, cost implications, the max_spend_usd cap, drafting of missing material, and where to get results. Minor gaps remain around persistence of drafted cases/checks and execution timing, but the agent has enough to 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 coverage is 100%, so the schema already documents both parameters. The description adds some meaning by calling max_spend_usd an estimate-based credit cap and by tying prompt_id to load_prompts, but most semantic detail is already present in the structured fields.

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: test a prompt from load_prompts. It also clarifies that the tool uses the prompt's cases and checks, drafts missing ones, and directs the agent to get_test for results. This clearly distinguishes it from siblings like test_prompt and get_test.

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 makes clear this is used for prompts obtained from load_prompts, and it names get_test as the follow-up for results. It lacks an explicit contrast with test_prompt or a clear when-not-to-use statement, but the intended context is well signposted.

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

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

With no annotations, the description must carry the behavioral burden; it does disclose two meaningful traits — the 50-answer batch cap and that each call 'spends a little credit' (a cost signal). It does not say whether the call is read-only/idempotent, how much credit, or what happens when judge_id is untrained or invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action, the mechanism, the output scale, and the cost front-loaded in that order. No redundant restatement of the tool name and nothing that could be cut.

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 two-parameter tool with no output schema, the description covers the essentials: what is returned (a 0–1 score per answer), the batch limit, and the credit cost. Minor gaps remain around output alignment with input order and failure behavior.

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 0%, so the description must compensate; it partially does by implying judge_id refers to a trained judge and that answers is a capped list of up to 50 items. It adds no detail on judge_id format, item sizing, or whether answers are scored in order.

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 (score answers) plus the mechanism (a trained judge) and the output scale (0 to 1), which clearly separates it from train_judge, list_judges, and test_prompt. It lacks an explicit sibling callout, but the purpose is unambiguous.

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?

'With a trained judge' implies a prerequisite (obtain judge_id via train_judge/list_judges) and 'up to 50 answers' implies a batch constraint, but neither is stated as a when-to-use rule. There is no guidance on when to prefer this over test_prompt or when not to call it.

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 and does it well: it discloses credit spend bounded by max_spend_usd, that it returns immediately rather than blocking, that a test_id is issued for follow-up, that cases/checks are auto-drafted when omitted, and that models are dropped dearest-first to fit budget.

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?

Four tight sentences, front-loaded with purpose, then cost, then the async return contract, then defaults. Nothing is redundant.

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 async job-launching tool with no output schema, the description supplies everything an agent needs: cost implications, non-blocking return, the test_id handoff to get_test, and default behavior for optional inputs.

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 real meaning on top by explaining the defaulting behavior for cases and checks and the budget-driven model selection logic that the schema does not state.

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 ('Start a test of one prompt across several models') and distinguishes itself from the sibling that retrieves results by naming get_test 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?

Clear context: use this to launch a multi-model test, then call get_test for results. It does not contrast with improve_prompt or say when a test is inappropriate, so it falls short of full when/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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the judge is tested on unseen answers, only kept if it beats a common-verdict baseline, and consumes some credit. It does not explain permissions, failure behavior, or what is returned.

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 short sentences, front-loaded with the main action, followed by the key validation and cost details. There is no redundant or wasted wording.

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 charged training operation with no annotations or output schema, the description covers the core mechanism and cost but leaves gaps around outputs, permissions, and failure conditions. It is adequate but not fully 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 only 50%: 'name' is described as whose opinions, but 'test_id' has no schema description. The description adds that training uses a test's ratings, which helps identify what test_id refers to, but it does not clarify the 'name' parameter or the relationship between the two parameters.

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: train a judge on a test's ratings. It adds useful scope about validation and cost, but does not explicitly differentiate this tool from siblings such as list_judges or test_prompt.

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?

Usage is implied by the purpose: use it when you want to train a judge from a test's ratings. There is no explicit guidance on when to choose this over related tools, nor any stated prerequisites or exclusions.

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