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

With no annotations, the description bears the full burden of behavioral disclosure, but only says 'Create an AI agent.' It does not mention side effects, permissions, idempotency, or what the response contains. It also contradicts the input schema by claiming voice and agent_start_message are required when only name is required.

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 short and front-loaded, which is structurally good. However, the 'Required' phrase is inaccurate and does not truly earn its place because it misrepresents the schema and could cause incorrect agent behavior.

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?

This is a creation tool with no output schema, no annotations, and a misleading required-fields note. An agent lacks information about what happens after creation, how the response is structured, and which fields are genuinely optional. It is not complete enough for reliable 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 coverage is 100%, so the baseline is 3, but the description adds no useful parameter meaning and actively misleads by asserting fields are required that the schema does not require. This makes the description worse than simply relying on the schema.

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

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

The description clearly states the action ('Create') and the resource ('an AI agent'), which is a specific verb+resource pair. It is reasonably distinguishable from sibling tools like updateAgent and listAgents, though the description alone does not emphasize the distinction.

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 createVoiceClone or updateAgent. The 'Required' note is about fields, not usage context, and provides no exclusions or decision criteria.

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 must carry the full behavioral disclosure burden. It only states that extra columns go into extra_metadata_fields; it does not mention permissions, idempotency, potential for duplicates, or what the response contains after creation.

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 no filler. The core purpose is front-loaded and the extra-columns note is a useful, concise addition.

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 schema fully documents all seven parameters, and the description covers the basic operation and extra-column handling. However, with no annotations and no output schema, the description does not disclose the response format or side effects, leaving part of the behavioral picture incomplete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining that extra columns beyond the schema should be placed in extra_metadata_fields, which goes beyond the schema's per-property descriptions.

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

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

The description clearly states the verb 'Add' and the resource 'a contact / lead', so an agent can tell this tool creates leads rather than reading them or managing other entities. It does not explicitly compare itself to siblings like createAgent, but the resource naming is distinct enough.

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 about when to choose this tool over alternatives such as createAgent or listLeads, and no prerequisites or exclusions are mentioned. The only implicit signal is the tool name and the 'Add a contact / lead' phrasing.

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

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

With no annotations, the description carries the burden of disclosing behavior. It does so well by stating the action (emails an OTP + code ref), the negative (does not create an account), and the required continuation. It omits details like authentication requirements or rate limits, but the disclosed behavior is not misleading.

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 dense with useful information. The main action is front-loaded, and the most important caveat ('does NOT create the account') appears immediately. No filler or repetition.

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

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

The description explains the action and next step, but with no output schema it does not state what the tool returns. Since the agent presumably needs the code ref to call validateNewUser, the lack of return-value documentation leaves a meaningful gap in flow completion.

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 67%, with email and name having descriptions. The tool description itself adds no parameter-specific meaning beyond the schema. It does not clarify the phone parameter or how the parameters relate to the activation flow, so it only meets the baseline.

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

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

The description clearly states this tool requests an account-activation code by email and explicitly clarifies that it does NOT create the account. It names the follow-up tool (validateNewUser), making the tool's role in the larger flow unambiguous despite the 'createNewUser' 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 description tells the agent to call validateNewUser to finish account activation, which is a clear next-step instruction. It also prevents misuse by saying the account is not created here, but it does not explicitly compare against sibling tools like requestOtp or loginUser.

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

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

With no annotations, the description carries behavioral disclosure. It reveals an important non-obvious behavior: the scheduled call only activates if status is set to LIVE. But it does not explain how to set that status or what happens before activation, and it omits other side effects or authorization requirements.

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 short and front-loaded with the primary purpose. The second sentence earns its place by conveying the activation requirement, though its wording is terse and somewhat cryptic.

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 operation with no annotations and no output schema, this description is incomplete: the activation mechanism (setting status LIVE) is not represented in the input schema, the response is unspecified, and one parameter (receipient_name) lacks a schema description. An agent cannot confidently complete the full scheduling workflow from this text.

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 83%, so the schema already documents most parameters. The description adds no parameter-level detail and its reference to 'status LIVE' could imply a status parameter that does not exist in the schema, which slightly weakens the otherwise adequate baseline.

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

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

The description clearly states a specific action and resource: 'Schedule an outbound call.' This distinguishes it from instant-call siblings such as makeInstantCall and quickCall, though it does not name them 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 word 'Schedule' implies this tool is for future-dated calls rather than immediate ones, and the LIVE-activation note implies a workflow step. However, the description does not explicitly state when to prefer this over the instant-call alternatives or provide exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add a useful behavior by stating the return value includes training_status, implying asynchronous training. However, it does not explain that training runs in the background, that the clone may not be immediately usable, whether repeated calls overwrite or duplicate, or any authentication or rate-limit 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 concise sentences with no filler. The primary action is front-loaded, and the return behavior is stated in a single follow-up sentence. 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 description states the return value, which is useful since there is no output schema. But it omits the asynchronous training lifecycle, how to interpret training_status values, and whether the agent should later check listVoiceClones or poll for completion. Given the create-then-train workflow, this is a material 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?

