Amazon Connect MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes due to domain prefixes (cases_, config_, contacts_, etc.), but there are a few overlapping areas: list_domains_for_instance vs cases_list_domains, and ai_list_quick_responses/ai_search_quick_responses/qic_search all deal with quick responses/knowledge base search. These could cause some confusion, but the overall separation is strong.
Naming Consistency3/5
Naming follows a mostly consistent verb_noun pattern with domain prefixes (e.g., cases_create_case, config_list_users), but several tools lack these prefixes (get_case, create_case, search_contacts, list_queues, get_current_metrics). There are also outliers like qic_search and layout_visualizer that break the pattern. This mixed style is readable but not fully systematic.
Tool Count1/5
With 107 tools, the server is far beyond the typical well-scoped range and even beyond the 50+ threshold for extreme mismatch. The sheer volume makes tool selection overwhelming for an agent, even though the underlying service is broad. Many tools could be consolidated or grouped into sub-resources.
Completeness4/5
The server covers a wide breadth of Amazon Connect domains: instance management, queues, flows, contacts, cases, profiles, campaigns, analytics, AI, and onboarding. There are minor gaps such as missing update/delete operations for some config resources (e.g., queue has no update, user only has routing profile update) and no phone number claiming. Overall, the core workflows are well covered.
Average 2.8/5 across 95 of 107 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 states that the tool creates a routing profile, without mentioning required permissions, side effects, validation, or configuration details—critical for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise, but it under-specifies the tool's function and context. The sentence is essentially a restatement of the tool name, making it low-value rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and no behavioral description, yet the description provides only a single sentence. There is no explanation of what a routing profile is, what fields are required, or what the output will be, so an agent cannot reliably invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 6 parameters with 0% description coverage, and the tool description provides no parameter-level meaning beyond the field names. It doesn't clarify the format of media_concurrencies, the required nature of name and default_outbound_queue_id, or how region/instance_id are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a routing profile.' directly restates the tool name, adding no new information about the tool's specific scope or behavior beyond the name itself. While it identifies the verb and resource, it fails to distinguish this from other routing profile tools in any substantive way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like config_list_routing_profiles or config_update_user_routing_profile. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states 'Create a case template,' which does not reveal side effects, permission requirements, or idempotency. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified and adds no value beyond the tool name. It does not earn its place because it omits critical information needed for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, an output schema, and no annotations, this description is far too minimal. It fails to explain the purpose of parameters, prerequisites, or the relationship to other case template operations, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its four parameters, and the tool description does not explain any of them. The agent cannot infer the meaning or expected format of 'name', 'domain_id', 'description', or 'required_fields' from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a case template' is a tautology, essentially restating the tool name 'cases_create_template' in natural language. It provides no additional clarification about the scope or meaning of the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as cases_update_template or cases_list_templates. The description simply states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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' without mentioning permissions, idempotency, side effects, or the nature of the created resource. This adds no information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but it is under-specified rather than concisely informative. It omits crucial details, so the brevity is a defect, not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, three required, and a complex config array, the description is far from complete. It does not explain how to structure a request, what time_zone formats are acceptable, or what the config array should contain, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the five parameters (name, config, region, time_zone, instance_id). Required fields and the structure of the config array are completely undocumented, leaving the agent without necessary semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create hours of operation' essentially restates the tool name with no added scope or detail. It identifies the resource and verb but does not distinguish it from other config_create_* tools or explain what 'hours of operation' means 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.
Usage Guidelines2/5
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 alternatives like config_list_hours_of_operations. The description lacks prerequisites, intended use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits such as read-only nature, permissions, or side effects. It simply says 'Get campaign state', offering no information beyond the implied read operation, leaving the agent without crucial safety and effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is short, it is under-specified and simply repeats the tool name. It does not add value, making it an inefficient use of the description field rather than a concise, informative statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a single parameter, the description lacks context about what 'state' includes, when to use this tool, and how it differs from related campaign tools. This incompleteness hinders correct selection and invocation, especially among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'campaign_id' with 0% schema description coverage. The description does not explain the parameter's meaning, format, or how to locate it, failing to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get campaign state' is essentially a restatement of the tool name 'campaigns_get_state', making it tautological. It does not elaborate on what 'state' encompasses or distinguish this tool from siblings like 'campaigns_describe'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states the action without any context about appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states that a queue is created. It does not mention potential side effects, required permissions, uniqueness constraints, idempotency, or how creation might affect existing resources. The mutation is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness should not come at the cost of all useful detail. 'Create a queue.' is under-specification rather than efficient writing, offering no structure or additional context to guide the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a required hours_of_operation_id, and numerous sibling configuration tools, the description is severely incomplete. It provides no operational context, no relationship to other resources like hours of operation or instances, and no explanation of expected behavior or output. The agent cannot use this description to correctly select or invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% schema description coverage, yet the description adds absolutely no parameter-level detail. It fails to explain what 'name', 'region', 'description', 'instance_id', or 'hours_of_operation_id' mean or how they relate to queue creation. This is a complete gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a queue.' simply restates the tool name config_create_queue, adding no new information beyond the verb and resource already present in the name. It is a tautology and does not distinguish this create operation from the many sibling configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as config_describe_queue, config_update_queue_status, or list_queues. There is no mention of prerequisites, ordering, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description adds no behavioral information. It does not disclose side effects, permissions, or any internal behavior beyond what the name already implies. The description is essentially a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but this is under-specification rather than conciseness. It provides no substantive information beyond restating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 an output schema (not visible here), the description is severely lacking. It does not explain what an AI session is, the expected outcome, or any contextual details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the parameters 'name' or 'assistant_id'. The agent has no idea what values to provide or the meaning of these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an AI session' clearly states the action (create) and the resource (AI session). This is specific enough to distinguish from sibling tools like get_session or clear_session, though it does not elaborate on what an AI session is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not explain the relationship to ai_list_assistants or ai_query_assistant, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Get' implies read-only, but the description does not explain what data is retrieved, whether authentication or specific permissions are required, or how 'real-time' behavior might affect results. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but under-specified. It reads more like a label than an explanatory description. The single sentence does not provide enough useful information to earn a higher score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to clarify what 'real-time agent data' actually includes. The ambiguous resource combined with zero parameter explanation makes the tool incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters (instance_id and queue_ids). With schema description coverage at 0%, the description must compensate but does not—it never mentions what these parameters control or how they affect the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'real-time agent data,' but the resource is vague—'agent data' could mean metrics, status, or profile information. It does not clearly distinguish from sibling analytics tools like analytics_get_metric_data or get_current_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The 'real-time' qualifier hints at a use case, but there are no explicit when-to-use or when-not-to-use instructions, nor any mention of sibling tools or conditions that would make this the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only says 'Update contact flow content' without mentioning that the update likely overwrites existing content, whether it requires special permissions, or what the response contains. It adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but this brevity is due to under-specification rather than effective conciseness. A single sentence that essentially restates the tool name does not earn its place, leaving critical information missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and four parameters, the description provides no context about behavior, return values, or required formats. For a mutation tool, this is grossly insufficient and fails to support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it does not mention any parameters or explain what 'content' should be (e.g., JSON format, constraints). The parameter names are somewhat self-explanatory, but the semantics are ambiguous, especially for the 'content' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the target ('contact flow content'), making the tool's purpose understandable. However, it doesn't distinguish this from sibling config tools like config_create_contact_flow or config_describe_contact_flow, though it is the only update- specific tool for contact flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what prerequisites exist, or how it compares to alternatives. It is a bare statement with no situational context, leaving the agent to infer usage solely 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is a bare phrase with no annotations to compensate. It does not disclose side effects, idempotency, whether recording is ongoing, or what happens if recording is already active. 'Start' implies a mutation but omits any safety profile or behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise but under-specified. It front-loads the action but fails to include any supporting context needed for correct invocation, making it more under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations, the description is inadequate. While an output schema exists, the behavioral semantics (e.g., what 'recording' entails, whether it requires an ongoing call, or how the voice_recording parameter affects behavior) are completely absent, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to parameters such as instance_id, contact_id, or voice_recording. The schema itself provides basic types and defaults, but the description does not clarify their roles, constraints, or the effect of the voice_recording flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'start' with the object 'contact recording', clearly indicating that the tool initiates recording for a contact. It distinguishes from sibling tools like 'contacts_stop_recording' and 'contacts_start_outbound_voice' by specifying recording rather than a call or task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention prerequisites (e.g., an active contact or call), nor does it contrast with related tools like 'contacts_stop_recording' or 'contacts_start_chat'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely says 'Create a customer profile' and does not mention side effects, idempotency, permissions, or behavior if a profile already exists. The mutation is implied but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified. It does not provide enough information to be considered appropriately sized for a tool with 6 parameters. It is more under-specification than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and an output schema that is not described, the description is grossly incomplete. It lacks context about what a customer profile is, required fields, uniqueness constraints, and expected return values. It is inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the 6 parameters. It adds no meaning beyond the input schema, which itself lacks descriptions. The agent gets no guidance on required domain_name or optional fields like email, phone, attributes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (customer profile), which is a specific verb+resource. It distinguishes from sibling tools like profiles_search and profiles_delete_profile, but it does not elaborate on what a customer profile entails, so it is clear but minimally detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. There is no mention of how it differs from creating a domain or when profile creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds no context beyond the literal 'list' operation—no mention of pagination, result format, read-only nature, or dependencies. This is not sufficient for an agent to understand side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words), but it is under-specified rather than appropriately sized. While it is front-loaded, it omits essential context that could be conveyed in one or two additional sentences, making it an ineffective use of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required parameter (instance_id), an output schema, and several sibling tools, yet the description provides no context about what is listed, how results are scoped, or what the output contains. It is not complete enough for an agent to use the tool correctly without extra inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the three parameters (instance_id, region, max_results). The description does not compensate for the missing schema documentation, leaving parameter meaning entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List contact flows.' clearly indicates a list operation targeting contact flows. However, it does not distinguish this from sibling tools like config_describe_contact_flow, config_create_contact_flow, or config_update_contact_flow_content, which also operate on contact flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites (e.g., requiring an instance_id) or scenarios where listing contact flows is appropriate, nor does it exclude other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. 'Merge duplicate profiles' implies a mutation but does not state whether the merged profiles are deleted, whether the operation is reversible, or what permissions are required. This is a severe gap for a destructive merge operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is exceedingly terse. While it is front-loaded, it is under-specified to the point of being unhelpful. It reads more like a label than a description, so it fails to earn its place as a complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a destructive merge operation with no annotations, the description is critically incomplete. It lacks any information about prerequisites, side effects, or behavior beyond the bare action. The presence of an output schema does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. While parameter names like main_profile_id and profile_ids_to_merge are suggestive, the description doesn't explain their exact roles (e.g., whether the listed profiles are deleted after merging) or the purpose of domain_name. The short phrase adds minimal semantic value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Merge duplicate profiles' clearly identifies a merge operation on profiles, distinguishing it from sibling tools like profiles_update_profile and profiles_delete_profile. It is concise and uses a specific verb plus resource, but lacks detail on the relationship between main_profile_id and profile_ids_to_merge, so it isn't a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no typical scenarios. It is a single phrase with zero context, so the agent is left without information about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states 'Update a customer profile,' providing no information about mutation semantics, required identifiers, side effects, or any other behavioral traits. This is completely opaque for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is structurally straightforward. However, it is under-specified to the point of being almost tautological, so while it is concise, it lacks the substance that would make it genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 2 required), lack of annotations, and zero schema descriptions, this description is severely incomplete. It does not explain update behavior, parameter usage, return values, or any operational context, making it inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It adds no meaning beyond the parameter names and types in the schema, leaving the agent without essential guidance on how to populate fields like email, phone, attributes, or why domain_name and profile_id are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and resource ('customer profile'), which distinguishes it from sibling profile tools like create, get, delete, and merge. However, it does not specify which fields can be updated or any scope constraints, so it falls short of a fully detailed purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as profiles_create_profile or profiles_merge. It does not mention prerequisites, required parameters, or any context for appropriate use, leaving the agent to infer usage solely 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. It does not mention whether the operation is read-only, side-effect-free, requires authentication, or has rate limits. With no annotations provided, the description carries the full burden and fails to give any transparency about what happens during execution or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence, which is appropriately short for a simple query tool. However, it is overly minimal, lacking any additional structure or detail that could help an agent. It is not verbose, but it under-specifies the tool's behavior and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and an output schema (though its content is unknown), the description provides insufficient context for correct invocation. It does not explain return values, error conditions, or usage scenarios, making it incomplete for an agent to reliably select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the lack of parameter explanations. It does not clarify the meaning of 'query_text', 'assistant_id', or 'max_results' beyond the raw schema. The description fails to add any semantic value to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Query an assistant for recommendations.' It indicates the tool queries an assistant to obtain recommendations, which is specific enough. However, it does not differentiate from sibling tools like ai_get_recommendations, which likely serves a similar purpose, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description provides no context, prerequisites, or exclusions. It does not mention how it relates to ai_list_assistants or ai_get_recommendations, leaving the agent to guess the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Delete a campaign' without noting whether the action is permanent, reversible, affects related resources, or requires special permissions. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, and it is front-loaded with the action. However, it is so brief that it borders on under-specification, but that is already penalized in other dimensions. As a concise statement, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations, the description is incomplete. It does not mention side effects, irreversibility, or any other contextual information that would help an agent decide or proceed. The output schema's existence does not compensate for the lack of safety or side-effect disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for campaign_id. The single parameter is left completely unexplained; the description does not specify what the ID refers to, how to obtain it, or any format expectations. The parameter semantics rely entirely on the schema's name and type, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a campaign' clearly states the tool's verb (delete) and resource (campaign), and distinguishes it from sibling tools like campaigns_create, campaigns_list, and campaigns_stop. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not clarify when to delete a campaign versus pausing or stopping one, nor any prerequisites or consequences that might trigger a choice. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but 'Get campaign details' reveals nothing about permissions, side effects, result scoping, or error conditions. It is purely a statement of action without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it is under-specified. It conveys a basic purpose but does not add details that could justify its short length. It earns a middle score for being front-loaded but lacking substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema present), the description could be minimal but still needs to help select it among many siblings. The lack of usage guidance and parameter explanation makes it incomplete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'campaign_id' with no description and 0% schema description coverage. The description does not explain what campaign_id represents, how it is used, or any constraints, leaving the agent with no additional semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a resource 'campaign details', clearly indicating the tool retrieves campaign information. However, it does not distinguish itself from sibling tools like campaigns_list or campaigns_get_state, which could also retrieve campaign-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The sibling tools include several campaign-related operations (list, get_state, etc.), but the description gives no context or exclusions, leaving the agent to infer when 'details' is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'Stop a campaign' with no information about side effects, idempotency, whether the campaign can be resumed, or if it triggers immediate termination of ongoing processes. This is minimal transparency for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, consisting of a single short sentence, but it is under-specified rather than appropriately concise. It lacks necessary context and reads more like a placeholder than a helpful tool description. The brevity comes at the expense of clarity and utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many sibling campaign tools and the lack of annotations, this description is far from complete. It does not explain the tool's role in the campaign lifecycle, preconditions, or consequences. An output schema exists, but the description still needs to convey operational context, which it entirely omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter (campaign_id), and the description does not compensate. 'Stop a campaign' implies the campaign_id identifies the target, but that is already obvious from the parameter name. No additional meaning is added about parameter format, sourcing, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stop' and a clear resource 'a campaign', which unambiguously identifies the core action. However, it does not differentiate this tool from siblings like campaigns_pause or campaigns_delete, so it loses a point for missing sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions (e.g., 'use campaigns_pause for temporary stops'). This is a clear gap given the many campaign-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'update,' which is a mutation, but does not disclose permissions, reversibility, effects on existing data, return values, or any other behavioral traits. This is a minimal disclosure, similar to the update_drive example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified and does not earn its place beyond restating the tool's name. It provides no additional context, making it closer to 'Process' in the calibration example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 2 required, no annotations, and an output schema, this description is completely inadequate. It does not explain what is updated, how the parameters interact, or what the output indicates, leaving the agent to rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters at all. The schema itself is the only source of information about domain_id, field_id, name, and description, but the description adds no semantic meaning to these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('a case field'), which differentiates it from sibling tools like cases_update_case (case-level update) and cases_create_field (creation). However, it does not specify the exact scope or what updating a field involves, so it falls short of full specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 cases_update_case or cases_create_field. The description lacks any context about prerequisites, use cases, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'Update a case template' and does not reveal side effects, idempotency, required permissions, or how missing/optional fields are handled, providing no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified. While it is appropriately short, the brevity sacrifices essential information, making it less useful than a more balanced description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no annotations, yet the description provides no operational context. Although an output schema exists and return values need not be explained, the description still fails to explain the update semantics or parameter interactions, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It does not mention any of the four parameters (name, domain_id, description, template_id), adding no meaning beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a case template' clearly identifies the action (update) and resource (case template), distinguishing it from siblings like cases_create_template and cases_get_template. However, it lacks any additional scope or elaboration, so it does not fully meet the highest standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions, leaving the agent without guidance on selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action 'Create a user,' but does not mention required permissions, side effects, mutability, or whether fields like password are mandatory. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal but under-specified. While 'Create a user.' is concise, it does not earn its place given the complexity of the operation; it omits critical information and is not appropriately sized for a 9-parameter create tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is completely inadequate. It does not explain what the response contains, dependent steps like user creation requiring security profiles, or any post-conditions. For a create operation with required dependencies, this is a severe gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds zero meaning beyond the parameter names. With 9 parameters including instance_id, routing_profile_id, and security_profile_ids, the description offers no explanation of relationships, defaults, or constraints, leaving the agent to infer everything from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a user.' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling tools that list, describe, or update users, though it doesn't explicitly mention the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like config_update_user_routing_profile or config_list_users. It also lacks prerequisites such as the need for existing routing/security profiles, making the usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states the creation action and does not disclose any side effects, required permissions, rate limits, or what happens upon creation. This is a significant gap for a tool that initiates a contact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or redundancy. It is front-loaded with the action. However, given the tool's complexity (5 parameters), the brevity borders on under-specification, but not to the degree of a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no schema descriptions, no annotations, and an output schema, yet the description is merely 'Create a task contact.' This is grossly insufficient for an agent to understand how to invoke the tool correctly, what inputs are needed, or what to expect in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% schema description coverage, and the tool description adds no parameter information. It does not explain the meaning or purpose of instance_id, contact_flow_id, name, attributes, or description. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a task contact.' clearly states the action (create) and the resource (task contact). This distinguishes it from sibling tools like contacts_start_chat and contacts_start_outbound_voice by the specific contact type. However, it does not elaborate on what a task contact is, which limits full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or comparison with sibling tools like contacts_start_chat. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'Update contact attributes' without revealing whether the update replaces existing attributes, merges them, requires special permissions, or what the response format is. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but it is under-specified rather than concisely complete. It contains no redundant text, but also no useful details that would justify a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple update operation, but the description offers almost no context. With no annotations and minimal text, the agent lacks information about mutation behavior, return values, or how this integrates with other contact operations. An output schema exists, but that does not compensate for the missing usage and behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for the three parameters. The 'attributes' parameter (an object with additionalProperties) is not described, and the tool name and schema names are all the agent has to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('contact attributes'), making it distinct from sibling tools like contacts_start_chat. However, it lacks any additional context to differentiate it from similar update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like contacts_start_* or describe_contact. The description gives no context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description merely restates the action implied by the tool name. It does not disclose side effects, permission requirements, validation behavior, or how missing optional parameters like region are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified for a tool with four parameters and a nested fields object. Its brevity results in a lack of useful content, so it is not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with nested objects and an output schema, a one-sentence description is severely inadequate. It does not explain the relationship to domains, templates, or fields, nor does it clarify defaults or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero information about the four parameters (domain_id, template_id, fields, region). It does not compensate for the absent schema descriptions, leaving the agent without guidance on required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new case' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_case, search_cases, and cases_update_case. It unambiguously identifies the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as cases_create_template or cases_create_related_item. There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Search quick responses.' gives no details about read-only guarantees, pagination, authentication, or what kind of search is performed. It implies a read operation but does not state it explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, and the purpose verb is front-loaded. However, it is under-specified: it is too brief to compensate for the missing parameter and usage information, though it is not a total tautology like 'Process'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This search tool has three parameters and an output schema, but the description gives no context about what 'quick responses' are, how search behaves (e.g., fuzzy vs exact), or how parameters refine results. The output schema exists but does not compensate for the lack of behavioral and semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not mention any of the three parameters (query_text, max_results, knowledge_base_id). The description adds no meaning beyond the parameter names themselves, leaving the agent to guess how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('quick responses'), so the basic function is clear. However, it does not distinguish this from the sibling tool 'ai_list_quick_responses', and does not specify any scope or filtering behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the similarly named 'ai_list_quick_responses' or other search tools. The description only states the action without providing context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions 'historical metrics' and 'ISO 8601 timestamps', but does not confirm whether this is a read-only operation, describe the response shape, or address pagination, timezone handling, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, containing no fluff. However, it is under-specified for a tool with five parameters and multiple optional fields, so it does not fully earn its place as the sole guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and no usage context, this description is largely inadequate. The output schema may explain return values, but the description still fails to cover parameter semantics, filtering options, or how this differs from other analytics tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at the timestamp format (ISO 8601) but fails to explain 'metrics', 'queue_ids', 'instance_id', or their relationships. The description provides almost no added meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('historical metrics'), and the phrase 'historical' distinguishes it from the sibling tool 'get_current_metrics'. While it could be more explicit about exclusion, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'get_current_metrics' or other analytics tools. There is no mention of scenarios, prerequisites, or filters, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It implies a read-only operation via 'List' but fails to mention pagination, required permissions, or whether it returns form templates versus evaluation instances. The description adds minimal extra context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core action, but it is under-specified. It is not a tautology, but it sacrifices necessary contextual information for brevity, making it minimally acceptable but not well-structured for a tool with a schema and siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool comes with an output schema and two parameters, yet the description does not explain what an 'evaluation form' is, how this relates to 'analytics_list_contact_evaluations', or what 'instance_id' refers to. The description is incomplete for a tool in a large API family, especially given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about the parameters. The agent receives no explanation of the required 'instance_id' or the optional 'max_results' with its default of 25, leaving the parameters entirely undocumented in both the schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List evaluation forms' uses a specific verb ('List') and a clear resource ('evaluation forms'), making the basic operation evident. However, it does not differentiate from the sibling tool 'analytics_list_contact_evaluations', which could be confused with this one, so it lacks full distinguishing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like 'analytics_list_contact_evaluations'. It provides no context for the intended use case, no prerequisites, and no exclusions, leaving the agent to guess from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'start an evaluation.' It does not explain side effects (e.g., whether it triggers asynchronous processing, whether it changes state, or whether it requires special permissions). The minimal wording gives the agent little to infer about operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and thus concise, but it is under-specified. It provides no context beyond the basic action, making this more under-specification than genuine conciseness. The structure is simple and front-loaded, but the content is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description fails to provide essential context such as what an evaluation is, how evaluation_form_id is chosen, or whether the operation is synchronous. For a tool with three required parameters and no annotations, this is too minimal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it does not. Only 'contact' implicitly corresponds to contact_id; instance_id and evaluation_form_id are left entirely unexplained. Without any parameter details, the agent cannot determine what values are expected or how they relate to the evaluation process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'start' and identifies the resource as 'an evaluation for a contact,' which clearly conveys the tool's core function. It is implicitly distinguished from sibling tools like analytics_list_contact_evaluations by the action 'start,' though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context for its role in the analytics workflow. The only implicit cue is the 'analytics_' prefix in the tool name, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only repeats the tool name ('Start a campaign'). It does not mention side effects, whether an existing campaign is required, state changes, or any operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, which is concise. However, it is underspecified rather than efficiently informative, so it does not fully earn its place for the needed context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and the existence of a simple schema, the description should provide context about when starting is appropriate, prerequisites, and possible effects. It lacks these, making it incomplete for operational use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (campaign_id) with 0% description coverage, and the description does not mention it at all. The parameter name is self-explanatory, but the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('start') and resource ('campaign'), clearly indicating the tool's core action. However, it does not distinguish from sibling tools like campaigns_resume, which could overlap in meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as campaigns_resume or campaigns_create. The description gives no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, error conditions, or return behavior. The term 'get' implies a read operation, but the description fails to elaborate on side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff, making it efficient. However, it is under-specified, sacrificing crucial details for brevity, which is not true conciseness but rather minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is incomplete for a tool with two parameters, one required. It lacks any explanation of what 'case domain details' includes, how region affects the request, or any relationship to other case domain operations, leaving significant gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two parameters (domain_id, region), and the description does not mention either parameter or clarify their meaning. The agent must infer the purpose of region and domain_id, with no semantic support from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get case domain details' clearly states the action (get) and resource (case domain), distinguishing it from list operations like cases_list_domains. However, it does not explicitly mention that it fetches a single domain by ID, which would fully differentiate it from related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as cases_list_domains or cases_associate_domain. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action and gives no information about pagination, domain_id requirements, or return format, which are important for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and free of fluff, but it is under-specified for a tool with two parameters and no annotations. It is concise but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's place among many case-related list operations, the description is insufficient. It doesn't explain the purpose of domain_id or max_results, nor how this listing relates to other case tools. The presence of an output schema doesn't compensate for missing parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (domain_id or max_results). The agent cannot infer the meaning or formatting of these parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists case fields, identifying a specific resource and action. It differentiates from siblings like cases_list_templates or cases_list_domains by naming 'fields,' though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description simply says 'List case fields,' leaving the agent to infer usage without any context about prerequisites or other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply says 'List case layouts' with no mention of read-only behavior, output format, pagination, or potential side effects. Even though listing is likely read-only, the description fails to state this, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus a tip), but this brevity comes at the cost of essential information. It is under-specified rather than efficiently concise, missing parameter context and behavioral details that a longer description would provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 2-parameter tool with zero parameter descriptions and no annotations, the description is incomplete for safe and correct invocation. The output schema exists but cannot compensate for the lack of parameter semantics. The tip points to layout_visualizer but doesn't fully contextualize when to use this list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the required 'domain_id' or optional 'max_results' parameters. An agent cannot infer what domain_id means or how max_results behaves from the tool description alone, so the description adds no value beyond the schema's raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'case layouts', making the core purpose obvious. The tip about layout_visualizer helps differentiate this listing tool from the design tool, though it doesn't distinguish from sibling list tools like cases_list_fields or cases_list_templates beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only indirect usage guidance via the tip: if you want to design new layouts, use layout_visualizer. It does not explicitly state when to use this tool (e.g., to view existing layouts before editing) or mention any exclusions or alternatives for listing. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states 'List case templates,' with no mention of pagination, domain scoping, authentication requirements, or side effects. This is insufficient for a tool with multiple sibling operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, but it borders on under-specification since it simply restates the tool's name. It is not verbose, but it also adds little information beyond what the name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and only two parameters, the description fails to explain key usage context such as the meaning of domain_id, the effect of max_results, or the structure of the returned templates. Given the large number of sibling template tools, this minimal description is not sufficient for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention domain_id or max_results at all. With no parameter information in either the schema or description, an agent has no help understanding required or optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'case templates,' distinguishing it from sibling tools like cases_create_template and cases_get_template. However, it is terse and does not clarify scope (e.g., by domain) or the relationship to the similar-sounding template_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as cases_get_template or template_list. There is no mention of required context, prerequisites, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the action without revealing behavioral traits such as read-only nature, permissions, or response characteristics. 'Get contact flow details' adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified rather than efficiently concise. It captures the core purpose but omits essential context, balancing brevity with inadequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, zero parameter documentation, and only a terse statement, the description is insufficient for a tool with three parameters and an output schema. The output schema exists, but the description does not help the agent understand when or how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. Although parameter names like instance_id and contact_flow_id are somewhat self-explanatory, the description provides no additional context or detail about them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('contact flow details'), clearly indicating a describe operation. It distinguishes from sibling tools like config_list_contact_flows and config_create_contact_flow, but does not elaborate on what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as config_list_contact_flows or config_describe_queue. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is only three words. It does not disclose whether the operation is read-only, whether it requires special permissions, or any other behavioral characteristics beyond the implicit verb 'Get'. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) and front-loaded, with no wasted language. However, it is so sparse that it provides minimal value beyond the tool name, though the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (two required) and an output schema, the description is far too minimal to be considered complete. It does not explain what inputs are needed (beyond their names) or any context about the queue being described, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (instance_id, queue_id, region). The agent is left with only the parameter names to infer meaning, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get queue details' clearly identifies the operation as a read/describe action for a specific queue, which distinguishes it from sibling tools like list_queues. However, it lacks specificity about what 'details' include and does not explicitly differentiate from related describe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_queues or config_describe_contact_flow. The description does not mention prerequisites like needing an existing queue_id, nor any context such as reading configuration vs. runtime state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get user details' without mentioning whether it returns the full user configuration, requires specific permissions, or how it behaves for nonexistent users. The output schema may cover return values, but the description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words and front-loaded with the verb, but it is under-specified. It essentially restates the tool name without providing additional structured context, making it minimally acceptable rather than well-rounded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, an output schema, and a large sibling set, the description is too sparse to be complete. It fails to explain the tool's context, when to use it, or any edge-case behavior. The output schema covers return values, but the description lacks the necessary surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameter meaning. It does not mention instance_id, user_id, or region, nor explain their roles or relationships. The parameter names are somewhat self-explanatory, but no additional semantic detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user details.' clearly uses the verb 'get' with the resource 'user details', indicating a read operation for a specific user. However, it does not explicitly differentiate from sibling tools like config_list_users or config_describe_contact_flow, though the singular 'user details' suggests a single-user lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer config_describe_user over config_list_users, nor does it state any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility for behavioral disclosure. The single sentence only states the basic action and gives no information about permissions, pagination behavior, or whether statuses are current or historical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is under-specified given the tool's complexity. It earns a middle score because it is not verbose, but it lacks valuable details that could be included without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and no parameter descriptions, the description is far too minimal to be complete. While an output schema exists, the agent still lacks contextual information about what 'agent statuses' means, what the region parameter does, or how max_results affects the list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (instance_id, region, max_results) with zero description coverage. The description does not mention any of them, forcing the agent to infer meaning solely from names and types, which is insufficient for instance_id and region.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List agent statuses.' clearly identifies the action (listing) and the resource (agent statuses). However, it does not differentiate from sibling tools like config_list_users or config_put_user_status, leaving ambiguity about what 'agent' means 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, required parameters, or scenarios where this tool is preferred over similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation via 'list', but does not disclose required permissions, pagination behavior, or response structure. Minimal transparency beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, making it concise. However, it is under-specified for a tool with three parameters and no other context, so the conciseness reduces the utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and no parameter descriptions, the description is far from complete. The output schema exists but its content is not summarized, leaving the agent without guidance on what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (instance_id, region, max_results). The description adds no semantic value beyond what the schema field names already imply, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('hours of operation'), making the core function clear. It does not explicitly differentiate from sibling tools like config_create_hours_of_operation, but the verb+resource adequately conveys 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information on when to use this tool versus alternatives, such as config_create_hours_of_operation. There is no mention of prerequisites, use cases, or exclusions, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'List', implying a read-only operation, but fails to disclose that instance_id is required, how pagination works with max_results, or any filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, but it is under-specified for a tool with three parameters. It does not waste words, but it also fails to provide useful contextual structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required instance_id and optional parameters, yet the description gives no context about how these are used or when the tool should be invoked. An output schema exists, but it doesn't compensate for the missing usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any parameter. It doesn't explain region, instance_id, or max_results, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists security profiles, which is a clear verb+resource. However, it is very minimal and doesn't distinguish from other config_list_* sibling tools beyond the specific resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. The agent must infer from the sibling list and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the burden of behavioral disclosure. It only says 'List users,' which implies a read-only action but does not disclose pagination behavior (max_results), the requirement for instance_id, or any side effects. The description adds no meaningful behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words ('List users'), which is extremely concise but under-specified. It essentially restates the tool name and does not earn its place by adding new information. This is closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, the description is inadequate for a tool with three parameters. An output schema exists, but the description does not explain input semantics or when to invoke the tool. This leaves the agent with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no explanations for the three parameters (region, instance_id, max_results). The agent must rely entirely on parameter names, which are not defined or clarified. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list) and resource (users), which distinguishes it from sibling tools that list other entities (e.g., hours of operations, phone numbers). However, it lacks scope context (e.g., instance-specific users) and does not explicitly differentiate from similar user-related tools like config_describe_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as config_describe_user or list_instances. It does not mention prerequisites, exclusions, or any context that would help an agent decide between listing users and other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states 'End a contact' without mentioning side effects, whether the contact must be active, or if the action is irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words) with no wasted words, but it is under-specified. It is not appropriately sized for a tool that would benefit from explaining the scope of 'end'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, this description is incomplete. It fails to explain what ending a contact entails, whether it is safe, or how it relates to sibling tools, making it difficult for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines two parameters (instance_id, contact_id) with no descriptions, and the tool description mentions neither parameter. The description adds no meaning beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'End a contact' uses a specific verb and resource, which is clear at a basic level and distinguishes this from start/transfer tools. However, it is essentially a synonym for the tool name 'contacts_stop', adding little new information and not detailing what 'end' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools such as contacts_stop_recording or contacts_transfer. The description lacks any context about the contact lifecycle, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely states 'Get case details' without revealing return format, error behavior, permissions, or whether the operation is read-only. This is a minimal disclosure that leaves significant behavioral aspects unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no unnecessary words. However, it is under-specified to the point of not earning its place as a useful description. It is a single phrase with no structure or additional information, which is more under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and an output schema not visible to the agent, the description is incomplete. It does not explain what 'details' includes, how to construct a request, or any nuances about regions or required fields. The presence of many sibling tools makes this incomplete context more problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for all three parameters (domain_id, case_id, region), and the description does not mention any parameters or their meanings. The description fails to compensate for the lack of schema descriptions, leaving parameter semantics entirely inferred from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get case details' clearly identifies the action and resource. However, it does not distinguish this from sibling tools like search_cases or cases_get_template, which also relate to case retrieval. It lacks scope specifics such as fetching by case_id, but the name provides some clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, when not to use, or how it differs from search_cases or cases_list_cases_for_contact. The one-sentence description offers no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description was expected to disclose behavioral traits such as uniqueness constraints, effect on existing domains, or required permissions. It simply states the action, leaving agents to infer consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is under-specified rather than concise, omitting essential context. It doesn't earn its place because it adds nearly no information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description still lacks critical context such as domain naming rules, default behavior of expiration days, or what happens on duplicate creation. For a simple creation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining parameters. It adds no information about domain_name or default_expiration_days, relying entirely on the schema's self-explanatory names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and resource (profile domain), distinguishing it from case-specific domain tools. However, it doesn't elaborate on what a profile domain is or its relationship to siblings like profiles_list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description doesn't mention when to create a domain versus listing or associating existing ones, nor does it specify any prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the create action and the 'outbound' type. It does not disclose side effects, required permissions, return behavior, or validation expectations, providing minimal transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise but severely under-specified for a tool with three required parameters and a nested object. It is not well-structured because it omits essential usage and parameter guidance, making it an under-specification rather than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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, no schema parameter descriptions, and a nested required object, the description is highly incomplete. It does not mention prerequisites, valid parameter values, or the campaign lifecycle, leaving most of the necessary operational context absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three required parameters (name, connect_instance_id, channel_subtype_config). It also gives no insight into the nested channel_subtype_config object structure, leaving the agent unable to construct valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('create an outbound campaign'), which unambiguously states what the tool does. It also distinguishes this from sibling tools like campaigns_list and campaigns_start by focusing on the create action for campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or relationships to sibling tools like campaigns_start or campaigns_describe. There is no context at all beyond the one-sentence purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'List quick responses' without mentioning pagination, sorting, response format, or whether it returns responses from all knowledge bases or only the specified one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. However, it is under-specified, lacking important context about scope and parameters. It is concise but not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters (one required) and a sibling search tool, the description is too sparse. It doesn't mention that quick responses are scoped to a knowledge base, nor does it clarify the difference between listing and searching. The output schema exists, so return values aren't needed, but the description still feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no explanation for 'knowledge_base_id' or 'max_results', although the parameter names and the default value are relatively self-explanatory. The description provides zero added meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List quick responses' uses a specific verb (List) and resource (quick responses), clearly indicating a read operation. However, it does not differentiate from the sibling tool ai_search_quick_responses, nor does it mention the knowledge base scoping implied by the required parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus ai_search_quick_responses or other list tools. It lacks any indication that this lists quick responses within a specific knowledge base, which is implied by the schema but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of disclosing behavioral traits. It fails to mention whether the operation is read-only, what it returns (even though an output schema exists, the description could note status values), prerequisites (e.g., instance must exist), or any side effects. The bare verb 'Get' implies safety, but this is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence that is front-loaded with the key action and resource. It avoids unnecessary words and is efficiently structured. It loses a point because it is under-specified to the point of not covering essential details, but for sheer conciseness it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context among many campaign and wizard tools, the description is too minimal. It does not explain what 'onboarding status' means, the typical use case, or how it relates to campaigns_start_onboarding and campaigns_get_state. The presence of an output schema helps with return values, but the behavioral and usage gaps make it incomplete for a tool with zero annotations and one undocumented parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, connect_instance_id, with no description, and the description adds no explanation. Schema description coverage is 0%, so the description must compensate, but it does not. The parameter name is somewhat self-explanatory as an instance identifier, but the tool description gives no context about what 'instance' refers to or how to obtain this ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('instance onboarding status'), and the scope ('for outbound campaigns'). It distinguishes this from sibling tools like campaigns_get_state, which covers general state, and campaigns_start_onboarding, which is a mutation. The specific phrasing leaves 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.
Usage Guidelines2/5
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 it should be used to check onboarding progress before starting campaigns, nor does it differentiate from campaigns_get_state or wizard_* onboarding tools. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond the literal action. There are no annotations, so the description carries the full burden, but it does not disclose side effects, reversibility, required permissions, or effects on ongoing campaign activity. This is a severe transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at three words, front-loaded, and contains no filler. It earns a perfect score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely minimal and does not provide context about the tool's lifecycle position, prerequisites, or relationship to sibling campaign tools. While the operation is simple, the lack of annotations and usage guidance makes the description insufficient for an agent to fully understand when and how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, campaign_id, but the description does not mention or explain it. With 0% schema description coverage, the description fails to compensate for the lack of parameter meaning, leaving the agent to infer that the campaign_id is the target of the pause.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pause a campaign' clearly states the action (pause) and the resource (campaign), distinguishing it from siblings like campaigns_start, campaigns_resume, and campaigns_stop. It is not a pure tautology because it converts the name into a grammatically complete sentence, but it lacks any additional scope or differentiation beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description does not mention prerequisites, when pausing is appropriate compared to stopping or resuming, or reference any sibling tools. The agent receives no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only says 'Add contacts' but does not explain whether duplicates are handled, whether the operation is idempotent, what the outbound_requests objects must contain, or what response is returned. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. However, it is so terse that it sacrifices essential context, making it less useful than a slightly longer description with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters, an unstructured array parameter, no annotations, and 0% schema coverage, the description is incomplete. It does not explain the outbound_requests schema, validation rules, or side effects, leaving the agent unable to construct a valid request confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the description does not compensate. It explains the high-level intent ('contacts') but does not clarify `campaign_id` type/format or the structure and required fields of `outbound_requests`, which is an array of arbitrary objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('contacts to dial list'), clearly indicating this tool modifies a campaign's contact list. While it lacks the term 'campaign', the parameter `campaign_id` and sibling naming make the purpose understandable and distinct from other campaigns_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as which campaign types it applies to or prerequisites like needing a started campaign. The description implies use for adding contacts to a dialing list, but does not state exclusions or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without any details about side effects, validation, or output, which is insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and additional context. It is appropriately short for a simple tool, but it feels under-specified rather than efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter, the description does not explain what a case domain is, any constraints on the name, or what the output will be. The presence of an output schema is not enough to compensate for the lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'name' parameter with no description, and schema coverage is 0%. The description does not add any semantic detail about the 'name' parameter, leaving the agent to infer its meaning from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a case domain.' which clearly identifies the verb and resource. However, it does not differentiate from similar tools like profiles_create_domain or explain what a case domain is, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus related tools like cases_associate_domain or cases_list_domains. There is no mention of prerequisites or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. 'Get' implies a read operation, but there is no mention of permissions, error cases, response structure, or whether the operation is safe/idempotent. This is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It earns its place by stating the core action, though its brevity borders on under-specification. Still, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema and existence of an output schema, the description is still too sparse. It fails to explain what a 'case template' is, why domain_id and template_id are required, or how this tool fits with sibling operations. The lack of any usage or parameter guidance makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage—both domain_id and template_id lack any explanation. The description adds no meaning to these parameters, leaving the agent to guess their purpose, format, or relationship to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get case template details.' clearly states the action (get) and resource (case template details). It is specific enough to indicate a fetch operation for a single template, distinguishing it from list/create/update siblings, though it does not explicitly differentiate from similar generic template_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as cases_list_templates or template_get. The description gives no context about prerequisites like needing a valid domain_id and template_id, nor any indication of preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only states 'list' without disclosing details like pagination, filtering behavior via region, result limits, or whether the operation is read-only. The agent gets no insight into side effects or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, containing no fluff or redundant phrasing. However, its brevity borders on under-specification, though this is not a matter of excessive length or poor structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two optional parameters, a vague resource concept, and an output schema present, the description is far too minimal. It does not clarify what constitutes a 'case domain', how region filters results, or what max_results controls, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention parameters at all. The agent only sees parameter names 'region' and 'max_results' with defaults and types, but no explanation of their purpose or expected values, forcing guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List case domains' uses a specific verb (list) and resource (case domains), making the core action clear. It differentiates from sibling tools like cases_create_domain and cases_get_domain, though it does not distinguish from other domain-listing tools such as list_domains_for_instance or profiles_list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description omits any context about scenarios, prerequisites, or distinctions from similar domain-listing tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It indicates a mutating operation ('Create') but does not disclose permissions, reversibility, idempotency, content format expectations, or effects of the 'region' and 'instance_id' parameters. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main verb, but the 'etc.' is a filler that reduces informativeness. While concise, it lacks structured detail that would help an agent parse the key decision points (e.g., enum values, content format). It is appropriately sized but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and an output schema, the description is too minimal. It does not explain the relationship between flow_type and content, the expected format of 'content', or how parameters like 'region' and 'instance_id' influence the operation. The output schema exists but the description still should provide context for the parameters, which it does only for flow_type in a partial way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at valid values for 'flow_type' (CONTACT_FLOW, CUSTOMER_QUEUE, CUSTOMER_HOLD) but leaves 'etc.' vague and says nothing about 'name', 'content', 'region', 'description', or 'instance_id'. The meaning of 'content' (likely a flow definition JSON) is completely unexplained, leaving agents to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Create a contact flow') with a specific resource, and briefly lists some flow types. It distinguishes from sibling tools like config_list_contact_flows or config_update_contact_flow_content, though it doesn't explicitly name them. The 'etc.' leaves some ambiguity about the full set of types, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about when creating is appropriate. It only mentions the available types, not how to choose between them or when to use update/describe tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of disclosing behavioral traits. 'List' implies a read-only operation, but the description omits any details about pagination (max_results), region filtering, instance scoping, or the shape of results beyond what the schema already shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at a single sentence with no wasted words. However, it is under-specified, providing only the most basic action without supporting context, so it is not genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation and the output schema is provided, which helps complete the picture. Still, the lack of usage guidance, parameter semantics, and behavioral details makes the description less complete than it could be for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. With schema description coverage at 0%, the agent gets no explanation of what 'instance_id', 'region', or 'max_results' represent in the context of routing profiles, nor how they affect the outcome.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List routing profiles' uses a clear verb ('List') and identifies the resource, making the core purpose immediately understandable. However, it does not differentiate this tool from similarly named list tools like config_list_queues or list_instances, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 config_create_routing_profile or other config_list_* tools. No prerequisites, exclusions, or contextual triggers are provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention side effects, asynchronous behavior, permissions, or what happens when the call is initiated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, making it concise and well-structured. However, it may be too terse for a tool with five parameters and significant behavioral context, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and zero schema description coverage, the description is far too sparse. It omits key context such as required parameters, side effects, and when to use this over sibling contact-start tools. The presence of an output schema reduces but does not eliminate the need for behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the five parameters or their roles. The schema lists required fields like destination_phone and contact_flow_id, but the description adds no parameter meaning beyond what the raw schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Initiate') and resource ('outbound voice call'), which distinguishes it from sibling tools like contacts_start_chat and contacts_start_task. However, it largely restates the tool name without adding much new semantic content, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention prerequisites, contact flow requirements, or why outbound voice should be chosen over chat/task, and sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description needs to disclose side effects, prerequisites, and failure behaviors. It merely says 'Stop contact recording' without explaining what happens to the contact, whether recording must be active, or whether the operation is reversible. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the action, but it could be considered under-specified. However, for conciseness alone, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two required parameters and an output schema, the description is inadequate. It does not explain the workflow, any prerequisites, or the effect on the contact. Given the lack of annotations and parameter details, the description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no meaning for the parameters instance_id and contact_id beyond their names. It does not clarify what types of values are expected or how they relate to the recording operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: stopping contact recording. It identifies the specific resource (contact recording) and the verb (stop). However, it does not differentiate from sibling tools like contacts_stop, which could be ambiguous, so it doesn't fully earn the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 contacts_stop or contacts_start_recording. The description provides no context for when stopping recording is appropriate or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation but does not mention permissions, response shape, or potential errors. The phrase 'Get details' is essentially a restatement of the tool name and adds no extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and object. There is no redundant fluff, though the brevity sacrifices substance. It is appropriately sized for a simple tool but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations, the description is incomplete. It fails to specify what details are returned, any filtering semantics, or edge cases. Although an output schema exists, the description still needs to orient the agent about the tool's role and constraints, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the purpose or format of the two parameters (contact_id, instance_id). 'Specific contact' weakly hints at contact_id but provides no meaning for instance_id, which is required but unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('details of a specific contact'), clearly indicating a single-object read operation. It distinguishes from siblings like 'search_contacts' by implying retrieval of full details rather than a search result, though it doesn't explicitly state what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'search_contacts' or 'cases_list_cases_for_contact'. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Get profile details' without disclosing read-only semantics, error behavior, required context (e.g., domain_name to disambiguate), or what the response contains. The presence of an output schema helps, but the description itself is silent on these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasteful words. It delivers the core purpose efficiently, though it sacrifices useful context for brevity. It is appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are covered, but the tool is part of a large sibling set with many similar operations. The description lacks usage context, behavioral disclosure, and parameter elaboration, making it incomplete for an agent to confidently select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (profile_id, domain_name). The names are self-explanatory, but the description does not compensate for the lack of schema descriptions, leaving parameter semantics entirely to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get profile details' clearly specifies the verb (get) and resource (profile details), making the tool's purpose obvious. While it doesn't explicitly differentiate from sibling tools like profiles_search, the name and description together suggest a direct retrieval of a single profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as profiles_search or profiles_update_profile. There is no mention of use cases, restrictions, or differences from sibling tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'List profile domains.' It does not disclose whether the operation is read-only, how pagination works, or if auth/session is required. The description adds no behavioral context beyond the simple verb 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single three-word sentence with absolutely no wasted words. It is front-loaded and to the point, though it is perhaps too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is too sparse to be considered complete. It lacks any context about the domain model, parameter behavior, or differentiation from similar list tools, making it difficult for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single parameter max_results with 0% description coverage, and the tool description does not mention it at all. The agent gets no explanation of what max_results controls or how to use it, so the description adds zero value beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'profile domains', making the basic purpose clear. However, it does not explain what a profile domain is or differentiate from sibling list tools like list_domains_for_instance or cases_list_domains, so it lacks full scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention any context, prerequisites, or situations where another tool should be preferred, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is expected to disclose behavioral traits. It only states 'Search cases' without mentioning pagination, result limits, filtering behavior, or whether it returns full case details. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, stating the core action. It could include more specifics but achieves brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, one required, and no annotations, and the description is only five words. Given the moderate complexity and absence of behavioral details, the description is inadequate for correct invocation without relying on schema field names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the five parameters (domain_id, region, max_results, filter_field, filter_value). It only mentions 'domain' which loosely maps to domain_id, leaving the other parameters semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' with resource 'cases' and a domain scope, distinguishing it from contact-specific case listing (cases_list_cases_for_contact) and single-case retrieval (get_case). However, it doesn't explicitly differentiate from other search tools like search_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 cases_list_cases_for_contact or get_case, or what filtering capabilities exist. The description lacks any contextual recommendation or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Delete a case,' implying destruction but not stating whether it's a hard or soft delete, what cascading effects occur, or any permission requirements. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is under-specified to the point of being minimally helpful, conveying only the verb and object without essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is complete in stating the core action, but it lacks information on side effects, return values, or interaction with related cases. The presence of an output schema helps, but the description still doesn't address anything beyond the basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (domain_id, case_id) with 0% description coverage. The description adds no explanation of what these parameters refer to or their formats, leaving the agent without necessary context for correctly constructing the invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'a case,' clearly distinguishing it from sibling tools like cases_create_case, cases_update_case, and cases_get_case. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without context, 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.
Behavior2/5
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 only says fields are updated but doesn't indicate whether it's a partial update, how existing values are handled, required permissions, or side effects on other resources. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler, making it efficient for quick reading. However, the brevity causes it to omit critical details, so it doesn't fully earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations and no schema descriptions, the description covers only the basic action. While an output schema exists and return format is not needed, update semantics, valid field names, and error or edge-case behavior are entirely absent, leaving an AI agent with incomplete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the 'fields' parameter via examples. It doesn't explain the roles of domain_id and case_id, nor the expected format or permissible keys of the fields map beyond string values. Parameter meaning must be inferred almost entirely from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update'), the resource ('case fields'), and provides examples ('status, assignment'), making its purpose unambiguous. It distinguishes itself from get/delete/create case operations, though it lacks explicit scope qualifiers about which case types or constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as cases_create_case or cases_list_cases_for_contact. It doesn't state prerequisites (e.g., the case must exist) or when this should be preferred over other case-related mutations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses that the action is an update and lists valid status values, but does not describe side effects, permissions needed, reversibility, or any impact on the queue. This is minimal and leaves significant uncertainty for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the action. The second sentence adds useful detail about allowed status values. It is efficient, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and an output schema (content unknown), the description is insufficient. It fails to provide context on how to obtain instance_id/queue_id, what the update entails, or any caveats. An agent would be under-equipped to invoke this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'status' parameter values (ENABLED or DISABLED) but does not clarify 'instance_id', 'queue_id', or 'region'. These are essential identifiers, and the description provides no guidance on their meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('queue status'), and the second sentence clarifies the allowed status values. It distinguishes from sibling tools like config_create_queue or config_describe_queue by focusing on status modification, though it could be more explicit about what 'queue' refers to in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g., whether the queue must exist), and no mention of exclusions. The description simply implies 'use this to update queue status' without contextual help or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Update', implying mutation, but reveals nothing about permissions, side effects, or whether this assigns a new profile or modifies an existing one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, its brevity borders on under-specification, lacking essential context, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema available, the description is insufficient for a mutation tool. It does not explain the effect of the update, required permissions, prerequisites, or how it interacts with related resources, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. While parameter names like 'user_id' and 'routing_profile_id' are self-explanatory, the description adds no meaning beyond the schema and fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('user's routing profile'), which clearly indicates the tool's function. It distinguishes itself from sibling update tools by targeting the user routing profile specifically, though it doesn't elaborate on what 'update' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply states what it does, without contextualizing its use relative to other routing profile tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says only 'Start a chat contact' and omits details such as permissions, side effects, return behavior, or async nature. This is a significant gap for a tool that initiates a contact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that wastes no words and contains no redundant information. It is appropriately front-loaded, though its extreme brevity limits the information actually conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and no annotations, the description is grossly incomplete. It provides no context about prerequisites, the role of the contact flow, participant display name, or what the output represents. The entire description is three words, which is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameter meaning. It does not mention instance_id, contact_flow_id, participant_display_name, or attributes, leaving all four parameters semantically undefined beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a chat contact' uses a specific verb ('start') and resource ('chat contact'), clearly distinguishing it from sibling tools like contacts_start_outbound_voice and contacts_start_task by specifying the chat channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the voice or task start tools, nor any exclusions or alternatives mentioned. The description only states the basic action without contextualizing its appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'transfer' without explaining side effects, permission requirements, or what happens to the existing routing. This is minimal and could leave an agent unaware of potential impacts like ending current interactions or requiring specific ACLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 object. However, it is arguably under-specified, though that is more of a completeness issue than a conciseness issue. It earns a 4 for its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations, the description is too thin. It does not mention constraints (e.g., selecting either a queue or a user), return behavior, or impact on existing interactions. The presence of an output schema reduces the need to describe return values, but essential usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some meaning by implying the target is either a queue or a user, which maps to user_id and queue_id, but it does not explain the required instance_id and contact_id, nor the relationship (e.g., whether exactly one target must be specified). This is insufficient for full comprehension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (transfer), the resource (a contact), and the target (queue or user). It is specific enough to distinguish from sibling contact tools like contacts_start_* or contacts_stop, none of which mention transfer. It lacks explicit differentiation from potential alternatives but the verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mention of prerequisites (e.g., contact must be active), and no exclusions. The description is purely functional and does not help an agent decide between this and other contact manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that it creates a related item, but does not mention side effects, permissions, validation rules, or what happens on failure. The mutation aspect is implied by 'create' but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It includes useful examples in parentheses without excessive detail, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters including a nested object, and has an output schema, but the description provides minimal context. It does not explain what 'related item' can be, how content should be structured, or what the return value represents. The description is far too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives examples of item_type ('contact, comment') but does not explain the content structure, domain_id, or case_id semantics. The content parameter is entirely opaque, leaving the agent guessing about required fields and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a related item' and identifies the target resource 'for a case', with examples (contact, comment) that help distinguish it from sibling tools like cases_create_case. It does not fully enumerate all possible item types, leaving some ambiguity, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While the name implies it is for creating related items, no explicit conditions, prerequisites, or exclusions are provided. Sibling tools like cases_update_case or cases_create_case are not referenced, so the agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination, permissions, error behavior, or data scope beyond the bare statement. It lacks the detail needed for a list operation that may have implicit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is efficient. However, it is somewhat under-specified, though for a simple tool it remains appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal. It does not mention pagination behavior (relevant to max_results), region filtering, or any usage context, making it incomplete for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the parameters (instance_id, region, max_results). It only vaguely references an instance, leaving the meaning and usage of optional parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (phone numbers), and the scope (for an instance). This distinguishes it from sibling config_list_* tools that target other resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions or alternative tool references. The usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Set agent's current status' without mentioning permissions, idempotency, side effects, or what values are expected, leaving the agent with insufficient behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no verbose content, making it appropriately front-loaded. However, it is so brief that it misses opportunities to add valuable parameter or usage context without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters and no annotations, a one-sentence description is inadequate. The presence of an output schema covers return values, but the description fails to provide context on parameter relationships, prerequisites, or expected behavior, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters. The agent must infer that agent_status_id likely comes from a list operation, but no such guidance is provided. The parameter names alone are insufficient given zero schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('agent's current status'), clearly indicating the action. It distinguishes itself from sibling tools like config_list_agent_statuses, which read statuses, and other config mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It simply states the action without contextualizing it relative to other tools or workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state safety, permissions, pagination behavior, or any other side effects or limitations. It adds little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource. However, extreme brevity borders on under-specification, though for a simple list operation it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are documented separately. The description is adequate for a basic list operation but lacks context about when to use it, any prerequisites, and behavioral details such as pagination. It is a minimum viable description but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (instance_id, max_results) or their semantics. The parameter names are self-explanatory, but the description fails to compensate for the lack of schema descriptions, leaving the agent to infer intent from names and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('queues') within a specific scope ('in an Amazon Connect instance'). It is unambiguous and distinct from other list-type tools by naming the resource, though it does not explicitly differentiate from siblings like config_list_contact_flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, when not to use it, or any related tools that might be more appropriate for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency, but it only mentions ISO 8601 format. It does not disclose pagination, ordering, read-only nature, or any other behavioral traits, leaving the agent without safety/performance clues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, perfectly concise and immediately states the core action. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a 4-parameter tool. While an output schema exists (covering return values), the description lacks parameter semantics, usage context, and behavioral details, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains the time range format, but does not clarify instance_id, max_results, or the exact meaning of time_range_start/end beyond 'within a time range'. Partial compensation, insufficient for all four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches contacts within a time range, using a specific verb and resource. However, it does not distinguish this search from sibling tools or clarify what 'search' means (e.g., which contact fields are searched).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor are there exclusions or context hints. The description only states what it does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. 'Customize' implies a mutation, but the description does not disclose whether changes are persistent, reversible, require permissions, or how 'overrides' are applied. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded, but it largely restates the tool name. 'With specific overrides' adds only marginal value since the schema already documents the overrides parameter, so the sentence does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, including a nested overrides object, and an output schema, yet the description is only one sentence. It does not explain usage context, differences from sibling tools, or any behavioral caveats, making it inadequate for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the baseline is 3. The description's phrase 'specific overrides' adds minimal meaning beyond the schema's already-clear 'Dictionary of values to override in the template'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Customize' with the resource 'template', and 'with specific overrides' clarifies the scope. However, it does not distinguish this tool from sibling template-modification tools like cases_update_template, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as template_list, template_get, or cases_update_template. There is no mention of exclusions, prerequisites, or fallback scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 burden. It only says 'List evaluations for a contact' without disclosing sorting, filtering, pagination, or the need for an instance_id context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the verb. However, it is so minimal that it borders on under-specification, though not as extreme as a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters and no annotations, the description is too sparse to be contextually complete. It does not explain the role of instance_id, what counts as an evaluation, or when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a vague hint about contact_id via 'for a contact', but gives no explanation of instance_id or how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists evaluations for a contact, using a specific verb and resource. It distinguishes from sibling tools like analytics_list_evaluation_forms, which lists forms, and analytics_start_contact_evaluation, which starts an evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention exclusions, prerequisites, or related analytics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source for behavioral disclosure. It states only that onboarding is started, without indicating whether the operation is asynchronous, what side effects occur, or what system state changes, which is minimal for a process-initiating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise. However, it borders on under-specification, sacrificing clarity for brevity, though it still earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers only the immediate action and lacks context about the onboarding workflow, expected outcomes, and how it fits with sibling tools. Given the tool's complexity and the existence of related onboarding operations, the description is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The tool description adds no additional semantic information about parameters such as encryption or instance ID, making the description no more helpful than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('start') and resource ('instance onboarding for outbound campaigns'), making the core purpose clear. It is distinguishable from sibling tools like campaigns_start, which likely starts a campaign itself. However, it does not explicitly differentiate itself from related onboarding tools such as campaigns_get_onboarding_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when onboarding is needed, or relationship to other campaign lifecycle tools, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only repeats the action 'create' and points to another tool for JSON generation, without explaining side effects, required permissions, or behavior on existing layouts. The description adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The tip is a separate, informative line that earns its place. However, it is arguably too terse, omitting essential operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three parameters and no annotations, the description is incomplete. It provides no guidance on domain_id or name, no mention of how to structure content, and no indication of the return value or success/failure behavior. The pointer to layout_visualizer is useful but does not fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only hints that 'content' is a JSON structure via the layout_visualizer tip, but leaves name and domain_id unexplained. Minimal added meaning, not enough to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a case layout.' This is a specific verb+resource pairing. However, it does not explicitly distinguish this tool from sibling tools like cases_create_template or cases_create_field; the resource name 'layout' provides enough clarity, but the differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip explicitly recommends using layout_visualizer for visual drag-and-drop design, implying this tool is for programmatic/layout creation when you already have the JSON structure. This provides clear context and an alternative, though it does not explicitly state when not to use this tool or mention other create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state side effects, permissions, error conditions, or output specifics. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, and the description states the core action. However, it lacks usage guidance, parameter clarification, and explicit behavioral context, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, instance_id, with 0% description coverage. The description does not mention or clarify the parameter, relying solely on the parameter name, which is somewhat self-explanatory but still lacks explicit compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Amazon Connect instance details'), clearly conveying a single-instance detail lookup. It distinguishes from sibling list/create/delete instance tools, but does not explicitly contrast with list_instances, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_instances or delete_instance. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. It states 'delete' but does not disclose whether deletion is permanent, reversible, cascades to other data, or requires special permissions. For a destructive operation, this lack of transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action and object. It contains zero filler words and every word contributes to clarity, making it an example of highly efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and the tool is relatively simple, the overall context is thin for a destructive operation. The description lacks any mention of side effects, irreversibility, or when this tool should be invoked, making it incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of the required parameters (profile_id, domain_name). The description fails to add any meaning about what these parameters represent, how they relate to the deletion, or their expected values, leaving the agent completely dependent on bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a customer profile' clearly states the action (delete) and the resource (customer profile). It effectively distinguishes this tool from sibling profile operations like create, update, search, and get, which all handle different lifecycle stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives, no mention of prerequisites, or when deletion is appropriate. The description provides no context about the operation's place in the profile lifecycle or any exclusions, so it offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the wizard creates resources, is idempotent, requires permissions, or what side effects occur. It only states the action without any behavioral detail, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately concise, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and clear parameters, the description lacks essential context about what the setup wizard does, what it returns, or how it fits into the broader tool ecosystem. The brevity leaves the agent without enough situational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive parameter text, including the enum values for use_case and a default for region. Therefore, the description does not need to add parameter explanations; the schema already provides sufficient semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the resource ('Amazon Connect setup wizard'), making the primary purpose understandable. It is not explicitly differentiated from sibling wizard_* tools like wizard_execute_onboarding, but the setup-specific phrasing offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what prerequisites exist, or how it relates to alternatives like wizard_execute_onboarding or wizard_update_onboarding_state. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'List outbound campaigns,' which indicates a read-only operation but fails to disclose pagination (max_results), ordering, side effects, or permissions. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is efficiently short, though its brevity sacrifices detail that would help in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. However, the description gives no context about the domain of outbound campaigns, how to distinguish this listing from other sibling operations, or any prerequisites. For a tool with no annotations and an incomplete parameter story, the context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. While the parameter names are somewhat self-explanatory, the description adds no meaning about how max_results behaves or what connect_instance_id refers to. This leaves the agent without semantic guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a specific resource 'outbound campaigns,' which clearly differentiates it from sibling tools like campaigns_create, campaigns_describe, and campaigns_get_state. This is a concrete, non-tautological statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' implies this tool is for enumerating outbound campaigns, establishing a basic usage context. However, it does not explicitly mention when to use it over alternatives like campaigns_describe or campaigns_get_state, nor does it state any exclusions. The guidance is purely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but only states the operation type (get) and provides no information about side effects, error behavior, or data handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema covers return values, the description lacks contextual information such as when a session is valid or how recommendations are generated, making it insufficient for understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics by mentioning the session context, but it does not explain the role of assistant_id or max_results, and the schema provides no descriptions, leaving the user without sufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource 'AI recommendations' scoped by 'for a session,' which clearly identifies the action and distinguishes it from sibling tools like ai_query_assistant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as ai_create_session or ai_query_assistant, or any prerequisites for a valid session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'List knowledge bases' without mentioning read-only nature, return content, pagination, error behavior, or authorization requirements. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the core action. No filler or redundant information exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one parameter), the description lacks essential context such as usage guidance, behavioral characteristics, and any mention of prerequisites or limitations. With no annotations and no schema descriptions, the description is too sparse to fully equip an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'assistant_id' with no description (0% coverage). The description adds little beyond the parameter name: 'for an assistant' only echoes the property name without explaining where to find the ID, format, or meaning. The added semantic value is negligible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'knowledge bases' and context 'for an assistant', making the tool's purpose clear and distinguishing it from sibling tools like ai_list_assistants or ai_list_quick_responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, when not to use it, or any prerequisites. The description only states what the tool does, not how to decide to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and only says 'List', implying a read operation. It does not disclose pagination behavior, domain scoping requirements, output format expectations, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no repetition or fluff. Every word contributes to the core meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still omits critical context such as domain scoping, pagination via max_results, and the relationship to sibling tools like search_cases. For a tool with two required parameters and no annotation coverage, this is too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it only clarifies the contact relationship via 'linked to a contact'. The domain_id and max_results parameters remain unexplained, leaving the agent to infer their meaning from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'cases', and the limiting scope 'linked to a contact'. This is specific and distinguishes it from generic case listing or searching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives like search_cases. The description implies a use case but provides no prerequisites, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose one behavioral trait beyond the schema: fetching all queues when queue_ids is omitted. However, it omits other behavioral details such as required permissions, rate limits, or result structure (though the output schema covers return values).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the core purpose, and no wasted words. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are documented. However, the description is sparse on context: it doesn't explain the required instance_id, the valid values for channel, or how this tool relates to similar analytics tools. The conditional queue_ids behavior is a positive, but overall the description leaves important gaps for an agent to fully use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 lack of parameter documentation. It only explains queue_ids behavior ('If no queue_ids provided, fetches all queues first'), but leaves channel and instance_id completely unexplained. This is insufficient for an agent to understand all parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get real-time metrics for queues and agents.' This is a specific verb+resource, but it does not explicitly distinguish itself from sibling tools like analytics_get_metric_data or analytics_get_current_user_data, though the real-time queues/agents focus provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over alternatives. The only usage hint is the conditional behavior with queue_ids ('If no queue_ids provided, fetches all queues first'), which is more about input handling than usage context. No alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the core action but does not mention any side effects, authentication requirements, rate limits, case sensitivity, or whether it returns full content or just metadata. For a read/search operation, more detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is front-loaded with the verb and immediately states the resource and key constraint, earning a perfect score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 3 parameters, no annotations, and the description is minimal, the context is incomplete. It lacks information about the search methodology, expected response structure (despite an output schema existing), and any limitations. The description does not fully equip an agent to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to search_expression by specifying 'exact name match', but it does not elaborate on knowledge_base_id or max_results. Since the parameter names are somewhat self-explanatory, this is minimally adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search content in a knowledge base by exact name match' clearly identifies the action (search), the resource (content in a knowledge base), and a key constraint (exact name match). This distinguishes it from sibling tools like ai_query_assistant, ai_list_knowledge_bases, and ai_search_quick_responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when to prefer other search tools such as search_contacts or qic_search. The implied usage is only that it is for exact name matching, but no alternatives are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. The verb 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention pagination, limits, or result ordering. This lack of additional behavioral context gives little beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and resource. It contains no filler words, making it appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the action is straightforward, the description is mostly sufficient. The agent can invoke the tool without ambiguity, though it does not clarify the scope of 'Amazon Q assistants' or whether all assistants are returned. The output schema likely covers return structure, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema confirms an empty object. The description does not need to explain parameter meaning because none exist. This matches the baseline for 0-parameter tools, scoring 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('Amazon Q assistants'), which accurately conveys the tool's function. However, it does not explicitly distinguish this tool from sibling list tools like ai_list_knowledge_bases or ai_list_quick_responses, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about prerequisites, exclusions, or scenarios where this tool is preferred over similar list tools, offering no usage direction beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and allowed types, offering no insight into side effects, permissions, idempotency, or error behavior. For a write operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main action front-loaded and a compact list of types. Every word earns its place, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to explain return values), the description is incomplete for an agent to confidently invoke the tool. It does not explain what a 'domain' is in this context, whether creation is idempotent, or any constraints beyond field_type. The description leaves too many unanswered questions for a 4-parameter tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage (no parameter descriptions), and the description only adds meaning for field_type by listing allowed values. It leaves domain_id, name, and description completely unexplained, forcing reliance on parameter names alone. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a custom field' with a specific verb and resource, immediately distinguishing it from sibling tools like cases_list_fields (list) and cases_update_field (update). The list of allowed field types further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating custom fields, but does not explicitly state when to use it over alternatives or mention any prerequisites. The absence of any exclusions makes it minimally acceptable, but the guidance is only implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only states the basic action. It does not mention that creating an instance can be time-consuming, may incur costs, requires AWS credentials, or has side effects beyond the creation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and output schema cover parameter details and return values, the description lacks essential context for a resource creation operation, such as typical provisioning time, potential failures (e.g., alias already exists), or the need to verify via describe_instance. It is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters (region, instance_alias, inbound_calls_enabled, outbound_calls_enabled, identity_management_type). The description adds no parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Amazon Connect instance' uses a specific verb (create) and a clear resource (Amazon Connect instance), which fully distinguishes it from sibling tools like describe_instance, delete_instance, and list_instances. No ambiguity exists about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as describe_instance or list_instances. The description does not mention prerequisites, follow-up steps, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It implies a read operation ('Get') and notes that the response includes LLM guidance, which is a useful behavioral trait. However, it doesn't explain what the guidance entails or how it should be interpreted, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in the first sentence and a brief note in the second. There is no wasted words or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is functional but not fully complete. The mention of 'LLM guidance' is vague and could confuse the agent about response format or usage. No error handling or fallback behavior is described, and the relationship to other template tools remains unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, category, subcategory) already well-documented. The description only repeats 'category and name' and does not add meaning beyond the schema, nor does it mention subcategory. This aligns with the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific template by category and name, using a specific verb and resource. It doesn't explicitly differentiate from sibling tools like template_get_case_workflow or template_get_routing_workflow, but 'specific template' implies a direct get operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as template_list or template_get_case_workflow. The mention of 'LLM guidance for proper usage workflow' is a feature of the response, not a usage guideline, and no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'List available templates,' which implies a non-destructive read operation, but does not elaborate on what 'available' means, whether the result is filtered by permissions or status, or whether the category parameter affects the output. For a tool with zero annotation coverage, this is a thin behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loading the action and resource with no wasted words or repetition of the tool name. It is appropriately concise for a straightforward listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and an output schema, so the description need not explain return values. However, given the large sibling set and the absence of any usage guidance, the description feels minimally complete: it states the purpose but leaves the agent to infer when to choose this tool over similar listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'category' parameter with a full description of allowed values, and schema description coverage is 100%. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List') and resource ('available Amazon Connect configuration templates'), specifying exactly what the tool does. It distinguishes itself from sibling tools like cases_list_templates and template_get by focusing on 'configuration templates' rather than case templates or individual retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With many sibling listing tools (e.g., cases_list_templates, config_list_contact_flows, ai_list_quick_responses), the description gives no contextual hints for tool selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the state change but does not specify behavior if the campaign is not paused, required permissions, error conditions, or side effects. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancies. Every word serves a purpose, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is minimally adequate. However, it lacks guidance on when to use resume versus start, what constitutes a valid paused campaign, and any operational constraints. It is incomplete but not critically so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required string campaign_id with no description (0% coverage). The tool description does not mention the parameter or provide format/source details, so it adds little value beyond the field name. The context from the tool name and description is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resume' with a clear resource 'paused campaign', making the tool's purpose distinct from siblings like campaigns_pause, campaigns_start, or campaigns_stop. It clearly indicates the action and state transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or alternatives, but the phrase 'paused campaign' implies it should be used when a campaign is already paused. However, it does not mention related tools like campaigns_start or explain the difference between resuming and starting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' implies a read operation, but there is no mention of what data is returned, how many results, ordering, or error behavior, and it does not clarify whether this is purely a read operation with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the operation and its scope. Every word contributes, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has an output schema, but the description alone is sparse. It doesn't clarify how it differs from 'cases_list_domains' or what 'case domains' means, nor does it explain the role of max_results; the contextual completeness is adequate only for the most basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention instance_id or max_results at all. While instance_id is self-evident from the tool name and description, max_results—which limits the number of returned domains—is completely absent, leaving the agent guessing about its semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'case domains' scoped to a particular Connect instance. This clearly distinguishes it from sibling tools like 'cases_list_domains' or 'profiles_list_domains' which imply different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context—this is for listing case domains belonging to a specific instance. However, it does not explicitly discuss alternatives or exclusions, leaving the agent to infer that other domain-list tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action ('Delete') but does not mention side effects, prerequisites, reversibility, or what happens to the instance. This is a significant gap for a destructive operation, especially since the output schema is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the action front-loaded. Every word earns its place, and there is no repetition of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still incomplete. It lacks important lifecycle context (e.g., whether onboarding must be in a specific state before deletion, or whether it is safe to call again). The parenthetical gives a hint but not enough for a full understanding of the operation's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (connect_instance_id) with no description, and the tool description does not mention it at all. With 0% schema coverage, the description needed to compensate by explaining the parameter's role, but it fails to do so. The parameter name is somewhat self-explanatory, but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Delete instance onboarding job') and the rationale ('to retry onboarding'). It distinguishes itself from sibling tools like campaigns_delete (which deletes a campaign) and campaigns_start_onboarding, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(to retry onboarding)' provides a clear context for when to use this tool, implying it should be used before restarting onboarding after a failure. However, it does not explicitly mention alternatives or exclusions, so it falls 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'clear' implies mutation, but the description does not disclose side effects, whether it invalidates data, requires authentication, or affects ongoing processes. This is a minimal statement without substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and immediately conveys the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters and an output schema, but the description lacks any additional behavioral hints or context. For a trivial reset operation it may be adequate, but it does not go beyond the bare minimum to explain the implications of clearing session context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the input schema confirms no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear session context' uses a specific verb and resource, clearly indicating an action that resets or removes the current session's state. It distinguishes from sibling tools get_session and set_session by implying a different operation (reset vs. read/write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While sibling names (get_session, set_session) imply a relationship, the description does not mention them or any context such as 'use when you need to reset the session between operations.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Search profiles by key'. It does not explicitly state read-only behavior, page limits, or that it searches within a single domain. The verb 'search' implies non-mutating, but other behavioral traits are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, immediately communicating the core action and examples without any superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, but the description omits how domain_name relates to the search and where to obtain it. However, for a simple search tool, the description provides minimal but sufficient context to guess the parameters' purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning to key_name via examples but leaves values and domain_name unexplained. Parameter names are self-descriptive, but the description does not clarify exact-match vs partial-match or the role of domain_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches profiles by key, giving concrete examples (_email, _phone, _account). This distinguishes it from sibling tools like profiles_get_profile (which fetches a single profile) and search_contacts (which searches contacts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a key value to match, but does not explicitly state when to use this over alternatives or what to do when you lack a key (e.g., use profiles_get_profile with ID). No 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The term 'Generate' is ambiguous—it could mean returning a template or performing a write operation. There is no statement about whether it is read-only, whether it deploys anything, or any side effects, which is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose. No filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered by structured data. However, the description is minimal and lacks guidance on when to use the tool or what the generated template includes, making it adequate but not comprehensive for a 5-parameter tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 5 parameters fully described in the input schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Generate' with a clear resource 'Infrastructure as Code template' and scope 'Amazon Connect deployment'. This clearly distinguishes it from sibling tools like template_get or template_customize, which deal with existing templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating an IaC template but does not provide explicit when-to-use or when-not-to-use guidance. Sibling tools such as wizard_start_setup or template_get exist, but no exclusions or alternatives are mentioned, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the behavioral outcome (allows agents to create and manage cases) but doesn't mention permissions, reversibility, idempotency, or failure behavior. It is informative yet not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every phrase adds value. There is no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple association tool, the description combined with full parameter schema coverage and an output schema is mostly complete. It could mention prerequisites or the session default for instance_id, but the provided information is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both domain_id and instance_id having descriptions. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource ('Associate a Cases domain with a Connect instance') and adds functional context by explaining that it enables Amazon Connect Cases. It doesn't explicitly distinguish from sibling tools like cases_create_domain or profiles_associate_domain, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence implies when to use it (to enable Cases for an instance) but provides no explicit exclusions, prerequisites, or alternatives. It gives context but doesn't guide tool selection among related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions enabling resume, which adds context, but does not explain how state is persisted, whether previous state is overwritten, or how the optional error/resource parameters affect behavior. The description says 'after each successful tool execution' yet the schema includes an error parameter for step failures, creating slight ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no waste. It front-loads the primary action and adds a brief usage directive. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has a complete schema plus an output schema, so return values need not be explained. However, the description misses important behavioral context around the optional error parameter and how the resume state is persisted. It is adequate but has clear gaps for an agent fully understanding the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter details beyond indicating the tool is used after completing a step, which aligns with the 'step' parameter but provides no additional semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update onboarding state after completing a step.' It uses a specific verb ('update') and resource ('onboarding state'), which distinguishes it from siblings like wizard_execute_onboarding and wizard_start_setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit timing guidance: 'Call this after each successful tool execution to enable resume.' This tells the agent exactly when to use the tool. However, it does not name alternatives or state 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.
Behavior3/5
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 warns that the action is permanent, which is critical for a delete operation, but it does not mention the confirmation mechanism or consequences for dependent resources. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the core purpose and highlights the permanence warning with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with full schema coverage and an output schema, the description and schema together are nearly sufficient. It omits prerequisites like permissions, but the critical permanence warning is present, making it complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides clear descriptions for both parameters, especially the confirm parameter's dual behavior. The description adds no additional parameter meaning beyond what the schema states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states an action ('Delete') and a specific resource ('Amazon Connect instance'), making it unambiguous. It also distinguishes itself from siblings like create_instance and describe_instance by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to delete an instance) but does not explicitly contrast with alternatives such as describe_instance or list_instances. No exclusionary or alternative tool guidance is given, but the context is clear enough for a straightforward destructive action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 primary mutations and the state-file resume mechanism, but it omits important details such as permission requirements, idempotency, impact on existing resources, and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and avoids fluff. Every sentence contributes meaningful information about the workflow and resume capability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a high-level overview of the workflow steps and explicitly mentions the resume state file, which is critical context for a complex multi-step operation. The presence of an output schema reduces the need to describe return values. However, prerequisites and guidance on interacting with sibling wizard tools are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds the state file path and resume behavior but does not provide parameter-level semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes the full onboarding workflow and enumerates concrete high-level actions (creates Connect instance, configures routing, enables Cases and Q in Connect). This specificity distinguishes it from related wizard tools like wizard_start_setup or wizard_generate_faq_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the full workflow and resume capability, but it does not explicitly state when to choose this tool over sibling tools like wizard_start_setup or wizard_update_onboarding_state. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic operation without disclosing any behavioral details such as requiring an active session, whether any state is changed, or error conditions. It doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundancy or filler. It is appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is complete enough. It identifies the tool's purpose clearly, and no further context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details, which is acceptable at the baseline of 4 for a zero-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (current session context). It is distinct from sibling tools like set_session and clear_session, so it disambiguates well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but the name and description imply it should be used to retrieve the current session context, particularly in contrast to set/clear. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral outcome—'enables Customer Profiles... allowing contact data to flow into customer profiles automatically'—which is useful. However, it omits details about whether an existing association is replaced, required permissions, or idempotency, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The first sentence states the verb and resource, and the second adds a meaningful consequence. This is an appropriately sized, front-loaded description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and the presence of an output schema, the description does not need to explain return values. It explains the main purpose and the automatic data-flow effect. It could add prerequisites like whether the domain must already exist, but it is largely complete for this configuration-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-specific detail beyond mentioning 'domain' and 'instance' in prose, so it does not exceed the baseline provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Associate a Customer Profiles domain with a Connect instance.' This clearly identifies both objects involved and distinguishes the tool from siblings like profiles_create_domain, profiles_list_domains, and cases_associate_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the intended context: it enables Customer Profiles for the instance and allows contact data to flow automatically. This gives clear when-to-use framing, though it does not explicitly name alternative tools or 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.
Behavior4/5
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 reveals a non-obvious behavior: it auto-discovers the first available assistant and searches only that assistant's knowledge base. This explains potential variability in results, which is valuable. However, it does not mention edge cases like failures when no assistant exists or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and target. The second sentence adds essential behavioral detail without redundancy. Every word contributes value, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return value structure, so that is not a gap. The description explains the core action and the auto-discovery trait, but omits details about max_results and does not address what happens if no assistant is available. While adequate for a simple search tool, these omissions leave the description slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for explaining parameters. It implicitly clarifies 'query' by mentioning the search action, but it says nothing about 'max_results', including its effect on the number of results or any constraints. The agent must infer max_results semantics solely from its name, which is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' with a distinct resource, 'Amazon Q in Connect knowledge base', and explicitly lists common aliases ('QiC', 'Q in Connect'). This clearly differentiates the tool from generic sibling search tools like ai_search_content by narrowing scope to Amazon Q's knowledge base.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clearly when to use the tool: for 'QiC', 'Q in Connect', or knowledge base searches. It does not explicitly name alternative tools or exclusions, but the context is sufficient for an agent to understand typical use cases. The auto-discovery note hints at limitations but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains that defaults are used unless overridden, but doesn't mention side effects like whether unspecified parameters are reset or how session state persists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose and effect. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with optional params and an output schema, the description covers the main behavior and override semantics. It could clarify whether partial updates preserve existing values, but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are well-documented with examples and defaults. The description adds no additional parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set session context') and the resource scope ('for subsequent operations' / 'all config tools'), which distinguishes it from sibling tools like get_session and clear_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool (before subsequent operations) and describes how defaults apply to config tools and can be overridden. However, it doesn't explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool returns resolved field mappings and step-by-step instructions, which is useful, but it does not mention error conditions, permissions, or whether the operation is strictly read-only (though 'get' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, and the second clarifies the output and usage context. Every word earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-style tool with an output schema, the description covers what it does, what it returns, and when to use it. The output schema eliminates the need to list return fields, and the missing error handling details are minor for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for both parameters, with 100% coverage. The description adds marginal context by mentioning the 'target domain', but it does not meaningfully enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete workflow for creating a case from a template, including field mappings and step-by-step instructions. This specific verb+resource combination distinguishes it from sibling tools like template_get_routing_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this tool before creating cases to avoid validation errors, giving clear contextual timing. It does not mention alternatives or when not to use it, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses what information is extracted (brand, industry, hours, FAQs, products) but does not mention potential side effects (e.g., outbound network request), failure modes (e.g., unparseable websites), or rate limits. It adds some context beyond the schema but lacks deeper behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: high-level goal, extraction details, and usage guidance. It is front-loaded with the most important information and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers what the tool does and where it fits in the onboarding workflow. It does not explain error handling or network assumptions, but these are not critical for basic use. Slightly more detail on failure modes would push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'url' parameter, so the schema already fully documents it. The description mentions 'from a website' but adds no additional parameter constraints, format, or validation beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: 'Discover business information from a website' and lists concrete extraction targets (brand name, industry, hours, FAQs, products). It also distinguishes itself from sibling wizard tools by positioning itself as the 'first step in automated onboarding.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this as the first step in automated onboarding,' providing clear usage context. It implies precedence over sibling wizard tools but does not include explicit when-not-to-use instructions or alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: creates one .txt file per FAQ, writes to ./{brand}/faq/, formats for Q in Connect ingestion, and enforces a 1MB limit. Missing details include overwrite behavior and error handling, but substantial context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, then providing directory details and file size limit. Every sentence adds value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with an output schema, the description covers target directory, file naming, size limit, and ingestion formatting. It doesn't mention error scenarios or prerequisites, but given the moderate complexity, it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described (brand as slug, faqs as list of objects with title/summary/content). The tool description adds no additional parameter-level semantics, only the directory context. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Generate FAQ text files for Q in Connect knowledge base,' using a specific verb and resource. It further specifies the output directory and file format, which distinguishes it from sibling wizard tools like wizard_discover_website or wizard_start_setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description focuses on mechanics (directory, file format) rather than use cases or exclusions. However, the purpose is clear enough for an agent to infer its applicability, but no when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the key behavior that omitting region lists across all regions, which is important. However, it does not mention pagination, rate limits, or other potential behavioral traits. For a simple read-only list tool, this is adequate but not exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that directly state the tool's purpose and the key parameter behavior. Every word earns its place, and it is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), the presence of an output schema, and the lack of annotations, the description covers the essential usage and behavior. It could mention error handling or pagination, but for most use cases, the description is complete enough to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'region' parameter (0% coverage), so the description compensates by explaining its semantics: if no region is specified, all regions are included. This adds meaning beyond the bare schema definition and helps the agent understand how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Amazon Connect instances') and the resource ('Amazon Connect instances'), distinguishing it from siblings like describe_instance, create_instance, and delete_instance. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it lists all instances, with the region parameter controlling scope. It implies that this is the broad-listing tool compared to describe_instance for single instances, although it doesn't explicitly name alternatives. The region behavior guidance is useful and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states it 'Returns step-by-step instructions with tool calls and dependencies,' making its read-only, informational nature clear. It could explicitly note that it makes no changes, but the 'get' verb and 'instructions' imply this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose, then detailing the return value and usage. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simple nature of the tool, the description covers purpose, usage timing, and return content. It lists the routing components covered and indicates it provides dependencies, making it complete for agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema fully describes both required parameters (instance_id and region) with 100% coverage. The description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the complete workflow for setting up routing' with specific components (hours, queues, profiles, flows). It uses a specific verb (get) and resource (routing workflow), distinguishing it from the sibling template_get_case_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use this before creating routing configuration to ensure correct order,' providing clear when-to-use guidance. However, it does not mention when not to use or name alternatives, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool launches a browser UI, supports drag-and-drop, generates JSON in real-time, and requires copying the output—implying it is a read-only design tool. It does not mention potential side effects like session requirements, but given the nature of a visualizer, this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a single, clear action sentence, followed by a compact bulleted list of capabilities. Every sentence earns its place—no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero-parameter signature and the presence of an output schema (not shown), the description fully explains what the tool does and how its output integrates with the cases_create_layout workflow. It leaves no ambiguity about the tool's purpose or usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows 100% coverage. The description adds no parameter-level detail because none is needed, which aligns with the baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Launch the Cases Layout Visualizer in your browser') and clearly identifies the resource and purpose. The bulleted list distinguishes this tool from siblings like cases_create_layout by emphasizing the interactive drag-and-drop interface that generates JSON, rather than directly creating layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: it is for visually designing layouts and generating JSON for later use with cases_create_layout. While it doesn't explicitly state when not to use it or list alternatives, the workflow implication is strong and unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amazon-connect-mcp MCP server](https://glama.ai/mcp/servers/mundurragacl/amazon-connect-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mundurragacl/amazon-connect-mcp)

Score Badge

Copy to your README.md:

[![amazon-connect-mcp MCP server](https://glama.ai/mcp/servers/mundurragacl/amazon-connect-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mundurragacl/amazon-connect-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mundurragacl/amazon-connect-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server