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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds useful scope by listing the organization data Sofia may use and explicitly restating that it cannot create, modify, run, or delete anything. It does not cover rate limits or detailed auth requirements, so it falls short of a 5.

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

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

The description is three tight sentences: capability, accessible resources, and mutation boundary. The core purpose is front-loaded and every sentence adds distinct 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?

Given rich annotations, full parameter descriptions, and no output schema, the description gives enough context to invoke the tool correctly: it is read-only, organization-scoped, and non-mutating. A minor gap is that it does not hint at the response shape or whether answers cite sources, but nothing essential for 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 description coverage is 100%, so the schema already documents prompt, session_id, and conversation semantics. The description adds no parameter-specific guidance beyond what the schema provides, which is the expected baseline for fully documented 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?

The description uses a specific verb and resource: 'Delegate a read-only Coval evaluation question to Sofia.' It clearly separates this delegation tool from the CRUD-style siblings by framing it as a read-only consultative delegation rather than a list/get/create operation.

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 implies when to use the tool by specifying 'read-only Coval evaluation question' and enumerating the data domains Sofia can access. However, it does not explicitly say when to use this instead of direct sibling tools like list_runs or get_metric, nor does it give exclusions beyond the mutation prohibition.

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=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of whether duplicate display_names are allowed, what happens to the agent after creation (does it go live?), or what auth is needed. For a non-idempotent creation tool, that is a meaningful gap.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly the source of the coverage gaps rather than a virtue in itself.

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 six parameters, a nested metadata object, a five-value enum, no output schema, and no annotations covering side effects, this description is minimal. The schema fills the parameter gaps, but nothing tells the agent what a successful creation returns or the implications of the enum choice (e.g., phone_number only relevant for voice agents).

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 six parameters are already documented in the schema with enums and formats. The description only alludes to model_type and 'connection details' (endpoint), adding no syntax, constraints, or required-vs-optional guidance 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 ('Create a new agent configuration') plus the two defining inputs, so the agent knows exactly what the tool produces. It doesn't explicitly distinguish itself from siblings like update_agent or create_run, but the create verb plus agent 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?

There is no guidance on when to use this versus update_agent, create_run, or other create_* siblings, and no prerequisites or exclusions are given. The agent must infer usage from the name alone.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the result is organization-private (visibility/auth scoping) and constrained to explicitly identified runs rather than arbitrary scanning. It does not say what is returned or whether repeat calls create duplicates, which matters given idempotentHint=false.

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

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

Two sentences, no filler. The positive capability and its scope come first, the exclusion second, so an agent reading only the opening clause still knows what the tool is.

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 create tool with no output schema, the description never says what comes back (a report ID to pass to get_report?) or how the 'explicitly identified evaluation runs' are bound given a completely empty parameter object. Those two omissions leave the agent unable to actually invoke the tool correctly, which outweighs the otherwise useful scope statements.

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 the baseline would be 4, but the description explicitly promises reports 'over explicitly identified evaluation runs' while the schema has no properties at all – the agent cannot tell how runs are supplied (implicit from prior context? a hidden convention?). That mismatch is a real ambiguity the description creates rather than resolves.

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

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

The description gives a specific verb and resource ('Create an organization-private saved report') plus the scope of the data it covers ('over explicitly identified evaluation runs'), which separates it from the read-side siblings list_reports and get_report. It stops short of naming those siblings as the contrasting path, so it is clear but not fully differentiated.

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 second sentence tells the agent what this tool deliberately will not do ('Public publishing and arbitrary custom dimensions are intentionally unavailable'), which is useful negative scope. However, there is no positive guidance on when to prefer this over list_reports/get_report, no prerequisites, and no indication of what the agent must have on hand before calling 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?

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false; the description adds nothing about what is actually created, that it likely launches a long-running/async job, cost or rate implications, or whether a run can be cancelled or deleted. For a destructive, non-idempotent, open-world creation tool this is a substantial disclosure gap.

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

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