The schema already documents most parameters with meaningful descriptions (provider, transcript, owner_email, metadescription), so schema coverage is high. The description adds only the contextual phrase 'training audio URLs,' which aligns with the required voice_clone_training_urls parameter, but does not add significant semantic value beyond the schema.

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

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

The description states a specific verb and resource: 'Upload training audio URLs and trigger voice cloning.' It clearly identifies this as the creation action and is easily distinguished from the sibling listVoiceClones, which lists existing clones. It also specifies the return value, reinforcing the purpose.

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

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

The usage is implied by the action 'trigger voice cloning' — an agent can infer this tool is for creating a new clone. However, there is no explicit guidance on when to use it versus alternatives, no prerequisites, and no mention of when not to use it.

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

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

With no annotations, the description carries the burden and does disclose the POST endpoint, direct synthesis behavior, and a playable audio file URL. However, it omits auth requirements, default provider, rate/cost considerations, and the fact that return_format can be base64 instead of a URL.

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 compact and front-loaded: endpoint, providers, and output are all present with no significant fluff. The word 'directly' adds marginal value and the provider list is a bit telegraphic, but nothing is wasted.

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

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

Core information needed to call the tool (endpoint, providers, output) is present, and the schema explains parameters well. Missing context includes how this relates to the many sibling TTS preview/list/call tools and the default return variant; for a parameter-rich tool with no output schema, it is adequate but not rich.

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 full descriptions for every parameter and an enum for provider, so the description's repeated provider list and URL note add little semantic value beyond the schema. Baseline 3 is appropriate because schema description coverage is 100%.

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 ('synthesize') and resource ('TTS audio') plus the endpoint and the output type. It is clearly distinct from call-making and preview siblings by saying 'directly' and mentioning a playable audio URL, though it does not explicitly name an alternative sibling.

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 explicit guidance about when to choose this tool over the many related TTS/call tools. It weakly implies direct generation rather than preview or calling, but it never states alternatives, exclusions, or selection conditions.

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

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

With no annotations, the description carries the behavioral burden. 'Get' and 'config' signal a read-only retrieval, and 'authenticated user' indicates auth context. However, it does not mention behavior for missing config, whether defaults are returned, or any side effects. It is adequate but not richly transparent.

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

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

One concise sentence with the verb and resource front-loaded. The field list is compact and directly informative, with no filler or repeated schema content.

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, but the description enumerates the return fields, which effectively serves as a return spec. The optional parameter is handled by the schema. Minor gaps include not clarifying what the 'active flag' controls or behavior when no config exists, but these are not blocking for a simple getter.

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 sole parameter owner_email is already fully documented in the schema ('Ignored for user API keys; required only with system API key'), so the description adds no parameter meaning. Schema coverage is 100%, which warrants the baseline 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?

