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

With no annotations provided, the description carries the full disclosure burden. It does add one meaningful behavioral trait beyond the name: 'The agent will be ready to take calls immediately,' which tells the agent the created resource is live at once. However, it remains sparse for a mutating creation tool — it does not disclose error cases, duplication behavior, idempotency, or cost/billing implications.

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

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

Two short sentences with zero waste. The primary action is front-loaded in sentence one, and sentence two contributes a distinct, valuable behavioral fact (immediate readiness). Every word earns its place.

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

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

The 100%-covered schema handles parameter understanding, and the description discloses the most important post-creation behavior (immediate readiness). However, with no output schema and no annotations, the description does not address the return value, failure modes, or validation outcomes an agent would encounter when invoking this tool with 10 parameters.

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 10 parameters including the 3 required ones already carry descriptions, enums, and examples. The description adds no parameter-level meaning beyond the 'voice AI agent' framing, so the baseline of 3 applies without needing compensation.

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 new voice AI agent on Movoice AI.' It is clearly a creation tool, distinct from the sibling list/get/update/delete tools. However, it does not explicitly differentiate itself from siblings by name — the uniqueness of the verb 'create' does that work implicitly.

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 word 'new' implies this is for creating previously nonexistent agents, and 'ready to take calls immediately' signals that no separate activation step follows. But there is no explicit when-to-use guidance, no alternatives named, and no exclusions (e.g., when to use update_agent instead for existing agents).

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states the operation is permanent, which is critical for a destructive action. It does not detail cascading effects on associated calls or authentication requirements, but the core irreversibility is clearly communicated.

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 with zero filler. Every word contributes meaning, and the destructive, irreversible nature is communicated 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 simple one-parameter delete tool, the description plus schema is adequately complete. It identifies the action, the target, the required input, and the permanence of the operation. Additional caveats about side effects or error handling would be useful but are not essential for basic correct invocation.

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 sole parameter 'id' is already well documented as 'Agent ID to delete'. The description adds no additional parameter-level context, but this is acceptable given the schema fully covers it.

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 ('permanently delete') and a concrete resource ('voice AI agent'), clearly distinguishing it from list_agents, get_agent, create_agent, and update_agent. The word 'permanently' adds important scope beyond the tool 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?

The purpose is clear enough that an agent can infer it is for removing an agent rather than reading or modifying it. However, there is no explicit guidance about when not to use it, prerequisites, or alternatives such as update_agent for reversible changes.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' clearly signals a read-only operation, but the description does not explain what kind of details are returned, error behavior for a nonexistent ID, or any access requirements. It is adequate but not rich, so a mid-range score is appropriate.

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 communicates the purpose in minimal words. Every element is useful, and there is no redundancy or filler. It is appropriately concise for a simple single-parameter getter.

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 one-parameter read tool with no output schema, the description is mostly sufficient for an agent to invoke it correctly. The only gap is that 'details' is vague and does not specify the return representation, but for a get-by-ID operation this is a minor omission given the tool's simplicity.

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 input schema already provides 100% coverage, including the source of the ID (from list_agents or create_agent). The description merely restates 'by its ID' without adding additional meaning. With full schema coverage, the baseline of 3 applies, and the description does not go beyond it.

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 a specific verb ('Get'), a resource ('voice AI agent'), and the distinguishing qualifier ('by its ID'). This sharply differentiates it from list_agents and the other sibling tools, leaving no ambiguity about which operation is being exposed.

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 this tool: when you already know a specific agent ID and want its details, as opposed to listing agents or performing mutations. The schema's parameter description further reinforces this by noting the ID comes from list_agents or create_agent. However, it does not explicitly state exclusions or directly name alternative tools.

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 be self-sufficient. 'Get' makes the read-only nature clear, and specifying that results include transcript and AI analysis sets expectations for what the call returns. It doesn't discuss potential failure modes or payload size, but for a simple retrieval this is adequate.

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 with no filler, front-loaded with the verb and resource, and it adds the key content detail (transcript and AI analysis) without redundancy.

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 tool with one well-documented parameter, the definition is complete: it identifies what is returned and where the ID comes from. Since there is no output schema, a bit more precision about the exact shape of 'full details' would justify 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?