Two sentences, both earning their place, with the core action front-loaded and no filler. It is lean to the point of under-specification, but nothing is wasted or buried.

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 7 parameters, a nested options object, and no output schema, an agent needs to know what a successful call returns (run id, status) and how options/concurrency affect execution. The description covers neither, leaving the most consequential behavior for a destructive creation tool undocumented.

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 of 3 applies. The description only restates the tags parameter's filtering purpose and says nothing about the nested options object (concurrency, iteration_count) or metric_ids behavior, which is the one area where prose could add real value.

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 'Launch' plus the noun 'evaluation' clearly names the action, and the required entities (agent, persona, test set) match the required schema fields. It is distinguishable from list_runs/get_run siblings, though it never says how it differs from create_scheduled_run, the closest ambiguous alternative.

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?

No guidance on when to use this versus create_scheduled_run (recurring) or create_report, and no prerequisites such as the referenced agent/persona/test set needing to exist. The only usage-adjacent sentence concerns tags, which is parameter detail, not selection 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 readOnlyHint=false, destructiveHint=true, and openWorldHint=true; the description earns credit for explaining the actual mechanics behind that risk — disabled-by-default creation and that enabling causes future external evaluation activity and costs. It still doesn't cover permissions or what happens to the created schedule if enabling fails, but the risk-relevant behavior is surfaced.

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

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

Two sentences, no filler, with the creation semantics first and the risk-bearing caveat second. Every clause carries information an agent needs.

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 destructive, open-world mutation tool it covers the key risk, but with no parameters and no output schema the description never explains how the run template is identified or what the created schedule reference looks like. Adequate but leaves a real gap around inputs and the return value.

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 declares zero parameters, which normally sets a baseline of 4, but the description references an "enabled" flag and a run template that are not present in the schema at all, leaving the agent to guess where those inputs come from. That is useful semantic content but creates a mismatch with the empty parameter 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?

The description states a specific verb and resource ("Create a recurring evaluation schedule") plus the source object ("from a run template"), which cleanly separates it from list_scheduled_runs, get_scheduled_run, and update_scheduled_run. It does not explicitly name the sibling it complements, but the create verb does the distinguishing work.

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

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

It gives a concrete usage condition: the schedule is inert unless enabled is explicitly true, so an agent knows creating is a safe default and enabling is the deliberate step. It stops short of naming alternatives or prerequisites (e.g., that a template must exist first), so it is clear context without full routing 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?

The annotations already declare this is a non-read-only, non-destructive, non-idempotent create operation. The description adds meaningful behavioral context by warning that scenario content must be fixture data and by specifying how IVR DTMF presses must be encoded, preventing spoken-digit mistakes.

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

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

The description is front-loaded with the core action and then adds targeted IVR guidance. It is compact and every sentence is relevant, though it partly repeats schema-level DTMF warnings.

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

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

Given the full schema coverage and existing annotations, the description covers the main purpose and the important IVR-specific edge case. It does not discuss return behavior or permissions, but those are less critical here because the schema is complete and no output schema is present.

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

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

Schema description coverage is 100%, and the schema already explains parameters such as input_type and simulation_metadata_input.script_turns in detail. The description reinforces DTMF handling but adds little parameter meaning beyond what the schema already provides.

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: "Create a synthetic evaluation test case in a test set." This clearly distinguishes creation from sibling read/update tools, though it does not explicitly name an alternative tool or clarify when to use it versus update_test_case.

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 provides useful usage context, including that scenario content is evaluation fixture data and never the current ChatGPT conversation. However, it does not explicitly say when to use this tool versus update_test_case or other sibling tools, nor does it list prerequisites beyond the implied test set 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds no behavioral context beyond that — nothing about duplicate naming, slug auto-generation, whether creation is idempotent in practice, or what the response contains.

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 economical sentence with the core action front-loaded and no filler. It is well structured but nearly the minimum content required.

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 6-parameter mutation with a nested parameters object and no output schema, the description omits what is returned on success, how slug collisions are handled, and any relevant guidance for the nested parameterization field. The fully documented schema partially compensates, but the description remains thin.

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 six parameters are documented in the schema, including the test_set_type options and slug auto-generation. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Create a test set') and adds the purpose ('organizing evaluation scenarios'). It is clear what the tool does, though it does not distinguish itself from nearby siblings like create_test_case or list_test_sets.

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 use this tool versus alternatives, no prerequisites, and no mention of what happens if a set with the same slug exists. The agent is left to infer usage entirely.

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 closed-world, so the safety profile is covered. The description earns credit beyond that by naming the concrete fields returned — meaningful here because there is no output schema to convey the response shape. It stops short of covering not-found behavior or whether optional fields (phone_number) may be absent for non-voice agents.

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 front-loaded sentence with the returned fields enumerated; no filler, no redundancy with the schema.

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, listing the returned fields is exactly what the description needs to do, and it does so. Minor gaps remain around null/absent optional fields and error cases, but an agent has enough to call this 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?