The description uses a specific verb ('Get') and resource ('authenticated user's CEMAS config'), then enumerates the fields returned. This clearly distinguishes it from sibling tools like saveCemasConfig and quickCall. There is no ambiguity about what the tool does.

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 the obvious context — use it when you need the current user's CEMAS config — but it never explicitly says when to use it versus alternatives such as saveCemasConfig. No exclusions or prerequisites are stated. Usage guidance is present only by inference, not direct routing.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. 'Fetch' implies a read-only, non-destructive operation, and 'authenticated user' signals an auth requirement, but the description does not explicitly state that no side effects occur, that authentication is required, or what happens on auth failure. This is adequate but leaves some behavioral gaps.

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 no filler. Every clause adds information: the action, the resource, and the returned fields. It is appropriately sized for a zero-parameter tool.

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 zero-parameter getter, the description is nearly complete: it states the resource, the ownership scope, and the returned fields. There is no output schema, so the description does the work of explaining the return value. Minor gaps remain around explicit auth requirements and error behavior, but nothing prevents an agent from invoking this tool correctly.

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

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

The input schema has zero parameters, so there is little for the description to clarify. The baseline for a no-parameter tool is 4, and the description appropriately adds context by identifying which user profile will be returned, which is meaningful beyond the empty schema.

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

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

The description uses a specific verb ('Fetch') and a specific resource ('the authenticated user's profile'), and enumerates its contents (name, email, balance, preferences). This makes the tool's purpose immediately clear and distinguishes it from the unrelated sibling tools such as listVoices, createAgent, and generateTts.

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 clearly implies this is for retrieving the current authenticated user's profile, providing clear context. It does not explicitly discuss when not to use it or compare it to alternatives, but no sibling tool appears to serve a similar profile-fetching purpose, so explicit exclusion is unnecessary here.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' implies read-only behavior, and the description names the retrieved data, but it does not mention potential empty results, return format, or whether this depends on user authentication/session state. This is a minimal but acceptable level for a simple getter.

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, concise sentence with no filler. The key resource ('available DID / caller-ID numbers' and 'current SIP/VoIP provider') is front-loaded and clearly presented.

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

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

For a zero-parameter, read-only lookup tool, this description is nearly complete: it states exactly what data will be retrieved. Since there is no output schema, the description carries the burden of explaining return content, and it does so adequately, though it could add a note about the format or possible absence of data.

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

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

The tool has zero parameters, so the description need not explain any input semantics. The schema is empty and fully covered, and the description focuses on the return content rather than inputs, which is appropriate. Baseline 4 applies for no-parameter tools.

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

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

The description clearly states a specific verb ('Get') and resource ('user's available DID / caller-ID numbers and current SIP/VoIP provider'). It is unambiguous, but it does not explicitly distinguish itself from sibling tools that might also involve user data or configuration.

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, nor any mention of prerequisites or contexts where it is appropriate. The description simply states what it does without indicating when an agent should select it over other getter 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral details. It does not mention that this is a read-only operation, that owner_email is ignored for user API keys, whether rate limits apply, or what the response structure looks like.

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 very brief and front-loaded with the verb and resource, containing no fluff. However, it is terse to the point of under-specification, missing opportunities to provide useful context in the same small 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 tool with one optional parameter and no output schema, the description is too thin. It does not clarify what 'reports' include, whether filters are supported, what authentication context is needed, or what kind of data is returned. The agent would likely need to call the tool or inspect other docs to proceed safely.

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%: owner_email is described in the schema, including the conditional requirement. The description adds no additional parameter context, but per baseline rules 3 is appropriate since the schema already handles parameter documentation.

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 ('Get') and resource ('aggregate call reports / analytics'), so the core purpose is clear. However, it does not explicitly distinguish itself from sibling tools like listCallLogs or getProviderInfo, leaving some ambiguity about what counts as a 'report' versus a log.

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 exclusions, and no mention of prerequisites. The word 'aggregate' hints that it differs from raw call logs, but the agent is left to infer that connection on its own.

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 present, so the description carries the behavioral burden. 'Return the guide' clearly signals a read-only retrieval operation with no side effects, and the description names the exact artifact (skill.md) being returned. It does not mention authentication or output format, but for a zero-parameter documentation retrieval tool this is a minor 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?

The description is a single, front-loaded sentence that names the action, the artifact, and the guide's scope without any unnecessary words. The parenthetical explanation is compact and informative.

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

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

For a zero-parameter tool with no output schema, the description fully equips an agent to invoke it: it names the artifact, clarifies that it returns the onboarding guide, and previews the guide's contents. Nothing essential is missing for 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?

The tool has zero parameters, and the schema already fully documents this with 100% coverage, so no parameter-specific guidance is required. The description adds value beyond the empty schema by outlining what the returned guide covers, including the journey from sign-up to webhooks.

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 ('Return') with a specific resource ('CallRemind MCP onboarding guide (skill.md)') and enumerates the guide's coverage: signing up, quick calls, scheduling, agents, and webhooks. This clearly distinguishes it from the sibling tools, which perform operational actions rather than retrieving documentation.

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 'onboarding guide' framing makes the intended usage clear: call this tool when the agent or user needs the step-by-step product journey from sign-up through scheduling, agents, and webhooks. It does not explicitly mention alternatives or exclusions, but no sibling tool serves this documentation-retrieval role, so the context is sufficient.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It discloses that the tool returns audio in raw or WAV form and that clips are short, which is useful. However, 'depending on the call' is ambiguous, and there is no mention of side effects, rate limits, or prerequisites.

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 short and front-loaded, stating the main behavior in the first sentence. The second sentence provides a clear use case. Slight ambiguity in 'depending on the call' keeps it from being fully polished.

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

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

The description is adequate for a small preview tool, but the output format ambiguity ('raw or WAV depending on the call') is not resolved, and with no output schema or annotations, an agent may not know exactly what to expect or how to control the format.

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?

Input schema covers 100% of parameters with clear descriptions, so the baseline is 3. The tool description adds no extra parameter-level 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: generate a short voice clip with the Kokoro TTS engine and return audio. It clearly conveys the tool's core purpose. However, it does not explicitly differentiate from sibling tools like previewEdgeVoice or generateTts, leaving some selection ambiguity.

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 phrase 'Use to pick a voice' gives a clear intended usage context: previewing voices before selection. It does not mention alternatives or exclusions, but the guidance is explicit enough for a preview tool.

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 adds only the auth scoping detail ('for the authenticated user') but says nothing about pagination behavior, response shape, side-effect safety, or the auth-key distinction hinted at by the owner_email schema note. For an unannotated tool, this is thin.

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 efficient sentence with the verb and resource front-loaded and zero wasted words. However, at this length the brevity edges toward under-specification rather than maximally efficient completeness, so it does not earn a 5.

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

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

Given the absence of annotations and output schema, and a 3-parameter input carrying an auth nuance (owner_email ignored for user keys), the description is insuffiient. It does not mention pagination defaults, the system-key behavior for owner_email, or return vaues. An agent would have to guess at important calling context.

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 33% (solely owner_email has a description), so the description was expected to compensate, and it does not. It adds no meaning for limit, offset, or owner_email beyond what the parameter names already imply. The low coverage plus zero compensation warrants a below-baseline 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?

The description states a specific verb ('List'), a clear resource ('AI agents'), and a scope ('for the authenticated user'). This unambiguously distinguishes it from mutation siblings like createAgent and updateAgent, and from other list tools such as listVoiceClones or listLeads. It stops short of explicitly naming a sibling, but the resource is self-evident enough that an agent can identify the tool correctly.

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. It does not mention that createAgent/updateAgent are for mutations, nor how it differs from other list tools. The verb 'List' implies a read context, but no prerequisites, exclusions, or alternative conditions are given, leaving the agent to infer usage.

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

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

With no annotations, the description must carry the full behavioral disclosure burden. It implies read-only listing, but it does not mention pagination behavior, owner-email/auth constraints, rate limits, ordering, or whether results are date-rounded.

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 concise, front-loaded sentence with no filler words. It is efficient, though the description could be expanded with structured usage and behavior details without becoming bloated.

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

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

For a tool with no annotations, no output schema, and low parameter coverage, this description is too abbreviated. It omits when to use the tool, expected return shape, pagination semantics, and auth caveats, leaving an agent reliant on schema inference.

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

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

Schema description coverage is only 33%; only owner_email has a description. The description does not explain limit or offset and does not compensate for the schema's gaps, so an agent gets little parameter-level guidance beyond the defaults.

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 clear verb and resource: 'List past outbound call records.' The qualifiers 'past' and 'outbound' distinguish this from call-making siblings such as makeInstantCall and quickCall, though it does not explicitly name any alternative log/list tool.

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

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

No guidance is provided on when to use this tool versus siblings or when not to use it. The only content is a one-line purpose statement; there are no prerequisites, exclusions, or alternative tool mentions.

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 must carry the behavioral burden. The verb 'List' clearly signals a read-only, non-mutating operation, and the filter mention describes the main behavioral capability. It does not add deeper details like return shape, but for a simple listing tool this is reasonably transparent.

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 no filler. The primary purpose is front-loaded, and the supported filters are summarized efficiently.

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 listing tool with no required parameters and no output schema, the description covers purpose and filter options adequately. It could be more complete by stating what is returned or how this relates to sibling tools like previewEdgeVoice, but the core invocation path is clear.

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 67%, with q and lang documented and gender available via enum values. The description restates these filters with examples like 'en, ms, zh...' and adds the 'substring' wording, but it contributes limited meaning beyond the schema. It does not explain parameter combinations or edge cases.

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

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

The description names a specific verb and resource: 'List Microsoft Edge TTS voices' available for CEMAS / instant calls. It distinguishes itself from the sibling tool listVoices by explicitly scoping to Microsoft Edge TTS and the CEMAS/instant-call use 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?

The description supplies clear context: this tool is for listing Edge TTS voices used in CEMAS/instant calls. It does not explicitly name alternatives or when-not-to-use conditions, so it falls short of a full 5, but the context is strong enough to guide basic selection.

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 states the tool lists contacts/leads, implying a read operation, but it does not mention whether results are paginated, what the ordering is, whether it only returns owned leads, or any rate limits or side effects.

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 clear sentence with no redundant words. It is concise and front-loaded with the core action and resource.

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 three parameters, no annotations, no output schema, and no usage guidance, the description is too minimal. It leaves out pagination semantics, the meaning of owner_email, and any context about how the result set is scoped or ordered.

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 33%, with only owner_email documented in the schema. The description adds no meaning for limit, offset, or owner_email, and does not compensate for the low coverage. An agent must infer parameter behavior from names alone.

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 tool lists the authenticated user's contacts/leads, which is a specific verb and resource. It does not explicitly differentiate from sibling tools like createLead or listAgents, but the resource is distinct enough to be understood.

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 createLead, listAgents, or listScheduledCalls. The description implies a read/list operation but does not state conditions, exclusions, or 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 carries the full behavioral burden, but it only says 'List' without disclosing pagination behavior, auth/owner scoping, rate limits, or response shape. There is no explicit contradiction, but the description adds little beyond the operation name.

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 wasted words and a front-loaded verb+resource. It is concise, though the terseness leaves out meaningful operational detail addressed by other dims.

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 3-parameter list endpoint with no output schema and no annotations, this description omits pagination, return contents, auth requirements, and the meaning of owner_email. An agent cannot fully determine how to call it correctly from the description alone.

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 33% and the tool description does not describe any paramters. limit and offset have defaults but no semantic explanations, and owner_email's key-dependent behavior appears only in the schema, so the description does not compensate for the coverage gap.

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 planned outbound reminder calls.' The noun phrase clearly differentiates this from siblings like makeInstantCall or listCallLogs, and the scope is explicit without needing a title.

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 vs. alternatives, no exclusions, no mention of whether this is for retrieving upcoming scheduled reminders versus call logs or other call-related operations. An agent must infer usage from the tool 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?

With no annotations, the description carries the burden of behavioral disclosure. The verb 'List' implies a non-destructive read operation and the scope is clearly stated, but it does not mention authentication needs, response shape, or what 'available' means exactly (configured providers vs all possible providers).

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 conveys the purpose and enumerates the included providers without excesssive detail. Every part earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description is nearly complete. It names the exact providers and the scope ('static voices'). It could strengthen agent selection by noting how it differs from sibling list tools, but overall it provides enough context for a correct call.

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

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

The input schema has zero parameters, so there are no parameter semantics to explain. A baseline score of 4 is appropriate because no parameter compensation is needed.

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

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

The description uses a specific verb ('List') and identifies the resource ('available TTS providers and their static voices') plus the included providers. It is clear and understandable, but it does not explicitly differentiate itself from sibling tools like listVoices and listEdgeVoices, so it stops short of full sibling discrimination.

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 about when to choose this tool over its siblings. The description only states what it lists, leaving the agent to infer usage rather than providing explicit context or exclusions.

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

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

With no annotations, the description must carry behavioral transparency. It conveys the key scoping behavior (only the authenticated user's clones). But it does not disclose potential pagination, response shape, or whether any additional limits or side effects exist beyond the implied read-only 'List' 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?

A single, concise 9-word sentence that is front-loaded with the core action and scope. Every word adds value, with no fluff or repetition.

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

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

The tool is simple and the parameter is fully documented, but there is no output schema and the description does not mention the response format, pagination, or the system-API-key behavior that affects the owner_email parameter. This leaves an agent with some uncertainty about post-invocation expectations.

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% description coverage for the single optional parameter (owner_email), so the description adds no parameter-specific meaning. The baseline of 3 applies because the schema handles the semantic 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 uses a specific verb ('List') with a specific resource ('voice clones') and a clear scope ('owned by the authenticated user'). It is easily distinguishable from sibling tools like listVoices and listEdgeVoices, which target different object types.

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 clearly states the context: this tool returns voice clones that belong to the authenticated user. However, it does not explicitly contrast with sibling tools or mention when not to use it, 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?

With no annotations provided, the description carries the behavioral burden. It discloses the return shape ({ edge: [...], kokoro: [...] }) and the practical implication that voice IDs from either provider are usable. For a zero-parameter, read-only listing tool, this is sufficient transparency; only minor gaps like empty-list behavior or item shape remain.

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 packed sentences with no filler. The main action and scope come first, followed by the return structure and usage guidance. Every sentence earns its place.

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

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

For a zero-parameter list operation with no output schema, the description is complete: it states what is returned, from which providers, and how to use the result. No essential calling information 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?

The input schema has no parameters, so the baseline is 4. The description does not need to clarify parameter meanings since none exist. It adds helpful context about the returned voice ids being usable, which complements the empty schema.

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

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

The description uses a specific verb ('List') with a clear resource ('available TTS voices across providers'). It explicitly contrasts with narrower sibling tools like listEdgeVoices by showing it returns both edge and kokoro voices, making the tool's scope 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?

The description clearly indicates this is the place to retrieve voice IDs for either provider and that these IDs can then be used elsewhere. It does not explicitly name alternatives or state when not to use this tool, but the 'across providers' framing plus the listEdgeVoices sibling implies the distinction.

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 adds the valuable disclosure that secrets are redacted, and 'List' implies a read-only, non-destructive operation. It does not mention pagination or auth requirements for owner_email, but for a simple listing these are not critical gaps.

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 with no filler, front-loading the action and resource, and the note about secret redaction earns its place by adding meaningful behavioral context.

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 does not clarify the return shape beyond the implied 'list', and pagination is unmentioned. However, the tool is low-complexity, parameters are fully schema-documented, and the description covers the core behavior; it is minimally adequate with some inference required.

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 agent_id and owner_email already documented in the schema. The description adds no parameter-specific details beyond referring to 'an agent', so it provides no additional value over the structured schema.

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

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

The description states the specific operation ('List') and resource ('webhook configurations'), scoped to an agent and event types (on_call_start / on_call_end). It distinguishes this read operation from the sibling upsertWebhookConfiguration without needing to open 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?

The description makes clear what the tool does and for whom, but it does not explicitly say when to prefer this over the sibling upsertWebhookConfiguration, nor does it state any exclusions. The contrast between 'list' and 'upsert' is implied rather than 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 no annotations provided, the description carries the burden of behavioral disclosure. It reveals the expected output (API key + session) and that this is a login action, but it does not mention behavior on invalid credentials, session expiration, or any side effects beyond creating a session. Adequate but not deeply transparent.

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 no redundancy. The primary function and return values are stated first, and the sibling pointer to logoutUser is added efficiently at the end.

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

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

For a simple two-parameter login tool with no output schema, the description is largely complete: it states inputs, result, and logout counterpart. It could mention account prerequisites or error cases, but the core calling context is sufficiently covered.

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 covers both parameters with simple descriptions ('Account email', 'Account password'), so schema coverage is 100%. The tool description does not add further semantic detail beyond the fact that these are used for sign-in, which matches the baseline.

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

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

The description names the action ('Sign in'), the credentials used ('email + password'), and the result ('get the app API key + session'). It also explicitly differentiates itself from logoutUser, so an agent can tell this is the authentication entry point.

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 clearly states the tool's role for authentication and points to logoutUser as the counterpart for signing out. It does not mention when to use related auth tools like createNewUser or requestOtp, but the primary usage context is clear.

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

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

With no annotations provided, the description carries the burden, and it does well by explicitly stating the tool is stateless and that it clears the caller's stored key. This discloses the main side effect and distinguishes server-side vs client-side logout behavior. It could add idempotency or failure behavior, but the core transparency is strong.

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 deliver the action, its stateless nature, and the side effect without any filler. The most important information is front-loaded.

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 tool's zero parameters, no output schema, and simple operation, the description covers everything needed to invoke it correctly: what it does and what state it modifies.

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

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

The tool takes zero parameters, so the schema fully defines the input surface. The baseline for zero-parameter tools is 4, and the description does not need to add parameter detail.

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 ('Sign out') and resource ('current session'), and adds the defining side effect ('Clears the caller's stored key'). This makes the tool unmistakable and distinguishes it from login/session-related 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 intended use is implied by the action itself: call this to end the current session. However, there is no explicit guidance about when to prefer it over other auth-related tools, such as whether it should follow requestOtp/validateOtp or what to do when no session exists.

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 disclosing behavior. It mentions the endpoint and trigger semantics but does not explain call lifecycle, return behavior, side effects, prerequisites beyond agent_id, or any asynchronous/callback behavior. For a mutating trigger tool, this is a significant 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 concise, front-loaded sentences with no filler. The first sentence states the core action and endpoint; the second explains the three usage modes. Every phrase 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?

This is a 10-parameter tool with no annotations and no output schema, yet the description only provides a high-level overview. It does not explain conditional parameter relationships (e.g., voice_clone_id with QWEN), expected response shape, or operational semantics. An agent would need to infer too much to invoke it reliably in varied scenarios.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by mapping message to a template mode and clarifying that system_prompt/voice support a fully custom call. This helps an agent understand how parameters combine, which the schema alone does not convey.

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 action ('Trigger an immediate outbound AI voice call'), identifies the resource via the endpoint, and names the three invocation modes: existing agent, template message, or custom prompt/voice. This clearly distinguishes it from scheduled-call tools and makes its scope obvious.

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 implied usage context by noting the tool is for immediate outbound calls and describing three parameter-based modes. However, it does not explicitly compare against sibling tools like quickCall or makeInstantKokoroCall, nor state when not to use it.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does a good job by revealing that the call is outbound, one-way, immediate, always Kokoro-voiced, and that it pre-generates and plays a clip. It does not mention billing, failure modes, or required permissions, but the core side effects are clearly stated.

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 concise sentences with no filler. It front-loads the core action and immediate behavior, then adds the important pre-generation detail. Every part earns its place and it is easy for an agent to parse quickly.

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 side-effecting call tool with four well-documented parameters and no output schema, the description covers the essential selection and invocation context: directionality, timing, voice, endpoint, and pre-generation behavior. Minor gaps like return value, auth, and billing details remain, but they do not prevent an agent from understanding and invoking the tool correctly.

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

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

The schema already documents all four parameters with descriptions, and coverage is 100%. The description reinforces the meaning of message ('pre-generates... clip') and voice ('always voiced by Kokoro TTS'), but it does not add substantial new parameter-level information beyond what the schema 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 ('Place an immediate one-way outbound call') and names the exact endpoint. It clearly distinguishes this tool from siblings like makeInstantCall and quickCall by emphasizing that the call is always voiced by Kokoro TTS and pre-generates a per-recipient Kokoro clip.

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 need an immediate, one-way Kokoro-voiced call—but it does not explicitly state when to choose it over alternatives or when not to use it. No sibling tools are named, leaving the selection logic somewhat implicit.

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 disclosure burden. It does reveal the return format and that an Edge TTS synthesis occurs, but it does not mention side effects, network/API dependencies, auth requirements, output length limits, or failure 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?

A single, front-loaded sentence conveys the core action, the tool's scope, and the return format without wasted words. Every phrase contributes useful 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 synthesis tool, the description covers the key details: what it does, which voice family it uses, and the output encoding. Minor gaps remain, such as no explicit limits on preview length and no guidance versus sibling TTS tools, but it is mostly complete.

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

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

Schema description coverage is 100%, with each parameter (text, voice, rate, pitch, volume) already described and given examples. The description adds no additional meaning beyond what the schema provides, so the baseline score 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 action ('Synthesize a short preview clip') and resource ('Edge TTS voice'), and adds the output format ('MP3 bytes, base64 in the response'). This makes the tool's role clear and distinguishable from sibling call/voice-list tools.

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 use for previewing Edge TTS voices, but gives no explicit guidance on when to choose this over siblings like generateTts, quickCallWithEdge, or kokoroPreview. No alternatives, conditions, or exclusions are mentioned.

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 discloses that the call is immediate, one-way, outbound, and pre-generated via Kokoro TTS. However, there are no annotations to cover the tool's safety profile, and the description does not mention the external side effect of placing a real phone call, potential costs, irreversibility, or what happens after invocation.

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

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

The description is short and front-loaded with the core action in the first sentence. The second sentence clarifies prerequisites. The third sentence, 'Mirrors the MCP quickCall tool,' is mildly redundant but not harmful.

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 whose parameters are fully covered by the schema, the description provides enough to make a basic call. Missing pieces include when to choose this over sibling instant-call tools and what the caller should expect in return, especially since there is no output schema.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description adds the useful clarification that only phone and message are required, which aligns with the schema's required list, but it does not add meaning beyond that.

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 ('Place') and resource ('immediate one-way outbound call') and adds the qualifier 'voiced by Kokoro TTS (pre-generated)', which makes the action clear. It distinguishes from scheduled calls by saying 'immediate', but it does not explicitly differentiate from similar siblings like quickCallWithEdge or makeInstantCall.

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 statement 'Only a phone + message are needed' gives useful prerequisite context. However, there is no guidance on when to prefer this tool over alternatives such as quickCallWithEdge or makeInstantCall, and no exclusions or fallback conditions are provided.

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 burden of behavioral disclosure. It does reveal meaningful behavior: immediate, one-way, outbound, and Edge TTS powered with pre-generation. It does not, however, mention side effects, auth requirements, asynchronous behavior, or what happens after invocation, which are relevant for a real outbound call tool.

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

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

Two sentences with no filler. The core action is front-loaded, and the second sentence earns its place by differentiating from quickCall. This is appropriately concise.

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 four-parameter side-effecting tool with no output schema and no annotations, the description is reasonably informative but still leaves the agent uncertain about return value, failure behavior, or whether the call is queued versus completed before the tool returns. The gap is noticeable but not fatal for a straightforward call action.

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 all four parameters with clear descriptions, so the tool description adds little beyond that. It reinforces the Edge TTS/voice concept, but no additional nuance is needed for correct parameter usage.

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 distinct verb-resource pair: 'Place an immediate one-way outbound call voiced by Edge TTS (pre-generated).' It also differentiates from the sibling quickCall by explicitly presenting this as a 'Backup' that 'always uses Edge TTS', so an agent can recognize what it does 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?

The description names quickCall as the alternative and notes that this variant always uses Edge TTS, which implies when it might be preferred. However, it does not explicitly state when to use it versus when to avoid it, and 'Backup' is vague about whether it is a fallback or a voice-specific choice.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the side effect (sends a 6-digit code to the account email) and that the code is 'fresh', implying a new code is issued. It does not mention rate limits or error conditions, but the core side effect is explicit.

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 concise sentences plus an example, with the main action and key side effect front-loaded. Every sentence earns its place, and there is no redundant 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, no-output-schema tool, the description covers purpose, side effect, default behavior, and next step with an example. It omits the exact response shape, but that is not critical for a fire-and-forget OTP request, and the flow is clear.

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 description covers 100% of the single parameter, and the tool description reiterates that the email defaults to the configured key's account. This adds minimal meaning beyond the schema, so the baseline 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 states a specific verb ('Request'), a specific resource ('fresh email one-time sign-in code'), and even the HTTP endpoint. It clearly distinguishes itself from validateOtp by naming the next step, so an agent can tell these siblings apart.

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 clear usage context: this is the first step in an OTP authentication flow and the next tool to call is validateOtp. It does not explicitly list alternatives to avoid, but the sequencing guidance is strong enough for an agent to know when to invoke 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?

No annotations are provided, so the description carries the behavioral burden. It makes clear this is a write operation and adds a useful behavioral detail (voice_provider defaults to Edge TTS), but it does not disclose whether existing settings are fully replaced, what happens when optional fields are omitted, or what response/error behavior to expect.

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 no fluff. The first sentence states the action and fields, and the second adds a key default; information is front-loaded and 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?

For an 8-parameter mutation tool with no annotations and no output schema, the description gives enough to select the tool but leaves important invocation context (save/overwrite semantics, response/errors) to inference. The schema covers parameter details, so the gap is moderate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only high-level grouping and a default for voice_provider; it does not compensate for or add much beyond the already-complete schema parameter descriptions.

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

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

The description uses a specific action ('Save') and identifies the exact resource ('user's CEMAS destination phone(s), active flag, and voice prefs'), making the tool's purpose unambiguous and easily distinguishable from siblings like getCemasConfig and the call-making tools.

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 clearly implies this is the configuration-persistence tool, but it does not explicitly say when to use it instead of getCemasConfig, updateProfile, or call tools, and it gives no exclusions. Usage must be inferred from the save semantics and sibling names.

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 behavioral disclosure burden. It only says 'Update fields' and does not disclose partial-update semantics, required fields, permission requirements, return values, or side effects.

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, direct sentence with no wasted words. It is front-loaded with the action and resource, though it may be too terse to fully support correct invocation.

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 tool with no annotations and no output schema, this description is far too minimal. It omits critical information about update behavior, parameter roles, and expected outcomes, leaving the agent to infer too much.

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 33% (2 of 6 parameters have descriptions), and the description does not compensate by explaining what fields can be updated. The word 'fields' adds little meaning beyond the schema property names, leaving most parameters semantically underdocumented.

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 verb 'Update' and the resource 'existing AI agent', making the tool's purpose understandable. It distinguishes itself from createAgent by specifying 'existing', but it does not explicitly name or contrast sibling tools.

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 context is implied by the word 'existing'—use this when modifying an agent rather than creating a new one. However, there is no explicit guidance on when to choose this tool over createAgent or other sibling tools, and no alternative tools are named.

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 present, so the description carries the full burden of behavioral disclosure. It only says 'Update' without explaining whether updates are partial or full replacements, whether the operation is destructive, or whether any validation occurs.

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 short and front-loads the main purpose, with the parameter clarification placed second. It is efficient, though the brevity comes at the cost of omitting other parameter semantics.

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 four parameters, no output schema, and no annotations, the description is too sparse to fully support correct invocation. It explains only one parameter and provides no return or update-behavior context, leaving significant gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's silence. It explains max_talk_time_ms with a concrete example, but provides no meaning for name, profile_image_url, or default_sip_number, leaving three of four parameters semantically unexplained.

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 clear action ('Update') and resource ('profile fields'), so an agent can tell this tool is for modifying profile data. It doesn't explicitly differentiate from sibling update tools like updateAgent, but 'profile' provides enough distinctness in this context.

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 conditions, prerequisites, or exclusions are mentioned, leaving the agent to infer that it should be used whenever a profile update is needed.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create or update,' which signals mutation but does not explain upsert/overwrite semantics, idempotency, authentication requirements, validation behavior, or what happens to an existing configuration.

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 one short, front-loaded sentence with no filler. It is concise and scannable, though its brevity comes at the cost of behavioral and contextual detail.

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 mutation tool with no annotations, no output schema, and six parameters, this description is too thin. It omits important context such as owner_email's API-key-dependent requirement, webhook_secret purpose, is_enabled behavior, and expected 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?

Schema description coverage is about 67%, and the description adds only a light mapping of the resource to 'agent + event.' It does not clarify is_enabled, webhook_secret, or the conditions around owner_email, so it adds some value but does not fully compensate for the undocumented 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 ('Create or update') and names the resource ('webhook configuration for an agent + event'), making the tool's function clear. It is implicitly distinguished from the sibling read-only tool listWebhookConfigurations, though it does not explicitly name that distinction.

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 is used when a webhook configuration needs to be created or updated, but it gives no explicit when-to-use versus alternatives, no prerequisites, and no guidance about the user/system API key distinction referenced in the schema.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the side effect of fully creating the account, the optional password behavior, and the return value of the new API key. This is strong transparency for a mutation tool, though it does not mention whether the OTP is consumed or whether the operation is idempotent.

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 extremely concise: two sentences front-load the core action and then state the optional behavior and return value. Every sentence earns its place, and there is no redundant or filler content.

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 tool's moderate complexity, no output schema, and no annotations, the description explains the full flow: validate the email-based credentials, create the account, optionally set a password, and receive the API key. It is sufficiently complete for an agent to invoke correctly, though it could mention prerequisites like whether an OTP request must have occurred first.

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 all three parameters with descriptions at 100% coverage, so the baseline is 3. The description adds context by tying otp and ref to the emailed code and explaining that password is optional for login, but it does not significantly extend beyond the schema's own parameter descriptions.

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

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

The description states a specific action—validate the emailed OTP and code reference, then fully create the account—and clearly differentiates this from the sibling validateOtp by emphasizing account creation. It also specifies the optional password feature and the returned API key, leaving no ambiguity about the tool's purpose.

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 conveys the intended usage context: this is the final step after a user receives an emailed OTP, and it completes account creation. It does not explicitly list alternatives like validateOtp for OTP-only checks or requestOtp for sending the code, but the workflow implication is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior, required precondition ('signed-in account'), and return value. However, it does not mention behavior on invalid OTP, whether the code is consumed, error responses, or any security/session requirements beyond the signed-in account.

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 compact and front-loaded: a clear action statement, endpoint, usage sequence, and a useful example. Every sentence earns its place and there is no redundant or filler content.

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 two parameters and no output schema, the description covers the essential call flow, input example, and return shape. It could be more complete by mentioning invalid-code behavior or when to include 'email', but the core usage is sufficiently specified.

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 both 'otp' and 'email'. The description adds a concrete example using only 'otp' and shows the expected output, but it does not clarify when the optional 'email' parameter should be provided or add meaning beyond the schema.

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

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

The description uses a specific verb ('Validate') with a concrete resource ('email one-time code'), states the outcome ('return the account's API key'), and gives the exact endpoint. It clearly differentiates this from the sibling requestOtp by saying to use it after that step.

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 explicitly says 'Use after requestOtp', giving the agent a clear sequencing instruction. It does not discuss when not to use the tool or compare it to other auth-related siblings like loginUser, but the primary usage context is established.

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

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

With no annotations, the description carries full behavioral disclosure. It states the operation (profanity check), the input language coverage, and the return shape ({ safe, found, languages }). It doesn't mention side effects or error behavior, but for a validation tool the core behavior is well disclosed.

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

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

A single sentence that front-loads the purpose, includes the relevant languages, the endpoint, and the return shape. Every part adds value and there is no 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 one-parameter validation tool with no output schema, the description explains what it does, when to use it, the input, and the response. Nothing essential is missing.

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

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

Schema coverage is 100% and the schema already describes 'text' as 'The text/message to check'. The description adds minor context about the message being spoken but provides no additional parameter details such as length limits or formatting, so the baseline score 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 ('Check') and resource ('a message for profanity / swear words') and specifies supported languages. It clearly distinguishes itself from the sibling tools, which are all call-making or configuration tools.

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 phrase 'before it is spoken' provides clear context for when this tool is appropriate. While it doesn't explicitly name alternatives or exclusions, none of the sibling tools perform a similar safety-check function, so the context is sufficient.

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