The input schema already documents the only parameter with 100% coverage, including the useful note that the ID comes from list_calls. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('specific call'), and explicitly names the distinguishing content (transcript, AI analysis). This separates it from list_calls, which returns a collection, and from the agent-focused siblings.

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 tool definition makes the workflow clear: the id parameter is described as 'Call ID (from list_calls)', indicating the prerequisite of calling list_calls first. It doesn't explicitly state when not to use it or name alternatives, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool 'lists' agents, implying a read-only operation, but does not explicitly confirm it is non-destructive, describe pagination behavior (despite 'all' being potentially misleading given page/per_page parameters), or mention response format. The description adds no behavioral context beyond the literal action.

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 sentence, directly front-loaded with the action and resource. There is no redundant wording, filler, or repetition of schema details. Every word contributes to understanding the tool's purpose.

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 list tool with two optional parameters, the description is minimally adequate but leaves gaps. It does not mention that results are paginated, what the response looks like, or how this tool relates to sibling tools explicitly. Given the lack of annotations and output schema, the description is too sparse to be considered fully complete for an agent deciding how to invoke 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?

Schema description coverage is 100%, with both page and per_page parameters already described in the input schema. The tool description adds no additional meaning to these parameters, so it does not go beyond the schema. A baseline of 3 is appropriate since the schema already covers the parameters adequately.

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 ('List') and a specific resource ('voice AI agents in your Movoice AI account'), making the tool's function immediately clear. It also differentiates from sibling tools: get_agent handles a single agent and list_calls handles a different resource, so there is no ambiguity about what this tool returns.

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 usage: use this tool when you need to list all agents. However, it does not explicitly state when to use this over get_agent, create_agent, or list_calls, nor does it mention any exclusions or prerequisites. The guidance is entirely inferred from the verb and resource, not stated directly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool is account-scoped and returns fields like duration, sentiment, and transcript availability, but it does not explain pagination defaults, ordering, or whether the full transcript is included or only its availability.

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, focused sentence that immediately states the tool's purpose and then lists the key returned fields. There is no fluff or redundant 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 simple paginated list tool with no output schema, the description names the core resource and the included fields, which is enough to guide invocation. It could be more complete by mentioning ordering or the response envelope, but the gaps are minor.

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 input schema covers both parameters (page and per_page) with descriptions and defaults, so schema coverage is 100%. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('recent call logs for your account'), making it easy for an agent to understand what the tool does. It also differentiates itself from siblings like get_call (single call) and list_agents (different resource).

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 this tool should be used when an agent needs a paginated list of recent call logs, but it does not explicitly state when to prefer get_call for a single call or list_agents for agents. Usage context is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the key trait — PATCH-like partial update ('Only provide fields you want to change') — which prevents an agent from clobbering unspecified fields. However, it does not disclose error behavior, the effect of toggling isActive, permissions, or reversibility, leaving a thin profile for a write operation.

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

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

Two short sentences with zero waste. The first establishes verb and resource; the second delivers the crucial partial-update semantics. Nothing repeats schema content or adds 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 12-parameter mutation tool with no annotations and no output schema, the description omits what the call returns on success and how failures surface. It does cover the two essentials for a correct call — target identity via required id and partial-update semantics — and the schema carries enum and required constraints, so the main gaps are around response shape and consequences.

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 42%, leaving language, llmModel, ttsVoice, webhookUrl, asrProvider, llmProvider, and ttsProvider undocumented in the schema. The description must compensate but mentions no parameter specifics, formats, constraints, or enum guidance — the only parameter-level contribution is the general 'only provide fields you want to change' rule already implied 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?

States a specific verb ('Update') plus a specific resource ('existing voice AI agent'). The verb alone cleanly distinguishes it from siblings list_agents, get_agent, create_agent, and delete_agent, so an agent can select it without opening the schema.

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

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

'Only provide fields you want to change' gives clear in-tool usage guidance and signals partial-update semantics, while 'existing' implies the target must already exist, naturally pairing with create_agent for new agents. It never explicitly names alternatives or states when not to use it, so exclusions rely on inference from sibling names.

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