Only one parameter and the schema documents it fully at 100% coverage, including pattern and length constraints. The description adds nothing about agent_id beyond what the schema states, so 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 (get agent config) and enumerates what the config contains: model_type, phone_number, endpoint-configured flag, display_name. It is clearly distinguishable from list_agents and update_agent, though it never names those siblings explicitly.

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

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

Retrieval by agent_id is implied by the required parameter and the 'Get' verb, but there is no explicit statement of when to call this versus list_agents or get_persona, and no preconditions or failure behavior are given.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful context about what is returned (metric type, description, configuration), but does not cover error behavior, permissions, or rate limits.

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

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

The description is two short sentences, front-loaded with the core action and followed by the return contents. Every sentence contributes useful information with no filler.

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

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

For a simple one-parameter read tool with complete schema coverage and clear annotations, the description is largely sufficient. It identifies the main returned fields but does not describe behavior when the metric ID is invalid or 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?

The single parameter metric_id is fully documented in the schema with pattern, length constraints, and a clear description. The tool description adds no parameter-level semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: retrieving detailed information about one metric. It implicitly contrasts with list_metrics by saying 'a specific metric,' but it does not explicitly name the sibling tool for listing metrics.

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?

Use is implied for fetching an individual metric by ID, but the description does not explicitly say when to use this instead of list_metrics or other alternatives. No exclusions or prerequisites are given.

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, non-destructive, and closed-world behavior. The description adds useful context by listing the persona fields returned, including behavior-related fields like persona_prompt and conversation_initiation, but it does not describe error behavior or not-found handling.

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 a single, front-loaded sentence that lists the relevant details without filler. Every phrase contributes to clarifying what the tool returns.

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 read-only tool with full annotation coverage and a complete input schema, the description is nearly complete because it lists the returned fields in the absence of an output schema. Minor gaps remain around error behavior and response shape, but the essential context is present.

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 single parameter persona_id is fully documented in the schema. The description does not add any further meaning about persona_id, so it meets the baseline for full schema coverage.

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

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

The description uses a specific verb and resource ('Get persona details') and enumerates the details returned, making it clearly a single-persona retrieval tool. It is distinguishable from list_personas by the singular retrieval focus, even without naming the 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?

There is no guidance on when to use this tool versus alternatives such as list_personas, nor any prerequisites or exclusions. The retrieval use case is implied by the name and description but not explicitly stated.

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 readOnlyHint, idempotentHint and destructiveHint already declared, the description usefully adds behavior annotations do not cover: results are paged, completeness must be checked via the continuation token and scope.has_more, and report names/metadata are untrusted data. The prompt-injection warning is genuinely valuable context for an agent handling returned strings.

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, each load-bearing: what it returns, how to paginate correctly, and a safety caveat. The core purpose is front-loaded with zero 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?

No output schema exists, so the description carries the burden of describing the return surface, and it does so partially by naming continuation token and scope.has_more. It doesn't explain the row shape or what the report metadata contains, but for a bounded read tool this is close to sufficient.

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 all four parameters are already documented. The description notes that metric filters limit row data, which is a mild restatement of the metric_ids schema text, and adds nothing about report_id or page_token syntax. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource ('Retrieve one saved evaluation report') and adds the key scope detail that the result is a bounded page of rows, which separates it from the plural list_reports sibling. It never names the sibling explicitly, so 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?

The description gives operational guidance for pagination ('inspect the continuation token and scope.has_more before assuming the report is complete') but says nothing about when to use this tool versus list_reports or get_metric. The when-to-use case is only implied by the singular 'one saved evaluation report'.

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 and closed-world, so safety is covered. The description earns credit by adding value annotations can't: the PENDING→RUNNING→COMPLETED lifecycle and the fact that completed runs carry metrics (custom per org) and output_ids, which tells the agent results may be absent on early polls.

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

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

Two short sentences, front-loaded with purpose before the return-shape detail. The lifecycle arrow notation is dense but readable; nothing is wasted, though it could be marginally clearer as 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?

No output schema exists, so the description usefully sketches the return shape (status, metrics, output_ids). Combined with strong annotations, an agent has enough to call it correctly; only the missing guidance on incomplete/unknown runs keeps it below a 5.

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?

There is a single parameter at 100% schema coverage, and the schema documents run_id with type, length and pattern. The description adds nothing about run_id beyond what the schema provides, 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?

States a specific verb and resource ('Get run') plus what it returns: status and results, with metrics and output_ids on completion. It is distinguishable from list_runs by virtue of retrieving a single run, though the description never names siblings explicitly.

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

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

Usage is only implied: an agent infers it should call this when it has a run_id and wants status/results. There is no explicit when-to-use versus list_runs/list_runs filtering, and no mention of error behavior for unknown or not-yet-started IDs.

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 closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are capped to a bounded history window, a paging token continues within it, and history_scope signals when older upstream history exists beyond it.

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 tightly written sentences with the core action front-loaded and paging/scope caveats second. Slightly muddied by introducing output-field names that differ from the input parameter names.

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, so the description usefully sketches what comes back: a schedule, a bounded history page, a continuation token, and a scope indicator. The token naming mismatch is the only meaningful gap for an agent trying to page 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 baseline is 3, and the description's paging note is consistent with the schema's intent. However it references 'next_history_page_token' while the actual input parameter is 'history_page_token', and it never mentions history_size, so it adds little precise parameter 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 concrete verb and resource ('Retrieve one recurring evaluation schedule') and adds the scope detail of returning a bounded page of API history. The singular 'one' implicitly distinguishes it from list_scheduled_runs, though no sibling is named outright.

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

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

It gives continuation guidance ('Continue with next_history_page_token') and a hint about when older history may exist, which is useful. But it never says when to prefer this over list_scheduled_runs or get_run, and it omits any prerequisite/authorization 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's contribution is limited to naming the return payload shape, which is modest added value rather than rich behavioral disclosure (no auth, rate-limit, or not-found semantics).

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 front-loaded sentence with no filler; the return-field list is packed efficiently. It reads as a fragment rather than a full sentence, but nothing in it wastes tokens.

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 usefully enumerates the returned fields, and the annotations carry safety semantics. For a one-parameter read-only getter this is nearly sufficient; only not-found/error behavior and sibling disambiguation are 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?

There is a single parameter, test_case_id, and schema coverage is 100% with a pattern, length bounds, and its own description. The description adds nothing beyond the schema — which is the expected baseline when the schema does the work — so a 3 is correct rather than a low score.

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 (get test case) and even enumerates the returned fields (input_str, expected_behaviors, metadata), so the agent knows exactly what comes back. It does not, however, distinguish itself from sibling list_test_cases or get_test_set, leaving the single-vs-many routing to inference.

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 statement of when to use this rather than list_test_cases (browse) or get_test_set (parent container). The description gives no prerequisites, no mention of behavior when the ID is unknown, and no alternatives — usage must be inferred entirely from the name.

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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context by naming the returned details (display_name, description, test case count), though it does not mention error behavior such as a missing test set.

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 efficient sentence with the key return fields front-loaded. There is no wasted text or redundant restatement.

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

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

For a simple one-parameter read tool with rich annotations and full parameter documentation, the description is largely complete, especially by naming returned fields despite no output schema. It could be slightly more complete by noting behavior when the test set does not exist.

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 single parameter has 100% schema description coverage, including its pattern, length limits, and purpose. The description adds no further semantics about the ID parameter, so the schema is doing the substantive work.

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

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

The description uses a specific verb and resource ('Get test set details') and names the returned fields, so the core purpose is clear. It does not explicitly distinguish itself from siblings like list_test_sets or get_test_case, which keeps it below a 5.

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 required test_set_id and the singular 'Get' operation: retrieve details for a known test set. However, the description gives no explicit guidance on when to use this instead of list_test_sets or get_test_case.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that: no mention of pagination semantics, default page size behavior, whether the list is workspace-scoped, or result ordering. The model-type enumeration is domain context, not behavior.

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 compact sentences, front-loaded with the verb and resource, with the clarifying enumeration in the second position. Nothing is wasted or padded.

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

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

For a simple four-optional-parameter list tool with full annotation coverage and full schema coverage, the description is adequate but thin. With no output schema, the agent gets no indication of what a listed agent looks like or how pagination tokens are returned, and the scoping of the list (account/workspace) is unstated.

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 filter syntax, order_by format, page_size range and page_token are already documented in the schema, making 3 the baseline. The description contributes indirectly by naming the model types (VOICE, OUTBOUND_VOICE, SMS, WEBSOCKET, CHAT) that presumably serve as filter values, but never connects them to the filter parameter.

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

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

States a specific verb (List) and resource (agents) and parenthetically defines what an agent is ("AI systems to evaluate"), which disambiguates from siblings like get_agent or create_agent. The model-type enumeration adds scope detail. It stops short of explicitly contrasting with the other agent tools, so not a 5.

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 use this versus get_agent or list_runs, and no explanation of how to page through results or combine filter/order_by. The model-type list implies filtering is possible but never says so. Usage must be inferred entirely from the name.

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 safety is covered. The description adds the domain meaning of a metric and highlights that built-ins are hidden by default (though that duplicates the schema's 'default false'), but says nothing about pagination behavior or result volume.

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, no filler. The final sentence partially repeats the schema's default-false note, which is a small redundancy rather than a burden.

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 read-only list tool with full schema coverage and annotations, the description is close to sufficient. It does not say what fields a returned metric contains or how paging terminates, which matters somewhat since there is no output schema to fall back on.

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 five parameters (filter, order_by, page_size, page_token, include_builtin) are already documented with examples and defaults. The description only restates include_builtin, adding no syntax or semantics 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?

Specific verb+resource ('List available evaluation metrics') plus one line of domain framing ('Metrics define how agent performance is measured'). It is clearly a collection-listing tool, distinguishable from get_metric by implication, though no sibling is named 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?

The only concrete guidance is 'Set include_builtin=true to see built-in metrics', which tells the agent how to broaden results. There is no statement of when to use this versus get_metric or the other list_* siblings, and no prerequisites 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds the shape of a persona record (voice_name, language_code, background_sound, behavior prompt), which compensates somewhat for the absence of an output schema, but says nothing about pagination defaults, sort defaults, or filter expression support.

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

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

Two short sentences, front-loaded with the action and scope, then the record anatomy. No filler and nothing redundant with the schema.

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 full schema coverage and comprehensive read-only annotations, the main gap the description must fill is the return shape, which it does by enumerating persona fields in place of an output schema. Minor omissions remain around pagination behavior and filterable fields.

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 (filter, order_by, page_size, page_token) are already documented with examples and bounds. The description adds no parameter meaning beyond that, so the baseline 3 is appropriate.

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

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

Uses a specific verb+resource ('List personas') and immediately clarifies what a persona is ('simulated users'), which is genuinely useful domain context. It does not distinguish itself from the sibling get_persona, so an agent must infer that 'list' means enumerate-all versus single-fetch.

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 to prefer get_persona, and no examples of how to scope results via filter or order_by. Usage is only implied by the verb 'List'.

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, destructiveHint=false and openWorldHint=false, so the safety profile is free. The description usefully adds pagination semantics (bounded page plus continuation token) and org scoping, but omits ordering of results, behavior on empty result sets, and token expiry.

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, scoping and return behavior front-loaded with no filler. Slightly short of 5 only because it spends a clause on what the schema already says.

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

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

No output schema exists, so the description's note about page summaries and a continuation token carries real weight and covers the essentials for a read-only paginated list. Missing sort order and terminal-page behavior keeps it from 5.

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%: page_size bounds/default and page_token pattern are fully documented in the schema. The description's mention of a continuation token echoes the schema rather than extending it, so 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?

Specific verb+resource (list saved evaluation reports) with an added scope qualifier (authorized organization). It does not explicitly contrast with get_report or the other list_* siblings, so differentiation comes mostly from the name.

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 by the name and the 'saved evaluation reports' phrasing; there is no explicit statement of when to use this versus get_report for a single report or versus list_run_templates. An agent can infer it, but nothing is stated.

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 adds value annotations cannot: it enumerates the returned fields (run_id, status, tags) despite no output schema existing, and shows a concrete filter syntax the agent can copy. It does not mention pagination or default ordering.

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, front-loaded sentences: purpose first, data model second, return fields and filtering last. Nothing is repeated and 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?

With no output schema, the description correctly compensates by naming the return fields, and pagination parameters are fully documented in the schema. Missing only a note on default ordering or result size limits for an unfiltered list 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?

Schema description coverage is 100%, so the baseline is 3. The description contributes one extra filter example using the tag field, which is a slightly different case than the schema's status example, but it adds no syntax or semantics for order_by or page_token beyond what the 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?

States a specific verb and resource ('List evaluation runs') and adds the composition rule (run = agent + persona + test_set) plus returned fields, so the agent knows exactly what a run is. It does not explicitly distinguish itself from get_run or list_scheduled_runs, leaving sibling differentiation to inference.

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 tag filter example implies the browsing/filtering use case, but there is no explicit statement of when to use this versus get_run (single run) or list_scheduled_runs (schedules), and no exclusions or prerequisites. Usage is implied rather than prescribed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: results are page-bounded and a continuation token is returned when more exist, telling the agent to expect incremental retrieval.

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

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

Two short sentences with zero filler; the resource identity comes first and the pagination behavior follows. Nothing could be removed without losing 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 low-complexity, zero-required-parameter read tool with full schema coverage and rich annotations, this is nearly sufficient, and the description compensates for the absent output schema by describing the page-plus-token return shape. Only the default page size behavior under exhaustion is left implicit.

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 page_size (1-100, default 50) and page_token fully documented in the schema. The description only echoes the pagination concept, so it adds no meaning beyond the structured fields — baseline 3.

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

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

States a specific verb (list) and resource (reusable evaluation configurations / run templates) scoped to the authorized organization, so an agent can distinguish it from list_runs or list_reports by subject matter. It does not explicitly contrast itself with those siblings, which keeps it short of a 5.

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 scope phrase 'in the authorized organization' and the listing nature of the tool, but there is no explicit when-to-use guidance, no mention of alternatives such as list_runs or get_run, and no stated preconditions.

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, non-destructive and closed-world, so the safety profile is fully covered and the bar is lower. The description adds one useful behavioral fact beyond the schema - results are returned as a bounded page - but says nothing about ordering, default page size, or what a schedule record contains.

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

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

Two short sentences with zero filler, front-loading the resource being listed and following with the filter and pagination facts. Nothing is repeated from the name or 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 zero-required-parameter read-only list tool with full schema coverage and complete annotations, the description covers purpose, filters and pagination adequately; no output schema exists so return-shape detail is not required. A brief note on ordering or default paging would close the remaining gap.

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

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

Schema description coverage is 100%: each of the four parameters is documented in the schema with type constraints, ranges and defaults. The description only restates that filtering is possible by enabled state and run template, adding no syntax, format or interaction detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ("List recurring evaluation schedules") and enumerates the two filter dimensions, so the agent knows it is a paginated listing of schedules rather than runs, templates, or reports. It does not explicitly contrast itself with near siblings like list_runs or list_run_templates, which would be needed for a 5.

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: the agent can infer this is the listing call for schedules and that enabled/template_id narrow results, but the description never says when to prefer it over list_runs or get_scheduled_run, nor does it state prerequesites. No explicit exclusions or alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds useful return-shape context beyond annotations: each test case has input_str and optional expected_behaviors, which helps the agent understand what will be 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?

The description is two short sentences with zero wasted text. It is front-loaded with the operation and then gives the key filtering and return-shape details.

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 read-only list tool with complete schema parameter documentation and no output schema, the description provides enough context: it identifies the resource, the key filter, and the shape of returned test case objects. It could mention pagination behavior or total counts, but those are largely covered by the 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%, so the input schema already documents filter, order_by, page_size, and page_token. The description adds the specific filter usage 'test_set_id' beyond the schema's generic filter example, but it does not explain the other parameters, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'List test cases,' making the core operation clear. It also hints at filtering by test_set_id and describes returned fields, but it does not explicitly distinguish this tool from siblings such as get_test_case or list_test_sets.

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 says 'Filter by test_set_id,' which implies the primary use case for retrieving test cases tied to a test set. However, it gives no explicit guidance on when to use this tool versus get_test_case, list_test_sets, or other sibling list operations.

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 closed-world, so the safety profile is fully covered. The description adds the shape of each returned item, but never mentions pagination even though page_size/page_token exist, so the addition is modest.

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 compact sentences with the resource definition front-loaded and the return payload following immediately. Nothing is padded or restated.

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 read-only list tool with complete annotations and full schema descriptions, the definition covers identity and return shape adequately. It could mention that results are paginated and that an empty filter returns all sets, but nothing critical 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% – filter expressions, order_by syntax, page_size range, and page_token are all documented in the schema. The description adds no extra meaning about parameter interaction or filterable fields, so the baseline 3 applies.

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

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

Specific verb+resource ('List test sets') with a clarifying gloss ('collections of test cases') and an explicit statement of the returned fields (ID, name, description, test case count). It doesn't explicitly contrast with siblings like get_test_set or list_test_cases, so it stops short of a 5.

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 statement of when to use this versus get_test_set, list_test_cases, or other listing tools. The agent must infer that this is the enumeration endpoint from the verb 'List' alone.

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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false. The description adds genuine value by declaring partial-update semantics ('Only provided fields are changed'), which the annotations do not convey. However, it never explains what makes the call destructive — e.g. that a new prompt or endpoint replaces the existing one and cannot be recovered — so the most important behavioral fact is left implicit.

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

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

Two sentences, front-loaded with purpose followed by the partial-update rule; nothing is redundant. It is a little sparse for a destructive mutation tool, but no sentence wastes space.

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 destructive, non-idempotent mutation with no output schema, the description should warn about overwriting fields, permission requirements, and what happens to metadata/endpoint on replacement. None of that is present, so an agent has no basis to decide whether to confirm with a user before calling.

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 each of the six properties individually documented, so the schema carries the parameter burden. The description adds only the general rule that omitted fields are unchanged, which is meaningful but not parameter-specific.

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 ('Update an existing agent configuration'), which clearly distinguishes it from create_agent and get_agent in the sibling CRUD family. No further scope detail (e.g. which subsystems of the agent config are affected) is given.

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 use this versus get_agent-then-create, or when a full replacement is preferable. The phrase 'existing agent' implies agent_id must already resolve, but no prerequisites, permissions, or exclusions are stated.

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 real context beyond the annotations: enabling or changing timing 'can trigger future external evaluation activity and costs', which explains the consequence of the destructiveHint/openWorldHint flags. It does not say whether changes are reversible or what happens to fields not supplied, but the cost/external-activity warning is genuinely useful.

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 with no filler, and the operational warning is placed immediately after the action statement. Nothing needs trimming.

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?

A destructive, non-idempotent mutation with an empty input schema and no output schema needs the description to explain how to identify the target run and what inputs are accepted; it does neither. An agent reading this definition knows the effect but not how to actually call it.

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 declares zero properties, yet the description promises 'selected fields' and implies a target schedule, so the agent cannot tell from either source how a run is identified or which fields are updatable. With 0 params the baseline is 4, but the mismatch between the empty schema and the described field-selection behavior lowers this.

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 ('Update selected fields on one recurring evaluation schedule'), which cleanly separates it from create_scheduled_run and list_scheduled_runs. It stops short of naming a sibling or stating which schedule is targeted, so an agent knows the operation but not its scope.

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 choose this over create_scheduled_run or get_scheduled_run, nor any prerequisite (e.g., fetching the run first). The only conditional information is a side-effect warning, which is not usage 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds valuable mutation semantics beyond that: turn edits are merged server-side while simulation_metadata_input is replaced wholesale, which tells the agent exactly how differently the two paths behave.

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

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

Two sentences with zero waste. The primary action is front-loaded, and the one non-obvious operational warning follows immediately.

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, nested, destructive mutation tool, the description plus a very rich schema covers what an agent needs to call it correctly. The main omission is explicit partial-update semantics (whether omitted fields are left untouched or cleared), which matters somewhat for a destructive tool.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in detail, including the merge-versus-replace rules and DTMF formatting. The description's preference statement largely restates what the script_turns and simulation_metadata_input schema descriptions already say, so baseline 3 is appropriate.

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

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

The description states a specific verb (Update) and resource (one synthetic evaluation test case), and enumerates the mutable fields (scenario, expected behaviors, description, script turns). That distinguishes it cleanly from create_test_case, get_test_case, and list_test_cases without naming them.

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

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

It gives explicit routing advice for the one genuinely ambiguous choice: use the top-level script_turns field for turn edits because simulation_metadata_input replaces the stored object wholesale. It does not state exclusions or prerequisites for the other fields, so it falls short of a full when/when-not/alternative treatment.

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