@cig-chat/mcp

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 distinct purposes, and the descriptions clearly spell out what each does (e.g., send vs broadcast, by tag vs by segment). However, there are a few near-duplicates like cigchat_me and cigchat_whoami, and the many 'by_name' / 'by_user_id' variants could cause an agent to pick the wrong one if it doesn't read carefully.
Naming Consistency3/5
The naming mostly follows a snake_case pattern with a domain prefix (e.g., shop_products_create, subscriber_add_tag), but there are notable inconsistencies: some tools use 'get' while others use 'list', some use 'set' vs 'update', and a few lack a verb entirely (cigchat_flow_summary, cigchat_integration_claude). This mixed convention makes the set less predictable than it could be.
Tool Count1/5
With 250 tools, this server is far beyond the 'too many' threshold and represents an extreme mismatch for an agent to navigate effectively. Even for a broad API, the toolset is overwhelming and would benefit from consolidation or a more curated surface.
Completeness5/5
The toolset covers an impressively wide range of resources with full CRUD and lifecycle operations for flows, subscribers, shop items, templates, integrations, team management, and more. It even includes a generic api_call tool to fill any potential gaps, making the surface very complete for its intended domain.
Average 3.6/5 across 250 of 250 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/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 adds one useful fact: the required 'Manage Team' scope on the token. However, it does not disclose side effects, return values, idempotency, or that the resource is a discount code (it incorrectly says 'tag'). This is insufficient for a create operation with 13 parameters.
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 short (one sentence), but it is not effective. The phrase 'Create new tag' is actively harmful misinformation, and although the endpoint and scope are useful, the overall structure does not present information clearly or accurately. A concise description that contains a critical error does not 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?
This is a complex tool with 13 parameters, no output schema, and no annotations. The description only provides the wrong resource name, an endpoint, and a scope requirement. It does not explain the discount code domain, required fields beyond what is in the schema, or how this operation fits with sibling tools. The description is largely inadequate for an agent to safely and correctly invoke this 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 92%, so the baseline is 3 even though the description adds no parameter information. The schema itself provides examples for most parameters, which helps the agent. However, the description's misleading 'tag' label may cause incorrect interpretation of parameter meanings (e.g., 'type' could be misread). No additional parameter insight is given beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly says 'Create new tag', but the tool endpoint is /shop/discount-codes/create, indicating it actually creates discount codes. This is misleading and directly contradicts the tool's name and endpoint. It fails to identify the correct resource, so it cannot help an agent understand what this 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?
No guidance is provided about when to use this tool versus alternatives. It does not mention that it is the create operation among discount code tools, nor does it distinguish from related tools like cigchat_shop_discount_codes_update or cigchat_service_discount_codes_get_info. The only extra context is the required 'Manage Team' scope, which is not a usage guideline.
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 mentions the required 'Manage Flow' scope, which is useful, but it does not describe the actual side effects (e.g., whether it permanently unsubscribes the user, whether it is reversible, or whether it sends a confirmation). The mutation nature is implied by 'opt-out' but not made explicit.
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 is under-specified rather than concise. It is a fragment ('Opt-out Email') followed by an endpoint and a scope note, lacking a proper sentence structure or any elaboration that would help the agent.
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 (one parameter), the description is not completely unmanageable, but it fails to provide necessary context such as what user_ns refers to, what the endpoint does to the subscriber, and how it differs from related tools like opt_in_email or opt_out_sms. The lack of output schema and annotations makes this information gap more significant.
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, user_ns, with zero description coverage. The tool description does not explain what user_ns means or how to supply it, leaving the agent entirely without semantic guidance for the parameter.
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 'Opt-out Email [DELETE /subscriber/opt-out-email]' essentially restates the tool name with an endpoint, providing little beyond a tautological label. It does not clearly state that this opts a subscriber out of email communications, and it fails to distinguish it from sibling tools like cigchat_subscriber_opt_in_email or cigchat_subscriber_opt_out_sms.
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 about when to use this tool versus alternatives. The only contextual clue is the required scope, but there is no mention of prerequisites, effects on subscribers, or when opting out by email is appropriate versus other opt-out mechanisms.
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 bears the full burden for behavioral disclosure. It only mentions the required 'Manage Flow' scope and gives no information about side effects, reversibility, or idempotency of the subscription action.
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 brief (one sentence) and is not verbose, but the content largely repeats the tool name. It includes useful endpoint and auth info, but lacks structural expansion to cover 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?
For a mutation tool with no output schema, no annotations, and minimal description, the context is incomplete. The agent cannot infer expected return values, error conditions, or prerequisites beyond the auth scope.
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 a single parameter user_ns with no description, and the tool description does not explain what user_ns refers to or any format constraints. With 0% schema coverage, the lack of parameter semantics is a critical 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 states 'Subscribe to bot' which merely restates the tool name without explaining the semantics of subscribing a subscriber to a bot or distinguishing it from sibling tools like unsubscribe_from_bot or opt_in_sms. It lacks any detail about the operation's effect.
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 such as subscriber_resume_bot or subscriber_opt_in_sms. The only additional note is the auth scope, which does not help with tool selection.
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?
The description discloses the authentication requirement (Manage Flow scope) and the side effect that a real message is delivered, which is behavior beyond the schema. However, it doesn't explain how the delivery occurs, what data is used, or any return value, leaving the agent with incomplete behavioral knowledge.
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 includes the endpoint, but the first sentence is a fragment that mirrors the tool name, and the second sentence's meaning is not fully clear. It could be more effectively 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 five parameters, no output schema, and no parameter descriptions, the description omits critical information such as the meaning of user_ns and event_name, how the event data maps to the delivered message, and whether the operation is synchronous. The provided text is insufficient 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?
None of the five parameters (user_ns, event_name, text_value, price_value, number_value) are explained in the description, and the schema has no descriptions for them (0% coverage), so the agent has no guidance on what values to provide.
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 restates the tool name ('Log custom event') but then adds 'Delivers a real message to a person,' which confuses the primary function. It doesn't clearly explain that logging an event is distinct from directly sending a message, and the relationship between the two actions is ambiguous.
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 the many send_* siblings. The only contextual info is the required 'Manage Flow' scope, which is a prerequisite, not a usage guideline.
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 mentions the token scope, but does not describe side effects (e.g., setting an opt-in flag), idempotency, or what happens if the subscriber is already opted in. This is insufficient for a mutating action.
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 brief, but it is more of a label than a structured description. It includes the endpoint and scope, which are useful, but the main phrase 'Opt-in Email' mostly repeats the tool name. It is concise but under-specified rather than 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?
For a simple one-parameter action, the description still lacks essential context: what the parameter is for, what the response looks like, and whether the operation can be reversed. The absence of an output schema and the minimal description make it incomplete for reliable agent 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 schema has one required parameter (user_ns) with 0% description coverage, and the tool description does not explain it. An agent cannot determine what user_ns means (e.g., namespace vs. subscriber ID) from the description, so parameter semantics are entirely missing.
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 'Opt-in Email' combined with the endpoint POST /subscriber/opt-in-email clearly indicates the action (opt-in) and the resource (email for a subscriber). It is distinguishable from siblings like opt_out_email and opt_in_sms, though it could state explicitly that it enables email opt-in for a subscriber.
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 only addition is the required 'Manage Flow' scope, which is a prerequisite but not a usage guideline. It does not mention situations like 'when a subscriber needs to receive email communications' or contrasts with opt_out_email.
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 disclose behavioral traits itself. It mentions the required 'Manage Flow' scope, which is a useful access requirement, but it does not explain side effects, reversibility, or behavior if the user is already opted in. This is insufficient for a mutation 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 a single concise sentence with the endpoint and scope requirement, front-loaded with the action. It is efficient and free of fluff, though the minimalism borderlines on under-specification.
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 description is far too sparse for effective use. It lacks parameter explanation, behavioral outcomes, and any detail about what opt-in SMS actually does, leaving critical gaps for a tool with no output schema and 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 schema has no description for the required parameter user_ns, and the description does not compensate. It does not explain what user_ns represents or how to supply it, leaving the agent without guidance on the only required input.
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 'Opt-in SMS' followed by the HTTP endpoint, making the action clear. It distinguishes this tool from siblings like cigchat_subscriber_opt_out_sms and cigchat_subscriber_opt_in_email, though it relies on the tool name for full 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 such as opt_out_sms or opt_in_email. The only additional instruction is a scope requirement, which is more of a prerequisite than a usage guideline.
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 notes the scoping requirement, but does not state whether the update overwrites existing fields, whether 'type' is affected, or what the response looks like. For a mutation tool, 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 description is short and front-loaded, but includes a typo ('embeding') and a bracketed HTTP endpoint that adds little for an AI agent. It is concise but not polished, and the structure is acceptable.
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 is a mutation tool with no annotations, no output schema, and low schema coverage. The description is incomplete for 4 parameters and numerous siblings: it lacks parameter semantics, return behavior, and distinctions from create/import/generate. It only provides a single prerequisite, making it inadequate for an agent to fully understand the tool.
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 only 25% (only 'id' has a trivial description), so the description should compensate. It explains that 'heading' and 'text' are updatable, but says nothing about the 'type' parameter, leaving it unclear. The description adds minimal value over the bare 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 the action ('Update') and the resource ('embeding heading and text'), making it distinguishable from sibling tools like create/delete/get_info. However, the typo 'embeding' and omission of the 'type' parameter create slight ambiguity about the full scope of the update.
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 mentions the required 'Manage Team' scope, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives like create or import. No exclusions or alternative tool references are given.
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 adds the important behavioral detail that the token must have the 'Manage Team' scope, and the POST method signals a write operation. However, it does not disclose return values, side effects, or consequences beyond creation, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two short sentences that each convey essential information: the action and the auth requirement. No unnecessary words are present, making it efficient, though it may be too brief 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 3 parameters, no annotations, and no output schema, this description is incomplete. It lacks parameter semantics, return value information, and differentiation from sibling operations, leaving an agent to make significant assumptions about how to use it 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 offers no explanation of the parameters (heading, text, type). The names are self-descriptive to some degree, but 'type' is ambiguous and none of the parameter meanings are clarified, so the description completely fails to compensate for the schema absence.
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 as 'Create new embedding' and includes the HTTP endpoint, making the primary action unambiguous. However, it does not explicitly distinguish this from the sibling tools 'generate' or 'import', which could overlap in 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?
The description provides no guidance on when to use this tool versus alternatives like generate or update. It only mentions a required scope ('Manage Team'), which is a prerequisite but does not explain the appropriate context for invoking this tool.
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 that this sends a 'real message' (not a test) and requires the 'Manage Flow' scope, adding value beyond the tool name. However, it does not mention side effects, irreversibility, rate limits, or return behavior, which would be helpful for a mutating send action.
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, with two sentences that front-load the purpose and include the endpoint and auth requirement. The phrase 'learn more about how to use dynamic content' is slightly vague but not wasteful. Overall, it earns 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 complex nested schemas (data.content with anyOf/not constraints) and no output schema, yet the description gives no help on constructing the data object or understanding user_ns. The auth scope and 'real message' warning add some context, but the description is incomplete 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?
The description adds no parameter-level information. Schema coverage is only 33% (only send_as_agent has a description), and both 'data' and 'user_ns' remain unexplained. The description does not compensate for the low coverage, leaving the agent without guidance on constructing the dynamic content payload or identifying the subscriber.
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 ('Send') and resource ('content to subscriber') and adds that it 'Delivers a real message to a person,' which clarifies the tool's purpose. However, it does not explicitly differentiate from sibling send tools like cigchat_send_text or cigchat_send_sms, 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?
There is no guidance on when to use this tool compared to the many sibling send tools. The hint to 'learn more about how to use dynamic content' implies it's for dynamic content, but no alternatives or exclusions are given. The only explicit usage context is the 'Manage Flow' scope requirement, which is a prerequisite, not a usage guideline.
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 discloses the PUT method, the required 'Manage Team' scope, and detailed parameter constraints including conditional requirements and value ranges. However, it does not clarify whether the update replaces existing hours or merges with them, nor does it describe response behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence with comma-separated fields, making it hard to parse. It front-loads the purpose but then dumps all parameter rules without any structural organization, reducing readability.
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 many constraints (enumerations, time ranges, conditional requirements) and mentions authentication, but it omits the actual request structure (the 'data' array wrapper) and the semantics behind option values. There is no output schema, and the description does not discuss return values or failure scenarios, leaving the tool incomplete in 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 description adds significant value by listing allowed values for id, name, option, and time ranges, plus conditional requirements for start/end fields. However, it presents these as flat parameters while the actual schema requires a 'data' array containing objects, which is a critical mismatch that could lead to invalid invocation. The meanings of 'open' vs 'close' are also left 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 clearly states 'Update store business hours,' identifying the action and resource directly. It does not explicitly differentiate from the related read tool 'cigchat_shop_business_hours_info' or other update tools, but the verb and resource are specific enough to convey the 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 explicit guidance is given on when to use this tool versus alternatives, such as using the info tool for retrieving current hours. The verb 'Update' implies modification, but there is no mention of exclusions, prerequisites, or comparisons to sibling tools.
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 of disclosing behavior. It does disclose the key side effect ('Delivers a real message to a person') and the required OAuth scope, which is useful. However, it omits other behavioral details such as rate limits, idempotency, or what happens on failure, so it only reaches a minimum viable level.
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 brief and well-structured: a single action sentence plus a second sentence covering the impact and requirement. Every sentence earns its place with no filler. It loses a point because extreme brevity conflicts with the need for more detail, but as a standalone text it is efficiently organized.
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 side effect (sends a real message), the lack of annotations, output schema, and parameter descriptions makes this description critically incomplete. It does not explain what values trigger_name should take, how user_ns is identified, what the context object does, or what the response shape is. An agent would struggle to invoke this correctly and understand the outcome.
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 explanation for any of the three parameters (trigger_name, user_ns, context). The parameter names are not self-explanatory enough for safe invocation, especially 'context' which is an object with unlabeled fields. The description completely 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 states the action ('Trigger an app event') and the resource ('subscriber from installed min-app'), and adds that it 'Delivers a real message to a person,' which clarifies the real-world impact. It is specific but does not explicitly differentiate from sibling send/trigger tools, 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?
The description offers no guidance on when to use this tool versus alternatives, no use-case context, and no exclusions. It only mentions a required scope ('Manage Flow'), which is a prerequisite rather than usage direction. This is inadequate for a tool with many sibling send/trigger operations.
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?
The description discloses the HTTP method (DELETE) and a required scope, providing some behavioral context beyond the tool name. However, it doesn't mention side effects, reversibility, or what the opt-out action entails, which is important given no annotations exist.
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 brief and front-loaded with the main action. It is appropriately sized for a simple tool, though the bracketed HTTP method is a slightly technical inclusion that could be cleaner.
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 one parameter, no output schema, and no annotations, the description is incomplete. It omits the meaning of user_ns and any details about the effect or result of the opt-out, leaving significant gaps for the agent.
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 provides no explanation of 'user_ns'. The parameter name is ambiguous and the tool description doesn't compensate, leaving the agent without guidance on what value to supply.
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 action ('Opt-out SMS') clearly with a resource and distinguishes from sibling tools like cigchat_subscriber_opt_in_sms and opt_out_email. However, it doesn't explicitly say it's for a subscriber, relying on the tool name for that 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. The only additional note is an auth requirement (Manage Flow scope), which is a permission prerequisite rather than a usage guideline.
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 states that the tool 'Set or update' a value and mentions the required scope, but it fails to reveal side effects such as whether it creates missing fields, overwrites existing values, or returns any confirmation. No idempotency or failure behavior is described.
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, front-loaded with the action, and includes the endpoint. It is brief and without redundancy, though it sacrifices substance for 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?
The description is insufficient for a tool with no annotations, no output schema, and 3 undocumented parameters. It fails to specify the meaning of `user_ns`, differentiate from similar set_user_field variants, or state behavioral outcomes. Given the large family of subscriber and user-field tools, more detail is essential.
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. It only mentions 'field name' generically but does not explain the meaning of `user_ns`, the relationship between `field_name` and `value`, or how the subscriber is identified. This is a significant gap for a tool with 3 required parameters.
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 or update'), the resource ('subscriber user field value'), and the method ('by field name'). It also includes the endpoint for reference, and the name differentiates it from sibling tools like set_user_field (likely by ID) and set_user_fields_by_name (plural).
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 explicit guidance on when to use this tool versus alternatives such as cigchat_subscriber_set_user_field or cigchat_subscriber_set_user_fields_by_name. The only contextual clue is the required 'Manage Flow' scope, which is a prerequisite rather than a usage guideline. The phrase 'by field name' implies a use case but does not state exclusions or compare with ID-based methods.
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 disclose behavior but only reveals the HTTP method (PUT) and required scope. It does not state whether it overwrites an existing value, whether it can create a field, what the response contains, or error conditions. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no redundant words, but it under-specifies critical operational details. It is not bloated, but the brevity sacrifices the behavioral and contextual information an agent needs to invoke the tool confidently.
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 mutation tool with no annotations, no output schema, and a large set of similar sibling tools, the description is too sparse. It omits expected return values, side effects, how the field is identified, and differentiators from the many bot field related 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?
Schema description coverage is 50%: var_ns is well-documented, but value has no schema description. The tool description implicitly identifies 'value' as the new field value through 'update bot field value', adding minimal meaning. It does not elaborate on value format or constraints, but the implied context partially compensates.
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 'update bot field value' with the endpoint 'PUT /flow/set-bot-field', indicating a write operation on a bot field. However, it does not distinguish from closely related siblings like cigchat_flow_set_bot_field_by_name or cigchat_flow_set_bot_fields, so it lacks explicit 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?
No guidance is given on when to use this tool versus alternatives such as cigchat_flow_set_bot_field_by_name or cigchat_flow_set_bot_fields. The mention of 'Requires the Manage Flow scope on the token' is a permission constraint, not usage context.
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 mentions the 20-tag limit and the token scope, but does not explain side effects, return values, error behavior, or whether the operation is idempotent. For a mutating action, this is insufficient.
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 front-loads the action and includes essential details (tag limit, endpoint, required scope). There is no filler 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no output schema, and no annotations, this description is too sparse for a tool with two required parameters. It fails to explain what 'user_ns' means, how to format the data array, or what the response will look like. A more complete description is needed for safe invocation.
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% top-level parameter descriptions, so the description must compensate. It implies 'data' holds the tags (up to 20) but does not clarify 'user_ns' or how to structure each tag item beyond the nested schema description. This leaves significant ambiguity for the agent.
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 ('Add tags to subscriber') with a specific verb and resource, and adds useful details like the 'up to 20 tags' limit and the endpoint. It is unambiguous, though it does not explicitly distinguish itself from sibling tools like cigchat_subscriber_add_tags_by_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?
The description gives no guidance on when to use this tool versus alternatives. It only notes the required 'Manage Flow' scope, which is a prerequisite but not a usage directive. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits. It states the HTTP method (DELETE) and the required scope, but does not explain side effects (e.g., whether clearing is idempotent, whether it only removes the value or also other data, or what happens if the field does not exist). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, endpoint, and authentication requirement without unnecessary words. Every element serves a purpose, making this a model of concise tool documentation.
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 complexity (a mutation with required parameters, no output schema, and no annotations), the description is incomplete. It omits details about the subscriber context, what the cleared field value is, the response format, and potential errors. An agent would need to make assumptions or consult other tools.
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 describes 'var_ns' but leaves 'user_ns' without any description. The tool description adds no parameter details, failing to compensate for the incomplete schema. An agent cannot infer what 'user_ns' refers to (likely subscriber identifier) from the description alone, so parameter semantics are under-specified.
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 ('Clear subscriber user field value') and includes the endpoint [DELETE /subscriber/clear-user-field], making the tool's purpose immediately understandable. However, it does not explicitly distinguish this from the similarly named sibling 'cigchat_subscriber_clear_user_field_by_name', which reduces clarity for an agent choosing between 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 mentions a prerequisite ('Requires the Manage Flow scope on the token') but provides no guidance on when to use this tool versus alternatives like 'cigchat_subscriber_clear_user_field_by_name'. There is no context about typical use cases or situations to avoid this tool, leaving the agent without decision guidance.
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?
The description discloses the required authentication scope ('Requires the 'Manage Flow' scope'), which is a useful behavioral trait. However, it does not explain what the sync does, whether it mutates data, if it is destructive, or what the effects are. With no annotations, the description carries the full burden, and 'sync' is a vague operation that could involve significant side effects, so transparency is insufficient.
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 action and resource, and includes the endpoint and auth requirement in a compact format. Every word earns its place, with no fluff or repetition. It's very 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?
For a sync operation with no annotations or output schema, the description is insufficient. It lacks an explanation of what synchronization entails, what the endpoint returns, whether it is destructive, and any important caveats. Given the ambiguity of 'sync', the description should provide more context to make the tool safe and usable. It only covers the auth requirement, which is far from complete.
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 input schema has zero parameters, so there are no parameter semantics to explain. According to the rubric, a tool with 0 parameters gets a baseline of 4. The description doesn't need to add parameter details, and it doesn't.
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 states the verb 'Sync' and the resource 'Facebook utility message templates', which gives a general sense of the action. However, 'sync' is ambiguous—it does not clarify whether templates are pushed to Facebook, pulled from Facebook, or bidirectionally synchronized. The sibling tools (create, list, delete, describe) suggest a CRUD set, but 'sync' could mean several things, so the purpose is not fully precise.
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 the related sibling tools like create, list, or delete. The only additional note is the required 'Manage Flow' scope, which is an authorization detail, not a usage guideline. There are no scenarios, exclusions, or alternative 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?
With no annotations provided, the description carries the full burden. It discloses the required authentication scope, which is useful, but it does not describe what the summary contains, whether it is read-only (beyond the verb 'Get'), or any potential side effects or limitations. The behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant words. The action and resource are front-loaded, followed by the permission note. Every word earns 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?
Given the lack of annotations and output schema, the description should clarify what a 'flow agent summary' includes and how it differs from similar flow summary tools. The current text is too brief, leaving the agent to guess the return structure and usage context.
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% for both parameters (range and flow_ns), with descriptive text already present in the input schema. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 names a clear resource ('the flow agent summary'), adding the endpoint path for clarity. It does not explicitly differentiate this from sibling tools like flow_summary or flow_agents, but the resource term is reasonably distinct.
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 only additional context is the required 'Manage Team' scope, which is a prerequisite but not a usage guideline. No exclusions or alternative tool names 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?
With no annotations provided, the description carries the full burden of transparency, but it only mentions the auth scope. It does not disclose behavior on duplicate fields, return values, or side effects, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and includes essential auth/endpoint info, earning high marks for 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 no output schema and no annotations, yet the description fails to explain what the API returns or how conflicts are handled. Given the mutating nature and 6 parameters, the description is under-specified.
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 83%, so the schema already documents most parameters. The description adds no additional parameter semantics, but the baseline of 3 is appropriate given the high 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 action ('create new bot field') and includes the endpoint. However, it does not differentiate from sibling tools like cigchat_flow_create_user_field or cigchat_flow_set_bot_field, making the purpose clear but not uniquely distinguishable.
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 cigchat_flow_set_bot_field or cigchat_flow_create_user_field. The only usage-related note is the required 'Manage Flow' scope, which is a prerequisite rather than a selection guide.
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 carries the burden of behavioral disclosure. It discloses the 'Manage Flow' scope requirement, which is useful, but omits important behavioral details such as duplicate name handling, error conditions, or 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, with two short sentences that front-load the action and endpoint. No filler or redundant information is present.
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 description covers the basic action and auth requirement, but for a create operation it lacks guidance on uniqueness/duplicates and explicit differentiation from product tag creation. Given the simple interface and no output schema, it is minimally adequate but leaves notable 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?
The single 'name' parameter is not described in the description, and schema coverage is 0%. While the parameter is minimally self-explanatory, the description adds no extra meaning regarding constraints, uniqueness, or formatting.
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 new tag' with the endpoint '/flow/create-tag', clearly indicating a flow tag creation action. However, it does not explicitly differentiate from the sibling 'cigchat_create_product_tag', relying on the endpoint path and tool name for disambiguation.
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 mentions the required scope, but does not state use cases, exclusions, or related tools for product tags, leaving the agent without clear selection criteria.
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 but only partially: it discloses that this is a real message delivery and that a specific OAuth scope is required. It does not mention side effects, idempotency, error behavior, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the action and endpoint front-loaded, followed by a useful scope note. Every word earns 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?
As a mutating tool with no annotations and no output schema, the description omits how to resolve the identifiers, expected return values, and delivery caveats. It 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero explanation for either parameter. The schema gives an example for node_ns but leaves user_ns completely undocumented, so with only 50% schema coverage the agent is left guessing what these values mean.
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 ('Send node to subscriber') and includes the POST endpoint, making it evident that this tool sends a node message to a subscriber. However, it does not explicitly distinguish itself from sibling send tools like send_text, send_subflow, or send_content.
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. It only mentions the required 'Manage Flow' scope, which is a permission prerequisite, not a selection criterion.
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 does mention the required 'Manage Flow' scope, which is a useful authorization detail, but it omits behavior on duplicate tags, invalid subscriber, whether the tag is auto-created, error conditions, or side effects. Minimal beyond the obvious POST operation.
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, purposeful sentences: one specifying the action and endpoint, the other stating the required scope. There is no fluff, repetition, or unnecessary 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?
For a tool with only two parameters and no output schema, the description is too sparse. It fails to explain the meaning of 'user_ns' and does not address behavioral nuances such as errors, idempotency, or differences from closely named siblings. Given the large set of similar tools, this under-specification is risky for autonomous selection and use.
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. While 'tag_name' is clarified by the phrase 'by tag name', 'user_ns' is completely unexplained—no format, example, or meaning. This is a critical gap for an agent to correctly invoke the 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 begins with 'Add tag to subscriber by tag name', which is a specific verb, object, and method. This clearly states what the tool does and differentiates it from siblings like add_tag (by ID) and add_tags_by_name (plural). The inclusion of the endpoint further clarifies the action.
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 cigchat_subscriber_add_tag or cigchat_subscriber_add_tags_by_name. The only contextual note is the required 'Manage Flow' scope, which is a prerequisite rather than a usage guideline. There is no exclusions or alternative tool references.
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 does disclose a behavioral requirement ('Requires the Manage Flow scope on the token'), which is useful authorization context. However, it does not mention whether the update is reversible, what happens to the chat, or any side effects of moving status, leaving significant behavioral ambiguity.
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 front-loads the action and includes the endpoint and scope requirement. It is appropriately concise with no filler, though it sacrifices completeness 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?
For a tool with 2 required parameters, no output schema, and no annotations, the description is minimally equipped. It gives the action and scope but leaves 'user_ns' undefined, does not enumerate valid statuses beyond the schema example, and does not explain what moving a chat status entails. An agent would likely need to guess about user identification and status semantics.
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 coverage is only 50%: 'status' has an example, but 'user_ns' lacks description. The tool description adds no parameter meaning beyond the schema, failing to compensate for the undocumented 'user_ns'. The status example in the schema is helpful but not expanded in 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 states a specific action ('Update chat status') and resource, making it clear what the tool does. However, it does not explicitly differentiate this from sibling tools that also operate on chat/subscriber state, such as assign_agent or pause_bot, though the 'move-chat-to' endpoint and 'status' parameter make the intended operation reasonably distinct.
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. There is no mention of prerequisites beyond the scope requirement, no scenarios described, and no exclusions. The tool name implies a chat-status transition, but the description does not help an agent decide between this and other chat/subscriber 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 full burden. It discloses the required scope but does not mention side effects, reversibility, or what 'resume' actually does to subscriber state. Lacks behavioral depth beyond the basic action.
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 with no filler. It front-loads the purpose and includes the endpoint and scope requirement in a succinct, well-structured manner.
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 tool with one parameter, the description states purpose and scope but misses key context: what user_ns means, what 'resume' entails, and when to use it relative to other subscriber tools. Incomplete for an agent to confidently 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 has one parameter (user_ns) with zero description coverage, and the description does not explain user_ns at all. It adds no meaning beyond the schema, leaving the agent to guess what value to provide.
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 ('Resume bot automation to subscriber') and identifies the target resource (subscriber). It distinguishes itself from sibling tools like pause_bot or subscribe_to_bot by specifying the exact operation and endpoint.
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 only mentions the required 'Manage Flow' scope, which is a prerequisite, not usage guidance. It does not explain when to use this tool versus alternatives like pause_bot or subscribe_to_bot, or any conditions for resuming automation.
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?
The description discloses the required 'Manage Flow' scope and the HTTP method/endpoint, which is useful but limited. With no annotations, it does not explain side effects, whether the operation is an upsert, or what the response looks like. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the action first, followed by endpoint and scope in a compact format. Each element earns its place without unnecessary fluff.
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, no output schema, and only 33% schema parameter coverage, the description is too sparse. It fails to convey return values, side effects, or usage context relative to sibling tools.
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 no explanation for the parameters. The schema describes var_ns (namespace id or name resolution) but leaves value and user_ns undocumented. With schema coverage at only 33%, the description does not compensate.
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 ('Set or update subscriber user field value') and identifies the specific resource. It includes the endpoint and required scope, which adds precision. However, it does not explicitly distinguish itself from sibling tools like set_user_field_by_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?
The description provides no guidance on when to use this tool versus alternatives. It only mentions the required scope, which is a prerequisite rather than usage context. There is no mention of 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.
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 it only discloses the required scope and HTTP method. It does not explain side effects (e.g., whether this permanently stops all communications), reversibility, or any additional behavioral implications beyond the generic 'unsubscribe'.
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. Including the HTTP endpoint and scope requirement is concise and functional, earning its place without redundancy.
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 (1 param, no output schema) and absent annotations, the description is too minimal. It lacks parameter semantics, expected behavior on success/failure, and any clarification of what 'unsubscribe' actually entails, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explanation of the required 'user_ns' parameter. The agent receives no help understanding what this parameter means or how to populate it, so the tool is difficult to invoke correctly.
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: 'Unsubscribe from bot', which is a specific verb+resource. It is distinct from sibling tools like subscribe_to_bot, opt_out_email, and opt_out_sms, and the endpoint DELETE /subscriber/unsubscribe-from-bot adds technical 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 on when to use this tool versus alternatives such as pause_bot or opt_out_email/opt_out_sms. The only condition mentioned is the 'Manage Flow' scope requirement, but there is no situational context or differentiation from other subscriber tools.
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?
The description discloses the HTTP method and path (PUT /subscriber/update) and an authorization requirement (Manage Flow scope), providing some behavioral context. However, it does not explain update semantics (e.g., partial vs full update, required user_ns) or what happens to unspecified fields.
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-loading the action and including only a necessary scope note. Every word is useful, with no redundancy.
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 8 parameters, no output schema, and no annotations, the description is too sparse. It omits required parameters, parameter semantics, response behavior, and how this tool differs from the many subscriber-related siblings.
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 parameter information, and the input schema only describes 'image' (13% coverage). With 8 parameters, the description fails to compensate, leaving the agent without meaning beyond the bare 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 states a clear verb+resource: 'Update subscriber data' with an explicit endpoint. However, it does not specify the nature of the data (e.g., profile fields vs custom fields) or distinguish itself from many sibling update tools like cigchat_subscriber_set_user_field.
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 gives no guidance on when to use this tool versus alternatives. It only mentions the required scope, not any use-case 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.
Behavior3/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 usefully discloses that the tool 'Delivers a real message to a person' (a significant side effect) and requires the 'Manage Flow' scope. However, it omits other behaviors such as whether status changes are reversible, idempotency, error conditions, or the response format, leaving gaps in transparency.
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 relatively compact and front-loads the core action and allowed values. It includes the HTTP endpoint and scope requirement without excessive fluff. The phrasing is a bit awkward (running the side-effect statement into the same sentence as the endpoint), but it earns its place by adding the crucial real-message warning.
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 no annotations and no output schema, the description is incomplete. It fails to clarify key parameters like order_id and user_ns, does not describe return values or failure modes, and leaves the 'Delivers a real message' behavior ambiguous (to whom, under what conditions). The provided status list and scope info help, but the lack of detail makes it risky for an agent to invoke correctly in all contexts.
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 only 33%, with only the 'status' parameter having any description. The description adds value by enumerating the valid status values for 'status', but it does not explain the semantics or format of 'order_id' or 'user_ns', which remain undocumented in both the schema and the description. This is insufficient for low 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 action ('Update order status') and provides the complete list of allowed statuses, which gives a specific verb and resource. It is somewhat muddied by the cryptic 'Delivers a real message to a person' phrase and does not explicitly distinguish from sibling tools like cigchat_shop_orders_update, but the tool name and status list make the purpose understandable.
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 provided on when to use this tool versus alternatives such as cigchat_shop_orders_update or cigchat_subscriber_update. The description mentions a scope requirement and the side effect of delivering a real message, which implies caution, but it does not state when to choose this tool or when not to.
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 full behavioral disclosure burden. It mentions a required scope but does not clarify the nature of the update (e.g., partial vs. full replacement), potential side effects, whether the operation is idempotent, or return values. 'Update' implies mutation, but critical behavioral context is missing.
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 action and endpoint. It includes the key prerequisite (Manage Team scope) without unnecessary fluff. Every word earns 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?
Despite having 6 parameters and no output schema or annotations, the description provides minimal context. It does not explain what specific group attributes can be updated, the meaning of the PUT method in this context, or expected outcomes. The tool's complexity demands more explanatory effort than this.
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 description adds no parameter-level information beyond that already present in the schema. Schema coverage is 67% (4 of 6 properties have descriptions), and those descriptions are reasonably clear. Since the schema handles most semantics, the description's lack of parameter detail is acceptable, though it doesn't reinforce or expand on any 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 action ('update agent group') and provides the specific HTTP endpoint, making the resource and operation unambiguous. However, it does not differentiate this from sibling tools like cigchat_team_update_agent_group_users or cigchat_team_create_agent_group, 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?
No explicit guidance on when to use this tool versus alternatives. The only contextual note is the 'Manage Team' scope requirement, which is a prerequisite rather than a usage guideline. No mention of whether this is for updating core settings vs. membership, or relationships to create/delete/update-users 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 available, the description carries full responsibility for disclosing behavioral traits. It fails to mention that this is a mutating operation requiring current password verification, that it permanently changes credentials, or any side effects like invalidating sessions.
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. It is front-loaded with the action and resource. However, it is so brief that it lacks necessary depth for the 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?
For a mutation tool with 3 required parameters and no output schema, the description is insufficient. It doesn't explain the return value, potential errors, or authentication requirements. The schema provides some parameter constraints but not enough to fully understand the operation.
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 only 33% (only password has a description). The tool description does not add any parameter semantics, and the relationship between current_password, password, and password_confirmation is not explained. This leaves the agent guessing about required values.
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 'Change user password [PUT /user/change-password]' clearly states the specific action (change password) and resource (user), and even includes the HTTP method. No sibling tool handles password changes, so it distinguishes itself.
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, any prerequisites, or alternatives. It simply states the action without contextualizing usage 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?
With no annotations, the description carries the full burden. It discloses required scope and input limits, which is useful, but it does not mention side effects (e.g., overwrites, errors) or response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence conveying all key constraints and the endpoint without filler. It is slightly packed but still readable and front-loaded with the main 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 description covers purpose, limits, and auth, but omits important context such as what the response looks like, how the 'type' field is used, and error behavior. For a tool with no output schema, these gaps reduce completeness.
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 max character lengths for heading and text but does not explain the 'type' field or the structure of the rows array beyond the schema's minimal definition.
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 'Import OpenAI Embeddings', which is a specific action on a specific resource, and includes the endpoint. It is distinguishable from sibling tools by name, though it does not explicitly contrast with create/generate.
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 constraints (maximum 100 embeddings, character limits) and an auth requirement, but no guidance on when to use this tool versus alternatives such as create or generate. It lacks explicit 'when/when-not' criteria.
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?
Without annotations, the description carries the full burden. It does disclose the required 'Manage Team' scope and the HTTP PUT method, which are useful traits. However, it does not describe whether it performs a partial or full update, effects on unspecified fields, or the response format, leaving significant gaps.
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. Every piece of information—the action, the endpoint, and the scope requirement—earns its place with no redundancy.
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 six parameters, no annotations, and no output schema, this description is incomplete. It does not explain partial vs. full update semantics, what happens to omitted fields, or what the response contains. The auth scope is helpful but insufficient for correct invocation.
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 only 17% (one of six properties described), so the description should compensate. It does not mention any parameter meanings or which fields can be updated. While names like lat, lng, name, and address are self-evident, 'note' remains ambiguous, and the description adds no clarity.
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 'Update location' with a specific verb and resource, and the endpoint confirms it targets shop locations. It distinguishes from sibling create/delete/get/list tools by the 'update' action, though it is terse.
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 create, delete, or get_info. It only mentions the required scope, which is a prerequisite, not a usage guideline.
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?
The description discloses the required 'Manage Flow' scope, which is a behavioral requirement beyond what the schema provides. However, it does not mention idempotency, duplicate handling, or failure modes, and there are no annotations to cover 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action, endpoint, and auth requirement with no superfluous content. It is well-structured 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?
For a simple 2-param tool with no output schema and no annotations, the description is too brief. It omits parameter semantics (especially user_ns), usage guidance relative to many sibling tools, and any return value expectations, leaving significant gaps for an agent to invoke 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 describes tag_ns (accepts id or name) but user_ns has no description. The tool description adds no parameter information at all, failing to compensate for the 50% schema coverage gap. This leaves the user_ns parameter 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 clearly states the action ('Add tag to subscriber') and provides the endpoint, which identifies the resource and operation. However, it does not distinguish this tool from sibling tools like cigchat_subscriber_add_tag_by_name or cigchat_subscriber_add_tags, so it's not fully differentiating.
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 tag_ns accepts an id or name, which could help decide between this and add_tag_by_name, nor does it provide any exclusions or preconditions beyond the scope requirement.
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 transparency burden. It does disclose a permission requirement ('Manage Flow' scope) and the HTTP DELETE method, signaling a destructive operation. Yet it omits details about whether the field itself is removed or just its value, idempotency, 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 compact and front-loaded, combining the action, endpoint, and auth scope in two short sentences. Every clause adds information with no filler.
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 being a simple 2-parameter mutation, the tool lacks an output schema and annotation support, so the description should explain the parameters and behavior more fully. The unexplained 'user_ns' and lack of success/error return information make it insufficient for confident invocation.
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 coverage is 0% and the description adds little parameter semantics. 'field_name' is lightly implied by the phrase 'by field name,' but 'user_ns' is entirely unexplained, leaving the agent guessing as to what namespace or subscriber identifier is 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 uses a specific verb ('Clear') and resource ('subscriber user field value'), and specifies 'by field name' to disambiguate from similar clear/set field operations. However, it doesn't explicitly contrast with sibling tools like cigchat_subscriber_clear_user_field or clear_user_fields_by_name, so it stops short of full 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?
No guidance is given on when to choose this tool over alternatives such as clear_user_field, clear_user_fields, or clear_user_fields_by_name. The only contextual note is the required 'Manage Flow' scope, which addresses auth, not usage selection.
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 carry the full burden of behavioral disclosure. It does add useful context by stating the required 'Manage Flow' scope and the DELETE HTTP method, implying a mutating operation. However, it does not describe outcome, idempotency, error behavior, or side effects, leaving significant gaps.
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 with no filler. The first sentence states the operation, and the second adds the endpoint and auth requirement, both useful bits. It is 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?
Given no annotations, no output schema, and a partially documented schema, the description is too sparse to be complete. It omits the meaning of user_ns, behavior on missing tags, return format, and how this relates to the numerous sibling tag-removal tools, leaving substantial ambiguity.
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 tool description adds no parameter meaning. The schema documents tag_ns (accepts id or name) but user_ns is completely undescribed, and schema coverage is only 50%. The description neither clarifies user_ns nor reinforces tag_ns, so it fails to compensate for the schema gap.
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 'Remove tag from subscriber' with the DELETE endpoint, identifying the resource and operation. However, it does not distinguish this from sibling tools like cigchat_subscriber_remove_tag_by_name or cigchat_subscriber_remove_tags, so it lacks 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?
The description provides only a prerequisite (requires 'Manage Flow' scope) and no guidance on when to use this tool versus the many related tag-removal operations. It does not mention alternatives, exclusions, or recommended conditions, leaving the agent to guess among similar siblings.
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. It adds useful context: the required 'Manage Flow' scope, the PUT endpoint, and the 20-field cap. But it does not disclose response behavior, error handling, partial-failure semantics, or what happens if a field does not 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?
A single, front-loaded sentence communicates the operation, resource, field limit, endpoint, and auth requirement without redundant filler. Every component adds value.
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 write tool with a nested array parameter, no annotations, and no output schema, the description is too thin. It lacks return-value info, failure behavior, validation rules, and relationship to sibling field-setting tools, leaving the agent under-informed for a relatively complex operation.
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 low, and the tool description does little to clarify the parameters. It mentions 'multiple user field value' and 'up to 20', but never explains `user_ns` or the expected shape of `data` items (value + var_ns). The schema's var_ns description does more work than the tool 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 clearly identifies the action ('Set or update'), target ('subscriber multiple user field value'), and capacity ('up to 20 user fields'), plus the REST endpoint. However, it does not explicitly differentiate this tool from closely related siblings like subscriber_set_user_field or subscriber_set_user_fields_by_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 choose this tool over the many similar subscriber/field manipulation siblings. The only usage-related detail is the auth scope requirement and the 20-field limit, which is a constraint rather than a decision rule.
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?
The description discloses an authentication requirement ('Requires the Manage Flow scope on the token') and a constraint ('up to 20 user fields'), which are useful. However, with no annotations carrying the burden, it does not describe side effects, whether missing fields are created, or response behavior, leaving a moderate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the action, and includes the endpoint and auth scope in two short segments. However, the phrasing 'subscriber multiple user field value' is grammatically awkward and could be clearer, slightly detracting from 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?
For a tool with no annotations, no output schema, and only two parameters, the description provides some context (purpose, limit, auth) but omits crucial details like how user_ns identifies the subscriber and how the data array is structured. Given the complexity and many sibling tools, this incompleteness hinders proper 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 fails to explain the meaning of 'data' or 'user_ns'. It only offers a vague phrase 'subscriber multiple user field value' and does not mention that data is an array of name/value pairs or what user_ns represents. This is insufficient compensation for the lack of 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 clearly states the action ('Set or update') and resource ('subscriber user field value'), and specifies scope ('multiple user field value, up to 20 user fields'). The endpoint URL 'set-user-fields-by-name' distinguishes it from sibling tools like set_user_fields or set_user_field, 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?
No guidance is provided on when to use this tool versus alternatives (e.g., set_user_field_by_name for single fields or set_user_fields for IDs). The description does not mention exclusions, prerequisites beyond the auth scope, or scenarios where this tool is preferred.
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 indicates a mutation ('Update') but does not disclose whether the update replaces all settings, merges with existing ones, toggles booleans, or what happens with invalid/duplicate values. No return value or side effects are described.
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 long sentence that buries the essential verb and resource amid a large list and endpoint info. It is factually dense but poorly structured; a list of values could be separated for readability. Still, there is no filler or repetition.
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 one parameter, no output schema, and no annotations, the description is incomplete. It fails to explain how the 'data' parameter should be composed, whether it is required, or how the update affects existing settings. The many possible values require clearer semantics to avoid incorrect invocations.
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 provides a comprehensive list of valid values, which is valuable. However, it does not explicitly state that these values should be passed as elements in the 'data' array, nor whether the array is required or how partial updates are handled. The schema's 'Example: hide_xxx' is vague.
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 ('Update') and the target resource ('workspace settings for live chat sidebar'). It distinguishes from siblings like 'cigchat_workspace_settings_live_chat_sidebar' (likely a getter) and 'cigchat_workspace_settings_update_channels' by naming the specific resource. The list of available values reinforces the precise 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?
No explicit guidance on when to use this tool versus alternatives. It does not mention that this is for mutating settings and that the sibling 'live_chat_sidebar' tool is likely for reading current settings. The auth scope note is a requirement, not a usage guideline.
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 discloses the required scope and the HTTP method (GET), but says nothing about return format, side effects, pagination behavior, or error conditions. The scope note is valuable but minimal.
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 that front-load the action and include the endpoint for reference. Every phrase earns its place, with no filler. It is appropriately sized for a simple list operation.
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 description combined with the schema covers the essentials: scope, endpoint, filters, and pagination. However, 'by flow' is unexplained, and with no output schema, the return format is not described. This leaves a moderate gap for a straightforward list 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 baseline is 3. The description adds no parameter-level meaning; the schema already provides detailed descriptions for all 5 parameters, including pagination and accepted provider values. The description does not enhance or conflict with 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 'Get list of ai agents by flow' with a clear verb and resource, and the endpoint is provided for reference. It distinguishes from the sibling 'cigchat_flow_agents' by specifying 'ai agents', but the phrase 'by flow' is ambiguous and doesn't explain how the flow is determined.
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 mention of when to use this tool versus alternatives like 'cigchat_flow_ai_agent_info' or 'cigchat_flow_agents'. The only context is the required 'Manage Flow' scope, which is a permission prerequisite, not a use-case guideline. No exclusions or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a concrete behavioral requirement: 'Requires the "Manage Flow" scope on the token' and indicates a read operation via 'Get list'. With no annotations, the description carries the burden but omits details like pagination behavior, response format, or rate limits, though the schema hints at page/limit parameters.
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, with the main action first and the scope requirement appended in a second sentence. The typo 'seaching' and vague 'and so on' are minor issues, but overall it is 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?
With 17 optional parameters, no output schema, and no annotations, the description should provide more context. It does not explain how multiple filters combine, pagination defaults, or what the response structure looks like, making it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists a few example search fields (name, phone, email, tag, custom user field) but adds no meaning beyond what the schema already provides; 'and so on' is vague and not helpful.
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 'Get list of subscribers by searching for name, phone, email, tag, custom user field and so on' with a clear verb and resource. It distinguishes from sibling tools like get_subscriber or broadcast_to_list by emphasizing search/filter, though it doesn't explicitly name 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?
No guidance on when to use this tool versus alternatives (e.g., get_subscriber for a single subscriber). The description only mentions the endpoint and scope requirement, but does not explain selection criteria 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?
The description discloses that it 'Delivers a real message to a person' and requires a specific token scope, providing some transparency about impact and auth. However, it does not mention side effects, error behavior, or subscriber opt-out considerations, and with no annotations the description carries the full burden.
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 long, front-loaded with the action and endpoint, and every word contributes meaningful information. No redundancy or filler.
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 the basic purpose and auth requirement but lacks parameter semantics, usage guidance, and behavioral caveats. With no annotations and no output schema, it is insufficient for confident invocation, particularly for a tool that sends real messages to people.
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 description does not explain user_ns or the expected format of flow_name. The only hint is the phrase 'flow name', leaving both parameters semantically 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: 'Send sub flow to subscriber by flow name' and includes the HTTP endpoint for confirmation. It distinguishes from siblings like cigchat_send_subflow_by_user_id by specifying 'by flow name' and 'subscriber'.
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 send_subflow_by_user_id or send_main_flow. The only contextual information is a requirement for the 'Manage Flow' scope, which is a prerequisite, not usage guidance.
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 burden of behavioral disclosure. It mentions the required scope but says nothing about side effects, response format, validation behavior, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that includes the action, endpoint, and a critical prerequisite. It is front-loaded, free of fluff, and every word earns 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?
With 19 parameters, no annotations, and no output schema, a one-sentence description is severely under-specified. It does not explain the return value, parameter usage, or any post-creation behavior, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level guidance. Schema coverage is only 58%, and many parameter descriptions are just examples (e.g., 'Example: 100') rather than meaningful semantics, so the tool description does not compensate for this 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 clearly states 'Create new product' and includes the endpoint 'POST /shop/products/create', making the action and resource explicit. It distinguishes from siblings like update/delete, which are alternative operations on the same resource.
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 explicit guidance on when to use this tool versus alternatives like update or delete. The only additional information is a prerequisite (requires 'Manage Team' scope), but no context about the use case 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. It mentions the 20-tag limit and the required scope, but fails to disclose behavior regarding duplicate tags, non-existent tag names, partial failures, or the response format—important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the action, the limit, the endpoint, and a required scope. Every word earns its place with no redundancy.
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 required parameters, no output schema, and no annotations, the description is too sparse. It omits parameter semantics, success/error behavior, and how the subscriber is identified, leaving the agent with significant ambiguity.
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 does not explain the 'data' array or 'user_ns' parameter. The phrase 'by tag name' hints at data containing tag names, but 'user_ns' remains unclear, and the schema's ambiguous anyOf structure is not clarified.
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: 'Add tags by tag name to subscriber', identifies the resource (subscriber), and provides the endpoint and a specific limit (up to 20 tags). This distinguishes it from sibling tools like add_tag_by_name (single) and add_tags (likely by ID).
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 on when to use this tool versus alternatives such as add_tag_by_name or add_tags is given. The only extra context is the required 'Manage Flow' scope, which is a prerequisite, not a usage recommendation or exclusion.
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. It discloses the authentication scope ('Manage Flow') but does not explain what happens on success, whether the operation is idempotent, or what response to expect. It also doesn't clarify if this appends or replaces cart items.
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 and front-loaded with the key verb and resource. No filler words; every phrase earns 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 is a mutation with no annotations, no output schema, and weakly described parameters. The description omits critical context such as the response format, error behavior, or how this relates to other cart tools like remove_from_cart. It's 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 description doesn't explain any parameters. The schema provides only example values for qty and variant_id, and user_ns has no description, leaving the required identifier ambiguous. With 67% coverage but no semantic meaning, the description fails to clarify what these fields represent.
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 states a specific verb ('Add') and resource ('item to subscriber shopping cart'), and includes the endpoint. This clearly distinguishes it from sibling tools like remove_from_cart and empty_cart.
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 such as remove_from_cart or cart. The only contextual information is the required 'Manage Flow' scope, which is a prerequisite, not a usage guideline.
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?
The description discloses the HTTP method (DELETE), the endpoint, and a required scope ('Manage Flow'), which adds useful behavioral context. However, since there are no annotations, it fails to disclose irreversibility, what 'clear' does to the fields, or error/limit behavior beyond the 20-field cap.
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 compact and front-loaded with the main action, then adds endpoint and scope in a delimited form. No filler or repetition; every sentence earns 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?
For a destructive mutation tool with no annotations and no output schema, the description is too thin. It omits a critical explanation of 'user_ns', does not specify the semantics of 'clear', and provides no guidance on when to use this over the by_name variant. The endpoint and scope help, but the overall picture is 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 only mentions 'up to 20 user fields', which vaguely relates to the data array, but does not explain the 'user_ns' parameter or the 'var_ns' semantics beyond what is already in the schema. The description adds minimal guidance for parameter usage.
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 ('Clear multiple subscriber user fields'), the resource, and a limit ('up to 20 user fields'), with a concrete endpoint. It differentiates from singular sibling tools by emphasizing 'multiple', but does not explicitly distinguish from the by_name sibling variant (cigchat_subscriber_clear_user_fields_by_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?
Usage context is implied through 'multiple' and the endpoint path, suggesting it is for batch clearing. However, no explicit when-to-use vs alternatives (like clear_user_field or clear_user_fields_by_name) or exclusions are provided. The scope requirement is a prerequisite, not a usage guideline.
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?
The description discloses the HTTP method (DELETE) and the required OAuth scope ('Manage Flow'), which are useful behavioral details. However, it does not explain the side effects of the operation beyond removal, such as irreversibility, idempotency, or what happens if the tag does not exist. With no annotations, the description carries the burden but only partially meets 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 a single sentence plus endpoint and scope note, with no redundant words. It is front-loaded with the primary action and contains only essential information. This is 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 description is adequate for a simple delete operation, including the method and required scope. However, it does not describe the meaning of `user_ns`, which is a required parameter, nor does it mention return values or error behavior. Given the lack of output schema and the presence of many related subscriber operations, this is a moderate gap.
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 implies that `tag_name` refers to the name of the tag to remove ('by tag name'), but it does not explain the `user_ns` parameter, which is likely a subscriber identifier. With 0% schema description coverage, the description should clarify both parameters, but it leaves `user_ns` undefined. This adds minimal value 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 the action: 'Remove tag from subscriber by tag name,' which is a specific verb and resource. It includes the endpoint and implies the distinction from removing by tag ID. However, it does not explicitly contrast with sibling tools like remove_tags_by_name or remove_tag.
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 choose this tool over alternatives. The description only mentions the requirement for the 'Manage Flow' scope, which is a prerequisite, not usage context. There is no mention of when to use by-name vs by-ID or singular vs plural 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, the description carries the transparency burden. It discloses that this is an update (PUT) requiring 'Manage Team' scope, but gives no details on side effects, idempotency, return value, or error behavior. This is typical but sparse 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?
Two terse sentences: action stated first, then endpoint and scope. Every word earns its place, no fluff or redundancy.
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?
For a simple parameter update with no output schema, the description provides the core action and auth requirement. Missing elements like return value or confirmation are not critical given the tool's simplicity, but could be improved with one sentence about success/failure behavior.
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 only 50% (tagId described, name not). The description adds meaning for 'name' by saying 'Update tag name', implying the name parameter is the new value. However, it doesn't fully compensate for the missing schema description of name or any 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 states 'Update tag name' with a clear verb and the HTTP path specifies 'product-tags', distinguishing it from tag create/delete/get/list siblings. While it doesn't explicitly say 'product tag' in the prose, the tool name and endpoint resolve ambiguity.
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 vs alternatives like create/get/delete product tags. It only provides the required scope ('Manage Team') and the HTTP endpoint, but no situational context 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?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It does state a specific auth requirement (Manage Flow scope), but fails to describe what the sync actually does—e.g., whether it fetches templates from an external source, overwrites local data, or returns a list. This is a significant gap for a 'sync' operation.
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 brief, with two sentences that each add value: one states the action, the other gives a critical authorization requirement. There is no fluff or repetition, making it well-structured 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 no parameters and no output schema, the tool's inherent complexity around the 'sync' action is left unexplained. The description does not clarify what synchronization entails, what changes occur, or what the caller should expect. This is incomplete for an operation with potential side effects.
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 in its schema, so there is no parameter semantic burden. A baseline score of 4 is appropriate because the description cannot add parameter meaning where no parameters exist.
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 ('Sync') and resource ('Whatsapp templates'), and includes the endpoint path, which distinguishes it from sibling tools like list, create, and delete. However, the exact meaning of 'sync' is somewhat ambiguous—it doesn't specify direction or effects—so it stops short of 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. The only additional note is a required scope ('Manage Flow'), which is a prerequisite rather than usage direction. No mention of scenarios, exclusions, or sibling tool comparisons.
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 states the action ('mark as read') but provides no information about side effects, authentication requirements, idempotency, or what happens to the announcement. Given zero parameters, it's unclear how the target announcement is identified or what the system considers 'read'.
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: 'Mark announcement as read [POST /announcements/read]'. It front-loads the action and includes the endpoint for reference. Every element earns its place; no wasted 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?
For a 0-parameter tool with no output schema, the description is minimally adequate. It states the core action but lacks context about how the announcement is selected, any preconditions, or what the response might be. Still, given the simplicity, this is a reasonable baseline.
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?
With zero parameters, there is nothing for the description to explain. The 0-params baseline is 4, and the description does not need to add parameter details. The empty input schema already conveys that no arguments 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 verb+resource: 'Mark announcement as read', making it obvious the tool marks an announcement as read. However, it does not differentiate from sibling tools like cigchat_notifications_read, which performs a similar 'read' action on a different resource.
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 the distinction between announcements and notifications, nor does it provide any context for when marking an announcement as read is appropriate. The usage must be inferred solely from the name and description.
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 disclose behavioral traits. It does mention the required 'Manage Flow' scope, which is useful, but it does not clarify what 'current flow' means, nor describe the response shape or side effects. The auth constraint adds some transparency, but overall the description is thin for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action front-loaded, followed by the endpoint and auth requirement. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the description is incomplete. It doesn't explain 'current flow', what the response contains, or how to find the id (e.g., using list_closing_notes). The auth requirement is helpful, but an agent would still have to guess at key execution details.
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 one parameter 'id' with no description coverage. The description's endpoint [GET /flow/closing-notes/{id}] implies id is the closing note identifier, providing some meaning beyond the bare schema. However, it does not explicitly define id or how to obtain it, so it only partially compensates for the 0% 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 'Get a closing note from the current flow' with a specific verb and resource. It distinguishes from sibling tools like list_closing_notes, create/update/delete, and includes the API endpoint for precision.
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. It doesn't mention that this fetches a single note by ID or suggest list_closing_notes for browsing. 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 must disclose safety and behavioral traits. It only mentions the HTTP method/endpoint and the required scope. It does not disclose return format, pagination behavior, default limits, or any side effects (though likely read-only). This is a minimal disclosure that leaves significant uncertainty about runtime 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 a single, focused sentence that immediately states the action and includes the endpoint and a security requirement. There is no filler or redundant information, and it is front-loaded with the core purpose.
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 is a list operation with no output schema, so the description must compensate for missing return value details. It does not explain what fields are returned, how pagination works (e.g., defaults for page and limit), or whether the 'code' parameter performs a partial or exact search. The scope requirement is helpful, but overall the context is insufficient for an agent to invoke it confidently.
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: each parameter (code, page, limit) has a description. The description adds no additional parameter details beyond the schema, so it meets the baseline of 3 but does not enhance understanding further.
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 states a specific verb+resource: 'Get list of discount codes', which clearly identifies the operation. It also includes the HTTP endpoint [GET /shop/discount-codes], and the name 'list_discount_codes' distinguishes it from sibling tools like 'get_info' or 'delete' for the same resource.
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 on when to use this tool vs alternatives such as cigchat_shop_discount_codes_get_info. The description does mention a prerequisite (Manage Team scope), but this is a permission requirement, not usage context. The 'list' behavior is implied, but there is no comparison to other related tools.
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?
The description discloses the HTTP method (GET) and the required token scope, which are useful behavioral traits beyond the schema. However, it does not mention pagination, response format, or any potential side effects. With no annotations, this leaves the agent needing to infer these details, so transparency is moderate.
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 plus a requirement clause, with no filler. It is front-loaded with the core action and includes the endpoint and auth requirement efficiently.
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 lack of an output schema and the presence of optional pagination and filter parameters, the description is incomplete. It does not explain response structure, default pagination, or how the parameters affect results, making it insufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (page, limit, user_ns), covering 100%. The description adds no extra meaning beyond the schema, so the baseline 3 is appropriate.
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 'Get list of orders' and includes the HTTP endpoint '[GET /shop/orders]', which uniquely identifies the resource. It is specific to orders, though it does not explicitly differentiate from sibling list tools, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided; it does not mention alternatives like shop_orders_get_info for single orders or explain how to filter or paginate. The only additional context is the required 'Manage Team' scope, which is a prerequisite rather than usage 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?
The description discloses the required 'Manage Team' scope and the HTTP method/path, which adds behavioral context beyond the bare tool name. However, it doesn't mention pagination behavior, response format, or any safety implications (e.g., read-only nature). With no annotations, more detail would be expected.
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 containing both the purpose and the auth constraint, with no unnecessary words. Each piece of information is useful, though it could benefit from a slightly more structured format.
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?
For a simple list operation, the description covers the basic function and a key requirement, but it omits details like response shape, pagination limits, or whether the list is ordered. The schema helps with parameters, but the lack of an output schema and annotations leaves some gaps.
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 provides full descriptions for all three parameters (name, page, limit), so the description adds no extra meaning. The description doesn't mention any parameter relationships or defaults, but the schema covers semantics sufficiently.
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 list of locations, distinguishing it from sibling CRUD operations like create/update/delete/get_info. The endpoint is included, adding specificity. However, it doesn't explicitly clarify the scope (e.g., all locations vs filtered) beyond what the schema parameters imply.
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 cigchat_shop_locations_get_info. The description gives no exclusions or alternative suggestions. The only additional context is the required auth scope, which is a prerequisite, not a usage guideline.
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 states the operation is a GET request but does not mention authentication requirements, rate limits, or the exact structure of the returned user info. The read-only nature is implied but not explicitly stated.
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 phrase that includes both the action and the endpoint, making it extremely efficient and front-loaded with essential 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?
Given zero parameters and no output schema, the description provides the core purpose but leaves out details about return value shape, authentication, or potential errors. It is adequate for a simple GET /me endpoint but not fully complete.
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 takes no parameters, and schema coverage is 100% vacuously. The description adds no parameter details because none are needed, earning the baseline score of 4 for zero-parameter tools.
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?
Description clearly states 'Get current user info' and includes the API endpoint [GET /me], making the purpose specific and unambiguous. However, it does not differentiate from the sibling tool cigchat_whoami, which likely serves a very similar 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 like cigchat_whoami or cigchat_resolve. There are no usage contexts, prerequisites, or exclusions 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?
With no annotations, the description carries full burden for behavioral disclosure. It reveals this is a POST mutation (not a read-only operation despite the 'read' in the name), but does not disclose side effects, idempotency, authorization needs, or error behavior when notification_id is invalid.
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 that front-loads the action and includes the endpoint. There is no fluff, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. It does not mention what the response looks like, how to obtain notification_id (e.g., from cigchat_notifications_recent), or any post-conditions. The minimal information is insufficient for an agent to confidently invoke and interpret the result.
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 for notification_id, but the description is only an example UUID, not a semantic explanation. The tool description adds no parameter context beyond what the schema provides, so it scores at the baseline for high 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 action ('Mark notification as read') and the resource ('notification'), distinguishing it from sibling tools like cigchat_notifications_recent (likely a listing tool) and cigchat_announcements_read (targets announcements, not notifications). The explicit HTTP endpoint adds further 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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites such as obtaining notification_id from a list operation. The description simply states the action without any contextual usage instructions 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. It only says 'Get recent notifications and announcements' and shows a GET endpoint, which implies a read operation, but it does not disclose return format, recency window, pagination, or any other behavioral details.
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 includes the endpoint. Every word earns its place, and it is appropriately front-loaded with the verb and resource.
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?
For a zero-parameter read endpoint, the description is minimally adequate but leaves gaps: 'recent' is undefined, the response shape is not described, and no distinction is made from sibling notification/announcement tools. It is workable but not rich enough to be fully self-contained.
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 input schema has zero parameters, so there is nothing for the description to explain. The baseline for zero-parameter tools is 4, and the description correctly adds no parameter-related claims.
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 operation ('Get') and the resource ('recent notifications and announcements'), and even includes the endpoint. However, it does not differentiate from sibling tools like cigchat_notifications_read or cigchat_announcements_read, so it falls short of 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 given about when to use this tool versus alternatives. There are overlapping sibling tools for reading notifications and announcements, but the description does not mention them or define when 'recent' is the right scope.
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. While it mentions the 'Manage Team' scope requirement, it does not disclose side effects, response format, or any potential destructive implications. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the key action front-loaded. Every word earns its place, and it avoids unnecessary repetition of schema or endpoint details beyond what is 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?
The tool has 12 parameters, no output schema, and no annotations, making it moderately complex. The description is too minimal: it lacks guidance on how optional parameters interact, what the response contains, and under what conditions variant creation succeeds. The schema covers parameter names but not the business logic needed 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 83%, so the baseline is 3. The description itself adds no parameter semantics beyond what the schema already provides. The schema descriptions are present, but the description does not explain the role of parameters like variant_1_value, price, or taxable in the context of creating a variant.
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 and resource: 'Create new product variant' with the endpoint '[POST /shop/products/{productId}/variants/create]'. This unambiguously identifies what the tool does and distinguishes it from sibling tools like update/delete variants.
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 does not provide guidance on when to use this tool versus alternatives. No exclusions or mentions of other tools for creating variants (e.g., cigchat_shop_products_variants_update) are given. The only additional context is the required scope, which is a prerequisite rather than a usage guideline.
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 does mention the required 'Manage Team' scope and the GET method, implying a read-only operation. However, it does not describe the return structure, pagination, or potential errors, which is a notable gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two short sentences, front-loading the action and immediately providing the endpoint and auth requirement. No unnecessary fluff, but the phrase 'Get type info' is slightly redundant with the tool name.
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?
For a simple get-info tool with one parameter and full schema coverage, the description covers the essentials: action, endpoint, and auth. However, it lacks any description of what the response contains or how the typeId relates to other product-type operations, so an agent might not know what to do with the result or when to prefer this over sibling info 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 provides 100% coverage for the single parameter 'typeId' with description 'Type Id'. The description's endpoint path reinforces that typeId is a path parameter, but it adds no additional format, source, or example beyond the schema. Baseline 3 is appropriate given 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 states 'Get type info' with the endpoint GET /shop/product-types/{typeId}/get-info, clearly indicating a read operation for a product type resource. It is distinguishable from sibling tools like cigchat_shop_products_get_info and cigchat_shop_product_vendors_get_info by the 'product-types' path segment, though it does not explicitly say 'product type info'.
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 related list/create/update/delete tools or any prerequisite besides the auth scope. The context is minimal and leaves the agent to infer usage from the name.
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 carry the full burden. It discloses the destructive nature of the operation (emptying the cart) and the required auth scope, but does not mention irreversibility, side effects, or what the response contains. This is basic but not deeply informative.
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?
A single sentence contains the action, endpoint, and auth requirement. It is front-loaded with the most important information and contains no filler.
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?
For a simple tool with one parameter and no annotations, the description covers the core action and auth but lacks parameter semantics and behavioral details. It is minimally adequate but has clear 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?
There is only one parameter (user_ns), and the input schema provides no description. The tool description does not explain the meaning, format, or expected values of user_ns, leaving the agent 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 clearly states the action ('Empty subscriber shopping cart items') and the resource, with a specific verb that distinguishes it from siblings like 'cigchat_subscriber_remove_from_cart' (which removes a single item). The endpoint reference adds further 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 on when to use this tool versus alternatives. It mentions the required 'Manage Flow' scope, which is a precondition, but does not explain 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It does reveal that the operation is a GET request, the endpoint path, and the required 'Manage Team' scope, which indicates a read operation with a permission requirement. However, it omits details about pagination behavior, default limits, response format, or whether filters combine as AND/OR, leaving significant gaps for a tool with 11 parameters.
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 one core sentence plus the endpoint and scope. It is front-loaded and contains no fluff. The minor typo 'seaching' slightly detracts but does not affect overall clarity or 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 11 optional parameters and no output schema, yet the description does not explain what the response contains, default pagination values, or how filters interact. It does provide the endpoint and auth scope, but for a tool with this parameter complexity, the description is insufficient for an agent to fully understand behavior without additional assumptions.
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 baseline is 3. The description mentions name, phone, and email as searchable fields, but adds no new meaning beyond the schema. It does not clarify filter combination logic, default values, or the meaning of 'and so on' for the remaining 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 'Get list of bot users' with a specific resource and filtering by name, phone, email. It includes the HTTP endpoint and required scope, helping to distinguish it from sibling tools like cigchat_flow_bot_users_count or cigchat_team_members. However, the phrase 'and so on' is vague and doesn't explicitly differentiate it from other subscriber list 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 provided on when to use this tool versus alternatives. It doesn't mention when to prefer this over cigchat_search_subscribers or other list tools. The only contextual hint is the 'Manage Team' scope, which is an authorization prerequisite rather than a usage guideline.
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 disclosure burden. It discloses the HTTP method and required authentication scope, which are useful behavioral traits, but it does not mention potential errors, idempotency, or response behavior. This is reasonable for a simple create endpoint but 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 a single sentence with no filler, front-loading the action ('create new label') and then appending the endpoint and scope. Every word 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?
For a low-complexity tool with one parameter and no output schema, the description covers the action, endpoint, and required scope. However, it omits parameter semantics and potential error conditions, leaving it only minimally 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?
The input schema has 0% description coverage for the single `name` property, and the description adds no parameter meaning. The agent only knows that `name` is a required string, with no constraints, uniqueness, or format details 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 uses the specific verb 'create' and the resource 'label', and includes the HTTP endpoint, making the tool's function unambiguous. It implicitly distinguishes this from sibling list/delete label tools, though it does not explicitly mention them.
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 gives an explicit prerequisite ('Requires the Manage Team scope on the token') but no direct guidance on when to use this tool versus alternatives. The usage context is implied by the action 'create new label' but there are no exclusions or sibling comparisons.
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 the required scope (auth) and implies a read operation via 'GET', which is useful. However, it does not describe return format, pagination behavior, or any side effects, leaving gaps for a complete behavioral picture.
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, front-loading the main purpose and then adding the endpoint and scope requirement. Every word earns its place, with no redundancy or filler.
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 a simple 4-parameter list tool with no output schema, the description is thin. It fails to explain what 'workspace bots' are in this context, what the response looks like, or how pagination works. The agent is left without crucial return-value context, making this less complete than similar 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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no parameter-specific information beyond what the schema already provides, neither enhancing nor harming 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 'Get list of workspace bots' with the endpoint '[GET /team-flows]', giving a specific verb and resource. However, it doesn't differentiate from similar list tools like cigchat_team_bot_users or cigchat_flow_agents, so it's clear but not fully distinguished.
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 only guidance is the auth requirement ('Requires the Manage Team scope'), which is a prerequisite rather than usage context. There is no mention of when to use this tool versus alternatives or any exclusions, so the agent gets minimal 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, so the description must carry full behavioral disclosure. It mentions the auth scope requirement, which is useful, but does not explicitly state read-only behavior, pagination, error handling, or any side effects. The 'Get' verb and endpoint imply read-only, but that is implicit rather than clearly disclosed.
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 concise and front-loaded, stating the action, including the endpoint for API clarity, and adding the auth requirement in a second short sentence. No wasted words or redundancy.
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 6 parameters and no output schema, the description lacks essential context. It does not explain what 'ticket list items' are, what the response shape looks like, or how pagination works (despite page/limit parameters). The mention of the required scope is helpful but not enough to make the tool usable without further inference.
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 already having a clear description. The tool description does not add any extra semantics for the parameters, 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 states 'Get list of ticket list items', specifying the verb (Get), the resource (ticket list items), and the exact endpoint. The term 'items' distinguishes this from sibling tools like cigchat_team_ticket_lists that list the lists themselves, and from create/update/delete variants.
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 mentions a required scope ('Requires the Manage Team scope') and gives no context about when this tool is appropriate, what it replaces, 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?
The description discloses the required 'Manage Team' scope, which is valuable beyond the schema. It also implies a PATCH-like behavior (only changed fields are updated). However, it does not mention response format, side effects, or what happens to omitted fields, leaving gaps for a mutating operation with no annotations.
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 includes the endpoint and a critical authorization requirement. It is concise and front-loaded with the core action, with no filler or redundant 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 complexity (26 parameters, nested objects) and lack of output schema/annotations, the description is too minimal. It does not explain the ticket list context, how this relates to other ticket list tools, or provide enough background for an agent to use it confidently without additional exploration.
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 provides descriptions for many parameters (dates, selects, comments, multi-selects), covering about 54% of them. The description adds the instruction to include only changed fields, which clarifies partial-update semantics but does not detail individual parameters. This adds marginal value 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 clearly states the action ('update a ticket') and references the specific endpoint. The verb and resource are unambiguous, and the name itself reinforces this. However, it does not explicitly distinguish among sibling tools like create or delete, though the update semantics are evident.
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 other ticket list operations (create, delete, items). The only usage note, 'include only the fields that need to be changed', is a partial-update instruction but does not address prerequisites, alternatives, or scenarios.
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 does disclose the required 'Manage Team' scope and the HTTP endpoint, which is useful. However, it omits behavioral details such as whether generating a new link invalidates previous ones, whether the link is single-use (beyond the name), and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action, endpoint, and a key prerequisite efficiently. Every element serves a purpose.
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 no output schema, so the description should explain the return value or expected outcome. It merely says 'generate link' without stating what the link is for, what it returns, or any context about its usage. Given the simplicity, key details are missing.
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 (templateNs and days both have descriptions). The tool description does not add extra parameter-level information 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 action ('Generate template one time install link') and the resource (template). It is specific and includes the endpoint, but it does not explicitly differentiate from sibling tools that also involve templates, such as cigchat_template_installs or cigchat_list_templates.
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 mentions a required scope, not when this tool is appropriate or when another should be chosen. No exclusions or alternative references are given.
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 transparency burden. It does note the required 'Manage Flow' scope on the token, which is useful, but it does not describe side effects, approval process, response format, or other behavioral traits.
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 brief and includes a direct link and endpoint reference. The bracket notation and multiple URLs add slight clutter, but it remains appropriately sized.
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 creation tool with 4 required parameters and no output schema, the description is thin. It lacks information about return values, template approval expectations, and parameter format details, making it incomplete for confident invocation without external lookup.
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 only 50% (name and components have descriptions, category and language don't). The description adds no parameter details and merely points to the Facebook docs via a link, leaving the agent without guidance on category/language values.
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 states 'Create Whatsapp template' with a specific verb and resource, and references the exact API endpoint, clearly distinguishing it from sibling list/delete/sync 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 when-to-use guidance or alternatives are provided. The description does not mention related template tools or conditions for choosing this over broadcast/list/delete 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 mentions the required scope but does not explain side effects, response behavior, or whether creation overwrites existing templates. 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 concise sentence that front-loads the primary action and includes the endpoint and scope requirement. Every word earns its place, though a slightly more structured formatting could improve readability.
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 is a create tool with a complex nested 'components' array and no output schema. The description does not explain the structure of components, required formats, or return behavior, leaving the agent under-informed 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 67% (name and components have descriptions, language does not). The description adds no parameter-level detail 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 the specific verb 'Create' with the resource 'Facebook utility message template', clearly distinguishing this from sibling list/delete/sync tools. The endpoint path is also included for reference, making the tool's function unambiguous.
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 its use case through the verb 'Create' but provides no explicit guidance on when to use it versus alternatives like listing or deleting templates. It does state a prerequisite (Manage Flow scope), which offers some contextual 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 carries the full burden of disclosing side effects and access requirements. It does disclose the required 'Manage Flow' scope, which is a useful behavioral constraint. However, it only says 'Get list', implicitly indicating a read operation, and does not explicitly state that it has no side effects, nor does it describe pagination or return characteristics beyond what the schema 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 immediately states the action and resource, followed by the endpoint and required scope. Every word adds value, and it is very concise without unnecessary elaboration.
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 a simple list operation with four optional parameters all documented in the schema. The description provides the endpoint and auth requirement, which is essential. However, it does not mention the absence of an output schema or clarify that results are paginated (though the page/limit params imply this). Given the simplicity and sibling confusion, the description is adequate but not rich enough for a higher score.
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?
Since the schema covers 100% of the parameters with descriptions (name, page, role, limit), the description does not need to re-explain them. The tool description adds no additional parameter details, which is acceptable because the schema provides sufficient 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 and resource: 'Get list of agents' with the specific endpoint '/flow/agents'. This is more specific than the name alone, but it does not explicitly distinguish from the sibling tool 'cigchat_flow_ai_agents', which likely lists AI agents. However, the endpoint and the context of 'agents' versus 'AI agents' provides enough clarity for most cases.
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 'Requires the Manage Flow scope' is a prerequisite rather than usage context. It does not mention when to prefer this over other agent-related tools like flow_agent_summary or flow_agent_activity_log_data.
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 of behavioral disclosure. It reveals the HTTP method (GET) and the required 'Manage Flow' scope, which are useful, but does not describe return format, pagination, or any side effects. This is minimal but non-tautological.
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 with no fluff. It front-loads the action and resource, then adds scope information. Every word 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 description is adequate for a simple GET request, but with no output schema and no annotations, it could benefit from explaining what the summary contains or how it differs from raw data tools. The lack of return value details leaves some ambiguity.
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% for both parameters, with descriptions present for 'range' and 'event_ns'. The description adds no additional parameter meaning beyond the schema, but none is needed given the high schema coverage, so baseline 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 tool gets a 'flow custom event summary' and provides the exact endpoint, making the purpose unambiguous. It is distinguishable from sibling tools like flow_custom_events_data by the word 'summary', though it doesn't 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?
No guidance is given on when to use this tool versus alternatives. It only mentions the required scope, but provides no context about use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage.
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 full transparency burden. It does disclose the required 'Manage Team' scope and the HTTP endpoint, providing some insight into authorization. However, it does not explicitly state whether the operation is read-only, what the response includes, or any rate limits or pagination, leaving gaps in behavioral 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 a single sentence that front-loads the core action ('Get the flow summary'), includes the endpoint, and states the required scope. There is no wasted wording, and the essential information is presented efficiently.
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, but with no output schema, the description does not clarify what the flow summary contains or how to interpret the response. While the schema covers parameters well, the description lacks broader context about return shape or typical use, making it adequate but with clear gaps.
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 fully documents both parameters (range and flow_ns) with clear descriptions of accepted values and behavior, achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the flow summary' with a specific verb and resource, and includes the endpoint. It is distinct from siblings like flow_agent_summary and flow_custom_events_summary, but does not explicitly differentiate itself from these alternatives, leaving some ambiguity about the exact scope of 'flow summary'.
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 neither mentions use cases nor exclusions, and fails to indicate that other summary tools (e.g., flow_agent_summary, flow_custom_events_summary) might be more appropriate for specific needs. The only secondary context is the 'Manage Team' scope requirement, which is about authorization, not usage.
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 behavioral disclosure. It does disclose the required 'Manage Flow' scope, which is useful auth context. However, it does not mention the effects of the update, error behavior, or idempotency, leaving the mutation consequences implicit.
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 with no fluff. The first sentence states the purpose and endpoint, the second gives the auth requirement. Every word earns its place, and the structure is 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?
For a 3-parameter mutation tool with no annotations and no output schema, the description is too sparse. It does not explain what a shortcut is, what fields can be updated, or what response to expect. The auth scope is helpful, but major usage and semantic gaps remain.
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 only 33% (only 'id' has a trivial example). The description adds no meaning beyond the schema; it does not explain what 'name' or 'value' represent, their optionality, or how they relate to the shortcut. With low schema coverage, the description was expected to compensate but did not.
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 'Update a shortcut' with the specific endpoint, establishing the verb (update) and resource (shortcut). It distinguishes from sibling create/delete/get shortcut tools by the operation type.
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 updating an existing shortcut, but provides no explicit when-to-use vs alternatives, no prerequisites (e.g., shortcut must exist), and no guidance on when to use create/delete instead. The context is implied by the tool name rather than stated.
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 behavioral disclosure burden. It adds an auth requirement (Manage Flow scope) and implies a read operation via 'Get', which is helpful. However, it does not describe return fields, error behavior, or any additional constraints beyond the endpoint and scope.
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 compact and front-loaded: two clauses, each adding distinct information (what and endpoint/auth). There is no fluff, and the sentence earns its place by giving the endpoint and a prerequisite.
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 simple one-parameter GET operation, the description is minimally viable with endpoint and auth scope. However, the existence of cigchat_get_subscriber_by_user_id creates a critical ambiguity, and the absence of any mention of alternatives or output expectations leaves a clear completeness gap.
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 already has 100% coverage with a description for user_ns, so the baseline is 3. The tool description adds no additional semantic meaning about the format, origin, or acceptable values of user_ns, leaving the agent to rely only on the schema's minimal 'Subscriber user_ns' text.
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 as 'Get subscriber info' and provides the explicit endpoint GET /subscriber/get-info. However, it does not distinguish this from the sibling tool cigchat_get_subscriber_by_user_id, which appears to serve a similar purpose with a different identifier.
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 gives a prerequisite (requires 'Manage Flow' scope) but offers no guidance on when to use this tool versus alternatives like cigchat_get_subscriber_by_user_id or cigchat_search_subscribers. There is no mention of what scenario warrants user_ns versus user_id, leaving selection to chance.
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. It discloses the HTTP method (GET) and a required auth scope, implying a read-only operation. However, it does not disclose return format, pagination behavior, or any side effects. The auth requirement adds some value beyond a bare 'list' statement.
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 that includes the operation, endpoint, and auth requirement. No wasted words; every element serves a purpose.
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 a clear name and endpoint. The description is adequate for a basic list operation, but given many sibling list tools, it could benefit from clarifying what type of templates (e.g., generic vs. WhatsApp) and any notable behavior. It does not explain return values, but no output schema exists, so that burden is not explicitly required.
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 each parameter (name, page, limit) has a clear description in the schema. The tool description adds no parameter-specific information 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 tool gets a list of templates, with the endpoint [GET /templates] and a required scope. It is specific about the verb and resource, though it does not explicitly differentiate from sibling tools like 'cigchat_whatsapp_template_list' beyond the resource name. Still, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires the 'Manage Team' scope on the token') but provides no guidance on when to use this tool versus alternatives. It does not explain scenarios or exclusions, so an agent gets little direction on selection.
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 must carry the burden. It discloses the auth requirement (Manage Team scope) and, through the GET method, implies read-only behavior. However, it does not describe what 'info' includes, error behavior, or what happens if the ID doesn't exist, leaving some behavioral 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 short sentences: one for the action/endpoint and one for the authentication requirement. Every word contributes useful information, and the key action is front-loaded. No fluff or unnecessary detail.
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?
For a single-parameter get-info tool with no output schema, the description covers the action and auth constraint, which is adequate for invocation. However, it fails to explain what 'embedding info' returns or what the agent should expect in the response, which would be valuable given no output schema exists. It does not mention alternative retrieval methods or the significance of the ID.
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% (id is described as 'Id' with integer type). The description adds no new meaning beyond the endpoint path showing {id}, which reiterates the parameter but doesn't clarify what the ID refers to or any constraints beyond the schema. Baseline is 3, and the description neither improves nor worsens it.
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 'Get embedding info' with a specific HTTP endpoint, clearly identifying it as a read operation for a single embedding resource. While it doesn't explicitly distinguish from sibling openai_embeddings_* tools, the name and endpoint make its role obvious among create/delete/update/generate/import 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?
The description provides a prerequisite ('Requires the Manage Team scope on the token') but offers no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving details about a specific embedding ID or contrast it with list/create/update operations, so the agent has to infer usage from the endpoint.
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?
Despite no annotations, the description usefully discloses that the operation requires the 'Manage Flow' scope and clarifies that it delivers a real message, implying a side effect. However, it does not mention reversibility, possible failures, rate limits, or response behavior, leaving a moderate 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 two short sentences, front-loaded with the core purpose and endpoint, followed by the required scope. Every sentence adds distinct value with no redundancy or filler.
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?
For a simple two-parameter mutation tool with no output schema, the description covers purpose, permission, and the fact that it is a real message. However, it lacks details on when to use it relative to closely related siblings and does not explain the return/error behavior, leaving it only minimally 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?
The description's phrase 'Send sub flow to subscriber' maps naturally to the two parameters (sub_flow_ns and user_ns), adding basic meaning. The schema already documents sub_flow_ns with a description, but user_ns is left entirely unexplained in both schema and description. Since schema coverage is only 50% and the description does not compensate for user_ns, the score is average.
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 ('Send sub flow to subscriber') and the resource/recipient, plus a clarifying phrase that it 'Delivers a real message to a person.' However, it does not differentiate itself from sibling tools like cigchat_send_subflow_by_name or cigchat_send_subflow_by_user_id, which also send subflows to subscribers.
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 gives no explicit guidance on when to use this tool versus alternatives. It mentions a required scope but does not state any exclusions, alternatives, or contextual triggers. The phrase 'Delivers a real message to a person' implies a use case but does not address the many related send/send_subflow siblings.
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 the auth requirement ('Requires the Manage Flow scope') and the limit ('up to 20 labels'), which are useful behavioral constraints. However, it does not describe side effects, idempotency, error behavior, or what happens if limits are exceeded. The verb 'Add' conveys mutation, but details are lacking.
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 packs the core action, limit, endpoint, and auth requirement with no fluff. Every element serves a purpose, making it highly efficient 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?
The description covers the basic operation but omits crucial context: what `user_ns` means, how the subscriber is identified, the expected format of `data`, response behavior, and error handling. With no output schema and sparse parameter documentation, an agent would likely struggle to invoke this correctly without additional assumptions.
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 clarifies that `data` contains label names implicitly via 'by label name', but it does not explain the `user_ns` parameter at all, nor the structure of `data` beyond labels. The odd schema with `anyOf` and `not` is not addressed. Significant ambiguity remains for parameters.
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 ('Add labels by label name to subscriber'), the resource (labels), the target (subscriber), and a key constraint ('up to 20 labels'). It distinguishes this from sibling tools like remove_labels_by_name and add_tags_by_name by specifying label-by-name semantics.
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 guidance is provided beyond the required 'Manage Flow' scope. The description does not mention when to use this tool versus alternative label/tag operations, nor does it specify any exclusions or context for choosing this tool over siblings like add_tags_by_name or remove_labels_by_name.
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?
The description discloses the operation type (removal), the batch limit (20), the endpoint, and required auth scope. However, it does not mention idempotency, error handling, or the effect of removing non-existent tags. Since no annotations are provided, more behavioral detail would be beneficial.
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 concise sentence packed with essential information: action, limit, endpoint, and scope requirement. No filler words or redundant 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?
For a mutation tool with no annotations and no output schema, the description should provide more context. It lacks parameter explanations, usage alternatives, and expected return behavior, making it insufficient for an agent to confidently invoke without additional assumptions.
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 clarify parameters. It implies 'data' contains tags and 'user_ns' identifies the subscriber, but it does not explicitly explain either parameter. The nested tag_ns schema has a description, but top-level params remain 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 ('Remove tags from subscriber'), the resource (subscriber tags), and a key constraint (up to 20 tags). This distinguishes it from sibling tools like add_tags or remove_tag by specifying the operation and limit.
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 vs alternatives such as remove_tag or remove_tags_by_name. The only usage-related note is the required 'Manage Flow' scope, which is a prerequisite, not a selection guideline.
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. It discloses the required 'Manage Flow' scope, which is useful, but it does not mention side effects, reversibility, or what happens to the chat after unassignment.
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 efficient sentence that includes the operation, endpoint, and auth requirement. Every word contributes value with no filler.
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, no output schema, and zero parameter semantics, this description is incomplete. It covers purpose and auth but leaves the required parameter and expected response/effects undisclosed.
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 single required parameter 'user_ns' has no description in the schema and is not explained in the tool description. The agent cannot infer what value to supply or how to obtain it.
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 ('Unassign agent from chat') and clearly distinguishes this from the sibling tool 'cigchat_subscriber_assign_agent'. The HTTP endpoint is also stated, adding precision.
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 when to use the tool ('Unassign agent from chat') and includes the required scope, but it does not explicitly mention alternatives or when not to use it relative to other subscriber tools.
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. It discloses the required 'Manage Team' scope, which is useful, but it doesn't mention side effects, response format, or what happens on creation. 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?
A single sentence that front-loads the purpose and includes the endpoint and scope. No wasted words, perfectly concise.
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 5 parameters and no output schema, the description is minimal. It tells what it does and the scope, but not expected outcomes, defaults behavior, or edge cases. The schema partially compensates, but overall 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 description provides no parameter explanations. Schema coverage is 60%, but the required 'name' parameter lacks a description, and the description adds no 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 'create new agent group' with a specific verb and resource, and includes the endpoint. This distinguishes it from sibling tools like update/delete/list agent group.
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 on when to use this tool vs alternatives. It mentions the required 'Manage Team' scope but does not provide context for choosing create over update/delete.
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 full burden for behavioral disclosure. It does mention the required 'Manage Team' scope, which is valuable context, and the endpoint implies a POST write operation. However, it lacks details about return values, error conditions, or side effects of creating a ticket.
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 and front-loaded, stating the action, endpoint, and auth requirement in two short sentences. Every word adds value, with no redundant or filler 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?
For a tool with 25 parameters, no output schema, and no annotations, the description is insufficiently complete. It doesn't explain the relationship between listId and the other fields, what constitutes a valid ticket, or how the optional fields map to a ticket's structure. The agent would likely need to retrieve the schema and other documentation 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 description adds no parameter-level meaning beyond the schema. With 25 parameters and only 48% schema description coverage, many fields (e.g., title, text1-5, number1-2) remain undocumented both in the schema and the description, forcing the agent to guess their 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 clearly states the action ('create new ticket') and the resource ('/team/ticket-lists/{listId}/create'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like update and delete by focusing solely on creation.
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 or any prerequisites beyond the auth scope. It doesn't mention that a valid listId is needed or how to obtain it, nor does it exclude cases where other ticket operations might be more appropriate.
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 mentions the HTTP method and required scope, but does not disclose return format, pagination semantics, or whether the list is read-only. For a list operation, this is limited behavioral 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 and front-loaded: two sentences that state the action, endpoint, and a required auth scope. Every word earns its place with no redundancy or filler.
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?
For a simple list endpoint with three optional parameters, the description plus schema is minimally adequate. However, with no output schema and no mention of response structure or pagination details, it lacks some completeness. The presence of overlapping sibling tools also introduces ambiguity that this description does not resolve.
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 provides 100% coverage with descriptive names and types for all three optional parameters (name, page, limit). The description adds no additional parameter semantics beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with a specific verb and resource: 'List Whatsapp templates' followed by the exact endpoint. However, it does not differentiate from sibling tools like cigchat_list_templates or cigchat_facebook_utility_message_template_list, though 'Whatsapp templates' narrows the scope somewhat.
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 a concrete usage prerequisite by stating the required 'Manage Flow' scope, which is useful for selecting the tool. It does not, however, explain when to use this tool versus alternatives such as listing Facebook utility templates or syncing templates, leaving usage context only implied by the name.
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. It discloses the required 'Manage Team' scope and the POST endpoint, indicating mutation. However, it does not mention potential errors, duplicate handling, or any side effects beyond creation.
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, well-structured sentence that includes the endpoint and permission requirement. It is appropriately concise with 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 description provides the essential context for a simple create operation: endpoint and authentication scope. However, without annotations or an output schema, it omits details about expected responses or error conditions, making it only minimally complete for reliable invocation.
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 the 'name' parameter at all. The single required parameter is left entirely for the agent to infer from the schema and tool name, which the description fails to reinforce or clarify.
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 states 'Create new tag' with the specific endpoint, making the action and resource unambiguous. It clearly distinguishes from sibling tools like delete, update, list, and get product tag.
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 that it creates a product tag specifically (as opposed to other tag types) or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It does disclose the HTTP method (GET) and the required 'Manage Flow' scope, which is helpful. However, it does not clarify what 'status' means or the shape of the returned count, leaving some behavioral 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 a single sentence that is front-loaded with the action and includes the endpoint and auth requirement. Every part earns its place with no wasted 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?
For a simple zero-parameter count operation, the description gives the core function and auth requirement. However, the phrase 'bot users status' is ambiguous regarding whether it's a single total or a status-breakdown, and no output schema exists to clarify. This leaves meaningful gaps for 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 tool has zero parameters, and the input schema is empty, so schema coverage is effectively 100%. The baseline for zero-parameter tools is 4, and the description doesn't need to add parameter detail.
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 ('Get count') and the resource ('bot users status'), plus the endpoint. It is specific enough to identify the tool's function, though it does not explicitly distinguish it from related sibling tools such as cigchat_team_bot_users.
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 guidance is provided. The description doesn't explain when to use this count tool instead of listing bot users, nor any alternatives or exclusions. Only an authentication scope is mentioned, which is not usage 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?
The description discloses the required 'Manage Flow' scope, which is a useful behavioral requirement beyond the schema. However, with no annotations, it does not detail other behavioral aspects such as side effects, reversibility, or response behavior. It partially covers the transparency burden but leaves gaps.
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, information-dense sentence. It includes the action, endpoint, and authorization requirement without any padding or repetition. Excellent 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 no output schema, the description does not explain what happens after creation (e.g., success response, return value). It also does not clarify how 'current flow' is determined or if there are prerequisites beyond the scope. These gaps make it incomplete for an agent making the call.
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 examples for both 'name' and 'value'. The description adds no further meaning beyond the schema, so a baseline score of 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 action: 'Create a shortcut for the current flow' with a specific endpoint. The verb 'create' and resource 'shortcut' are explicit, and referencing 'current flow' distinguishes it from sibling tools like update_shortcut or delete_shortcut.
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 on when to use this tool versus alternatives. While it implies a flow context, it does not mention related tools like update_shortcut or list_shortcuts or any exclusions. The description only states what it does, not when to choose it.
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 disclosure burden. It does disclose the required 'Manage Flow' scope and implies a safe read operation via 'GET'. However, it does not mention pagination, response format, or other behavioral details, though the read-only intent is fairly explicit.
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 containing the action, resource, endpoint, and auth requirement. There is no redundant phrasing or filler, making it concise 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 5 parameters and no output schema, the description only states the purpose and auth scope. It does not clarify what the returned 'data' contains or how this tool differs from the closely named flow_custom_events_summary, leaving the agent under-informed 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?
The input schema already provides descriptions for all 5 parameters, giving 100% schema coverage, so the baseline is 3. The description adds no parameter-specific meaning, which is acceptable because the schema fully documents each field and the time-window constraint.
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 a GET operation for 'flow custom event data' and includes the exact endpoint. The word 'data' distinguishes it from sibling tools like flow_custom_events_summary, making the resource and action 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 similar siblings such as flow_custom_events_summary or list_custom_events. The only contextual note is the auth scope requirement, which is not enough to direct tool selection.
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 full burden for behavioral disclosure. It does mention the required OAuth scope, which is valuable, but does not disclose pagination behavior, filtering semantics, or the fact that the operation is read-only. The GET method is implicitly shown in the endpoint, but no explicit safety characteristics are stated.
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 two pieces of information: the action and the auth requirement. Every sentence earns its place, and it is front-loaded with the primary purpose.
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 lacks critical context about what 'by flow' means—how the flow is identified and whether it is implicitly tied to the token. It also omits any indication of the response format, which would be important for a list operation. While the schema documents parameters, the absence of flow-context guidance makes the description incomplete for an agent.
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%, so the parameters (name, page, limit) are fully described in the schema. The description adds no additional meaning to these parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get list') and resource ('custom events by flow'), and includes the exact API endpoint, making the tool's purpose unambiguous. It clearly distinguishes from sibling list tools by specifying the resource type.
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 cigchat_flow_custom_events_data or cigchat_flow_custom_events_summary. The only usage-related note is the required 'Manage Flow' scope, which is a prerequisite rather than a usage context.
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 does disclose the required authorization scope and the HTTP method (GET), which implies a read-only operation. However, it does not mention pagination, filtering, response format, or whether the operation is safe/non-destructive beyond the GET method. This is a moderate disclosure but 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 with no extraneous words. It front-loads the core action and endpoint, then adds the critical auth requirement. Both sentences earn their place, 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 list tool with no output schema, the description is fairly complete. It states the purpose, endpoint, and auth requirement. The schema covers the filtering and pagination parameters. However, it could provide more context about the return structure or how this tool fits among the many embedding-related siblings (e.g., 'use this to list embeddings; use get_info for a single embedding'). Still, it is adequate for basic usage.
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?
All four parameters (page, text, limit, heading) have descriptions in the schema (100% coverage), so the description adds no additional parameter meaning. The baseline of 3 applies because the schema sufficiently documents the parameters. The description does not explain how the parameters interact or the purpose of 'heading' vs 'text', but that is not required given 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 operation: 'Get list of OpenAI Embeddings' with the HTTP method and endpoint. This distinguishes it from sibling tools like create, delete, generate, and get_info by explicitly indicating it returns a list. However, it does not explicitly contrast with 'get_info', which could be ambiguous, but the word 'list' provides sufficient 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 a prerequisite (requires 'Manage Team' scope) but no guidance on when to use this tool versus alternatives like get_info or create. It does not mention that this is the go-to for listing all embeddings or that filtering parameters are available. No exclusions or alternative tools are referenced.
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 warns that this is a real side-effecting operation ('Delivers a real message to a person') and states the required scope, which is helpful. However, it does not mention irreversibility, failure behavior, or delivery guarantees, leaving some 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 short sentences that immediately state the primary action and a key caveat. There is no redundant or filler content, making it highly efficient 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?
The description covers the core purpose and auth requirement but leaves gaps such as the meaning of user_ns, the format of content (plain text vs HTML), and whether subject is optional. For a simple send tool with no output schema, this is minimally adequate but not fully complete.
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 provides only 'Example: email content' and 'Example: email subject' for two parameters, while the required user_ns has no description at all. The description adds no semantic meaning beyond the schema, failing to explain what user_ns represents 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 uses a specific verb and resource ('Send email content to subscriber') and clarifies that it 'Delivers a real message to a person.' This clearly distinguishes it from sibling tools like send_sms or send_text by specifying 'email' as the 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?
No guidance is provided on when to use this tool versus alternatives like cigchat_send_sms or cigchat_send_text. The only context given is the required 'Manage Flow' scope, which is an authorization detail, not a usage criterion or exclusion.
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 discloses the required 'Manage Flow' scope and HTTP method, but does not explain update semantics (e.g., partial vs full update, required fields, side effects, or return format).
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 includes the endpoint and auth scope. It is front-loaded and free of filler.
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 complexity of 13 parameters and no output schema or annotations, the description is too sparse. It does not explain which fields are updatable, how the items array works, or what response to expect, leaving significant ambiguity for an AI agent.
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 69%, and the parameter names and inline descriptions provide some meaning. The description itself adds no parameter-level detail, but does not need to repeat schema. This is a baseline score for moderate 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 'Update order' with the specific HTTP endpoint, unambiguously indicating a mutation of an existing order. This distinguishes it from sibling tools like create, get_info, and list.
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?
Usage is implied by the name and endpoint, but there is no explicit guidance on when to use this vs alternatives. The auth scope requirement is a prerequisite, not usage differentiation.
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 full burden of behavioral disclosure. It does mention the required 'Manage Flow' scope, which is useful auth context. However, it does not describe side effects, whether the assignment overwrites an existing group, or error behavior. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences: a clear action plus a scope requirement. Every word is purposeful, and it is front-loaded with the verb and resource. No unnecessary fluff.
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?
For a simple 2-parameter mutation with no output schema, the description provides the purpose, endpoint, and auth scope, but omits meaning of 'user_ns' and what the tool returns. Given the simplicity, it is acceptable but not comprehensive.
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 describes only one parameter (agent_group_id) with useful detail about accepting an id or name and auto-resolution. The other parameter (user_ns) has no description, and the tool description does not clarify it. With 50% schema coverage and no compensation from the description, parameter semantics are incomplete.
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 starts with a specific verb and resource: 'Assign agent group to chat'. This clearly distinguishes it from sibling tools like 'cigchat_subscriber_assign_agent' (which assigns a single agent) and 'cigchat_subscriber_unassign_agent'. The HTTP endpoint is also included for precision.
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 assigning a specific agent or unassigning an agent. The only directive is the scope requirement ('Requires the Manage Flow scope'), which is a prerequisite, not a usage guideline. There are no exclusions or contextual hints.
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 full burden. It discloses the HTTP method (DELETE), the required scope, and the 20-field limit, which are useful behavioral details. However, it does not mention whether fields are nullified or removed, reversibility, or what response to expect, leaving significant gaps for a destructive mutation.
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 efficient sentence that front-loads the primary action and includes essential details (endpoint, limit, scope). It is concise with no filler, though the information could be structured more clearly for readability.
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 destructive tool with no annotations and no output schema, the description does not provide adequate context. Missing details include parameter semantics, effects on subscriber data, and differentiation from sibling tools. The limit and scope are helpful, but the overall description is incomplete for reliable invocation.
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 mentions 'up to 20 user fields' and the endpoint 'by name', but does not explain that 'data' should be an array of objects with 'name' properties, nor what 'user_ns' represents. Only a hint at the limit is provided, which is insufficient for understanding the parameters.
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 ('Clear multiple subscriber user fields') and includes the endpoint and a limit of 20 fields. This distinguishes it from the singular variants like 'clear_user_field_by_name' and clearly indicates a multi-field operation.
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 use when clearing multiple subscriber user fields at once, but does not explicitly state when to use this tool versus alternatives like the singular clear_user_field_by_name. It also provides a prerequisite (Manage Flow scope), which is useful context, but no 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 carries the full burden. It discloses the required auth scope and the phone/email requirement, which are useful behavioral constraints. However, it does not describe potential outcomes (e.g., partial failures, duplicate handling, idempotency) or what the response contains, which is important for a bulk creation 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?
One sentence, front-loaded with the action, and includes only essential additional info (auth requirement and input constraint). No wasted words or repetition of schema details.
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 schema provides rich descriptions for the users parameter, and the description covers the core action and scope. However, for a complex bulk-creation tool with no annotations and no output schema, the description lacks details on behavior under edge cases, error handling, and return values. It is minimally viable but not fully complete.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by clarifying that 'phone or email is required' (at least one), which is clearer than the schema's confusing anyOf/required structure. This directly helps the agent construct valid requests.
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 action ('Create new subscribers') and the resource clearly. It includes a key constraint ('phone or email is required') and the endpoint. However, it does not explicitly distinguish from the sibling tool cigchat_subscriber_create, relying on the tool name's 'many' to imply bulk 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 a prerequisite (requires 'Manage Flow' scope) but no guidance on when to use this tool versus alternatives like cigchat_subscriber_create for single creation. There is no mention of alternatives or exclusions, only an implicit bulk capability from the name.
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 present, so the description carries the transparency burden. It does add the required 'Manage Flow' scope and the DELETE HTTP method, which is useful context. However, it does not disclose behavior when variant_id is omitted, idempotency, or error handling, so it is only moderately 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?
A single, front-loaded sentence communicates the action, resource, endpoint, and auth requirement without fluff. Every word 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 operation is simple, but the optional variant_id creates ambiguity about whether the tool removes a specific item or the entire cart. No return format is described, and the description does not clarify the consequences of calling it with only user_ns. Given the lack of annotations, this is a noticeable gap.
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 50%: user_ns has no description and variant_id only shows an example. The description's phrase 'Remove item' does not explain how the parameters map to the operation, leaving the required user_ns and optional variant_id semantically 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 ('Remove item') and the resource ('subscriber shopping cart'), with the HTTP endpoint making the operation explicit. It distinguishes itself from sibling tools like add_to_cart and empty_cart by naming the specific removal action.
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 add_to_cart, empty_cart, or cart. The description does not mention use cases, prerequisites beyond the scope line, or exclusions, leaving the agent to infer 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.
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 reveals the HTTP method (GET) and a required scope, which are useful. However, it does not describe the response format or any potential side effects, though for a simple read operation this is somewhat sufficient.
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 that front-loads the action and resource, includes the API endpoint in brackets, and appends the auth requirement. Every element earns its place without redundancy.
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 (no params, no output schema), but the description is vague about what 'workspace info' includes. Without an output schema, the agent is left guessing what data will be returned. It is minimally adequate but lacks explicit detail on the return value.
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 parameter semantics are not a concern. The baseline for 0 params is 4, and the description adds no unnecessary parameter details, which is appropriate.
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 resource ('workspace info') and the action ('Get'), making the tool's purpose obvious. It distinguishes from sibling tools by focusing on workspace-level information rather than team members or agent groups, though the exact scope of 'workspace info' is left vague.
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 only an authorization requirement (Manage Team scope) but gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions or specific scenarios, leaving usage context entirely implied.
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?
The description discloses the authentication requirement ('Requires the "Manage Team" scope'), which is a valuable behavioral trait. The verb 'Get' and endpoint method 'GET' imply a read-only operation. However, with no annotations provided, the description carries the burden but does not cover other behavioral aspects like pagination, response format, or data limitations.
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, front-loaded with the action, and includes the exact endpoint and auth requirement. Every piece of information earns its place with no redundancy or filler.
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 8 parameters, no output schema, and no annotations. The description only states the endpoint and scope, omitting information about the response structure, what the log data contains, or how it should be used. Given the complexity, this is insufficient for an agent to fully understand the tool's behavior.
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%, meaning all 8 parameters are already documented in the input schema. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function with a specific verb and resource: 'Get the ticket list change log data'. It also includes the exact endpoint path, which unambiguously identifies the operation and distinguishes it from sibling tools like team_ticket_lists and team_ticket_lists_items.
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 team_ticket_lists_items or team_ticket_lists. It mentions the required scope but does not explain use cases, prerequisites, or situations where this tool should be preferred. This is a clear gap.
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 convey behavioral traits. It only discloses the required scope and the HTTP endpoint, but does not state that it is a read-only operation, whether results are paginated, or what the response contains. This leaves important behavioral details undocumented.
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 of about 20 words, efficiently combining the resource, endpoint, and auth requirement. Every word serves a purpose, with no filler or redundancy.
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 8 optional parameters and no output schema. The description covers the resource and a key scope requirement but omits the response format, default behaviors, or how to combine parameters. This is a minimal viable description that leaves the agent without expectations for the call's return value.
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 baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides. It only restates the tool's purpose, which is already clear from the 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 retrieves 'flow agent activity log data', with a specific verb ('Get') and a specific resource. This distinguishes it from sibling data-retrieval tools like cigchat_flow_conversations_data and cigchat_flow_custom_events_data.
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 does not explicitly say when to use this tool versus alternatives, but the resource name makes the use case apparent. It mentions the required 'Manage Flow' scope as a prerequisite, which is useful context, but lacks explicit guidance on when to choose this over similar data-log tools.
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?
Even without annotations, the description adds useful context: the HTTP method (GET) and required scope. However, it does not disclose pagination behavior, potential response size, or any side effects (though 'list' implies read-only). The schema hints at pagination via page and limit params, giving moderate 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, with two short sentences covering the purpose, endpoint, and auth requirement. Every word earns its place, and the key information is front-loaded.
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?
For a simple list tool with no output schema, the description is mostly sufficient but lacks explicit guidance on how 'by flow' relates to the parameters and what the response looks like. It does not mention whether name is an exact match or substring search, leaving room for ambiguity.
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 parameter descriptions in the schema already explain name, page, and limit. The tool description adds no additional parameter semantics or examples, so it earns the baseline score of 3.
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 list'), the resource ('bot fields'), and the context ('by flow'), with the API endpoint for reference. It distinguishes from sibling tools like cigchat_flow_set_bot_fields or cigchat_flow_create_bot_field by indicating a read/list 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 a prerequisite (Manage Flow scope) but no explicit guidance on when to use this tool versus alternatives such as cigchat_flow_user_fields or other list tools. It does not mention when not to use it or when a sibling would be more appropriate.
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 transparency burden. It does disclose the HTTP endpoint and the required 'Manage Flow' scope, but it does not describe side effects, whether partial updates preserve existing settings, or error behavior, which 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 sentence that front-loads the action, includes the provider list, endpoint, and scope without any filler. It is concise, efficient, and every piece of information 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 description, combined with the well-covered schema, provides sufficient context for a straightforward update operation: it states the action, endpoint, required scope, and valid providers. However, it omits details about partial update behavior and return values, making it adequate but not rich.
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 descriptions and examples for every parameter. The description merely repeats the provider list that already exists in the schema, adding no extra semantic meaning beyond what is already structured, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 ('Ai Agent provider and model'), clearly stating what the tool does. It also enumerates the available provider values, which helps distinguish this tool from sibling tools like flow_update_ai_task_provider or settings_set_default_ai_provider.
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 when to use it (to update an AI agent's provider/model) and lists the valid providers, along with the required 'Manage Flow' scope. However, it does not explicitly state when not to use it, nor does it compare against alternative sibling tools.
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 does disclose an important requirement: 'Requires the "Manage Flow" scope on the token.' However, it does not describe update semantics (partial vs full replacement), return values, or side effects, leaving significant behavioral aspects 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 two sentences long, front-loads the core purpose, and includes only essential context (endpoint and scope). Every sentence 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's an update tool with 5 parameters, no annotations, and no output schema, the description is too brief. It omits crucial context such as whether all fields are optional, the effect of the update, and any expected response. The scope mention is helpful but insufficient for an agent to invoke the tool correctly without further inference.
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 only 20% (only 'id' has an example), and the description does not explain any parameters beyond saying 'update a closing note.' It fails to compensate for the low schema coverage; fields like 'require_summary' and 'require_attachment' remain ambiguous, and no clarification is provided in prose.
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 'Update a closing note in the current flow', which specifies the verb (update) and resource (closing note). This distinguishes it from sibling tools like create/delete/get closing notes. The inclusion of the endpoint and scope requirement adds clarity without ambiguity.
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 stating the action, but it doesn't explicitly contrast with alternatives like creating or deleting closing notes. It mentions the required 'Manage Flow' scope, which is a prerequisite, but provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools.
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?
Annotations are absent, so the description carries the full burden. It discloses the required 'Manage Team' scope and the GET endpoint, adding context about authentication. However, it does not mention response format, pagination behavior, or any side effects, leaving gaps for a complete behavioral picture.
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: the first states the purpose, the second notes the required scope. No unnecessary words or repetition, and the key information is front-loaded.
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?
For a simple list operation, the description covers the core purpose and auth requirement. However, there is no output schema and the description does not explain return structure or pagination defaults. The schema covers parameters, but the overall context is adequate yet not rich.
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 provides descriptions for all three parameters (page, limit, title), giving 100% coverage. The description does not add any additional meaning or clarify parameter interplay, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the list of installed mini apps' with the HTTP endpoint, providing a specific verb and resource. It distinguishes from sibling tools by focusing specifically on installed mini apps, unlike other list tools for tags, templates, products, etc.
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. The only additional information is the required 'Manage Team' scope, which is a prerequisite rather than usage context. With many sibling list tools available, there is no differentiation or exclusions 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?
The description discloses the required 'Manage Team' scope, which is a useful behavioral constraint. However, with no annotations, it fails to mention pagination behavior, search semantics, default limits, or response format, leaving the full burden on description.
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?
A single sentence that front-loads the purpose, includes the endpoint, and notes the auth requirement. No unnecessary information or repetition.
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?
For a simple list endpoint, the description covers the basic action and auth, but lacks usage guidance, pagination behavior, and any indication of the return structure. The schema fully documents parameters, but the absence of output schema and annotations leaves some gaps.
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 three optional parameters (name, page, limit) documented in the schema. The description itself adds no parameter-level details, 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 states 'Get list of product vendors' with the HTTP endpoint, making the action and resource specific. It distinguishes from sibling get_info tools by using 'list' rather than 'get info', which is inherently 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?
No guidance is provided on when to use this tool versus alternatives like cigchat_shop_product_vendors_get_info for individual vendor details. The description only mentions a required scope, not typical 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the required 'Manage Flow' scope and the endpoint, which are useful behavioral traits. However, it does not describe pagination, response format, or other runtime behaviors, leaving notable gaps.
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: one sentence for purpose plus a scope note. Every word is informative, and the critical scope requirement is included without fluff.
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?
For a simple list tool with no output schema, the description is adequately clear but lacks details about the response structure and usage context (e.g., what a subflow is, how pagination works). It is sufficient for basic invocation but not rich enough to fully guide an agent in edge 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?
The schema covers 100% of parameters with clear descriptions (name, page, limit). The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 list') and the resource ('sub flows'), with the endpoint [GET /flow/subflows] reinforcing the purpose. This distinguishes it from sibling list tools (e.g., list_tags, list_templates) by the specific resource type.
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 mentions the required 'Manage Flow' scope, which is a precondition, not a usage directive. No exclusions or alternative tool references are given.
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 exist, so the description carries the burden. It discloses that the tool sends a real message (real-world consequence) and requires the 'Manage Flow' scope (auth). However, it does not mention irreversibility, rate limits, or whether the recipient must be subscribed, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and endpoint, followed by a critical warning and permission note. Every sentence adds essential information without waste.
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 that sends a real message with a nested object schema, the description lacks critical context: what the template fields mean, prerequisites (e.g., approved template), potential errors, or return behavior. No output schema exists, and the description does not explain outcomes.
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%, but the description provides no explanation of the 'content' or 'user_ns' parameters, nor the nested fields like 'lang' and 'name'. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Send Facebook utility message template to subscriber' with the endpoint path included. It clearly identifies the resource (Facebook utility message template) and the target (subscriber), distinguishing it from broadcast tools that target tags or lists.
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 clear context: 'Delivers a real message to a person' and requires 'Manage Flow' scope. This implies single-recipient use and permission requirements, but does not explicitly mention alternatives or when not to use this tool compared to similar send tools.
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 must carry the full burden of behavioral disclosure. It does warn that this 'Delivers a real message to a person,' which is a crucial behavioral trait and heightens the stakes of using it. However, it does not mention reversibility, potential side effects, rate limits, or error behavior. The warning is valuable but 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, succinct, and front-loaded. The first sentence immediately conveys the action, the second adds the critical 'real message' warning and required scope. No filler or redundancy. Every sentence earns 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 a nested content object with multiple subfields, no output schema, and no annotations. The description does not explain how to assemble the content, what a 'utility message template' is, how params map to placeholders, or what response to expect. It only covers the high-level action and a prerequisite. Given the complexity of the schema, the description is incomplete for an agent to invoke this tool correctly without additional inference.
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 provides structure but zero descriptions on main properties (content, user_id). The description partially clarifies that user_id is a user identifier via the operation name and path, but it does not explain the content object's fields (lang, name, params, use_default_values) at all. Since schema_description_coverage is 0%, the description should compensate, but it adds no parameter meaning beyond what the name implies. This leaves the agent guessing about how to construct valid content.
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 a specific verb ('Send'), resource ('Facebook utility message template'), and recipient ('subscriber by user id'). It also adds the important operational note that it 'Delivers a real message to a person,' which distinguishes it from mere template management or inspection. The name and path include 'by_user_id', further differentiating it from sibling send/broadcast variants.
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 when to use it: when you need to send a real Facebook utility template to a specific user identified by user_id. It also states a prerequisite scope ('Manage Flow'). However, it does not explicitly contrast with alternatives such as cigchat_send_fb_utility_template (likely a different identifier) or broadcast variants, nor does it give examples of when not to use it. The guidance is clear but not explicit about exclusions or alternatives.
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?
The description adds useful behavioral context: the message is 'real' and the token needs the 'Manage Flow' scope. However, since no annotations are provided, the description carries the full transparency burden and does not mention other side effects (e.g., irreversibility, possible delivery channels, or rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 endpoint, and includes the auth requirement. No filler or redundant 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?
For a side-effecting send tool with no annotations and no output schema, the description is too brief. It leaves 'user_ns' ambiguous, says nothing about the delivery channel or how to obtain the subscriber identifier, and lacks any response behavior details, making it inadequate for an agent to invoke safely and 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 covers only 50% of parameters: 'content' has a minimal example and 'user_ns' has no description. The tool description does not explain 'user_ns' (likely a subscriber identifier) or clarify content format, so it 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 the verb 'Send' and the resource 'text content to subscriber', and includes the REST endpoint [POST /subscriber/send-text]. It distinguishes this tool from sibling send tools (send_sms, send_email, send_whatsapp_template) by specifying 'text content' and 'real message to a person'.
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 context that this tool delivers a real message and requires the 'Manage Flow' scope, but it does not explicitly state when to use this tool versus alternatives like send_sms or send_email. No when-not-to-use guidance or named alternatives 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?
With no annotations, the description must carry the full behavioral disclosure burden. It does reveal an authentication requirement ('Requires the 'Manage Team' scope on the token') and indicates a POST endpoint (mutating), but it does not explain whether the update overwrites existing configuration, what happens on success/failure, or any side effects. The term 'config' is vague—especially since the only parameter is api_key—leaving uncertainty about the actual 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 a single, concise sentence that front-loads the action and includes the endpoint and auth scope. Every piece of information is essential and there is no redundant or filler wording. It is efficiently structured for an agent to parse quickly.
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 (one parameter, no output schema), but the description leaves ambiguity about the exact effect of the update—particularly because it says 'config' yet only accepts an API key. It also does not mention return values, but the absence of an output schema lowers that burden. Given the simplicity, the description is adequate but not complete in clarifying behavioral outcomes.
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 for the single parameter (api_key: 'Api Key'), so the schema already provides full meaning. The description does not add any detail about the parameter beyond the schema, such as format, length, or how it relates to the config update. Baseline of 3 is appropriate since schema handles the heavy lifting.
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 ('Update the config') and the specific resource ('Ainvented integration'), with the HTTP endpoint. This distinguishes it from sibling tools like get_integration_ainvented and clear_integration_ainvented. The verb and resource are precise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Update' and names the integration, so an agent knows when to call it, but it does not explicitly state when not to use it or mention alternatives like get_integration_ainvented or clear_integration_ainvented. The scope requirement provides a prerequisite, but no exclusions or alternative guidance is present.
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 must disclose behavioral traits itself. It does disclose the required 'Manage Team' scope and the HTTP method (GET), implying read-only behavior, but it does not explicitly state there are no side effects or describe what data will be returned. This is partial transparency, better than nothing but insufficient for a tool with no annotation safety info.
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—a single sentence with an endpoint and a scope requirement, followed by no extra fluff. Every element earns its place, though it sacrifices some necessary detail for brevity.
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 (one parameter) but lacks an output schema, so the description should explain what 'info' includes. It also omits distinctions from similar tools, making it incomplete for an agent that must decide between get_info and get_info_by_code. While the endpoint and auth requirement are useful, the missing return-value and usage context leave gaps.
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 already describes the sole parameter 'codeId' as 'Discount Code Id', achieving 100% schema coverage. The description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('discount code info') and includes the exact endpoint path, making the tool's purpose immediately clear. The parameter name codeId and the sibling tool 'cigchat_shop_discount_codes_get_info_by_code' help distinguish this ID-based lookup from other discount code 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?
The description provides no guidance on when to use this tool versus alternatives like 'cigchat_shop_discount_codes_get_info_by_code' or 'cigchat_list_discount_codes'. It only mentions a required scope, which is a prerequisite, not a usage recommendation.
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. It discloses an authentication requirement (Manage Team scope), which is a behavioral constraint. However, it doesn't describe what the response contains, whether it's a read-only operation, or any other side effects. For a simple GET tool, this is minimal but adequate.
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: two short clauses, front-loaded with the purpose and endpoint, followed by the auth requirement. Every word earns its place with no unnecessary elaboration.
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 (one parameter, no output schema), and the description covers purpose, endpoint, and auth scope. However, since there is no output schema, the agent doesn't know what fields 'product info' includes, and the description doesn't clarify the difference from other product-related tools. This is minimally adequate for a low-complexity 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?
The input schema already documents the single parameter 'productId' with description 'Product Id', giving 100% coverage. The description adds no extra semantic detail about the parameter beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get product info' with a specific verb and resource, and the endpoint '/shop/products/{productId}/get-info' makes it obvious it retrieves a single product's details. The tool name includes 'products' and 'get_info', which distinguishes it from sibling tools like product_vendors_get_info or variants_get_info, though the description itself doesn't explicitly call out these distinctions.
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 mentions an explicit prerequisite ('Requires the Manage Team scope on the token'), which is useful contextual guidance for when the tool can be used. However, it provides no guidance on when to use this tool versus alternatives like list_products or product_variants_get_info, so the agent must infer the use case from the tool name and endpoint.
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?
The description discloses the 'Manage Team' scope requirement, which is a useful behavioral trait. However, it does not clarify whether the update is partial (PATCH-like) or full replacement (PUT), nor what the response contains. For a mutation tool with no annotations, more disclosure about side effects and response is needed.
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 that includes the endpoint and a critical auth requirement. There is no redundant information, and it is front-loaded with the primary 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?
Given the tool has 13 parameters, no annotations, and no output schema, the description is sparse. It covers the core purpose and auth, but omits behavioral context such as whether unspecified fields are preserved or reset, and does not describe the return format. This is a moderate-complexity mutation tool, so more context would be appropriate.
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 high (85%), so the baseline is 3 even with minimal parameter info in the description. The description adds only the endpoint path with productId and variantId, which reinforces required parameters but does not add semantics beyond the schema. The schema itself provides descriptions/examples for most fields.
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 'Update product variant info' with a specific verb and resource, and includes the exact HTTP method and endpoint. It is distinct from sibling tools like create/delete/get variants because the verb 'update' makes the action explicit.
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. It only mentions the required 'Manage Team' scope, but does not state that it is for modifying existing variants, nor does it reference any sibling tools or provide exclusions. An agent would have 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the auth requirement ('Manage Team' scope) and the HTTP method (PUT), which adds value beyond the schema. However, it does not state whether the update is reversible, what happens if the vendor does not exist, or what response is returned, leaving significant gaps 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 extremely concise: one purpose sentence, the endpoint, and the auth requirement. Every element earns its place, and the main purpose is front-loaded. No redundant or filler content.
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?
For a simple tool with only two parameters, the description covers the core purpose, endpoint, and auth requirement. However, with no annotations and no output schema, it is incomplete regarding post-update behavior (e.g., success confirmation, return value, error conditions). It is adequate but not fully self-sufficient.
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 50% (vendorId has a description, name does not). The description's 'Update vendor name' directly links the 'name' parameter to the vendor's name field, partially compensating for the schema gap. The endpoint path clarifies vendorId's role. However, it adds no format constraints or syntax details for the name parameter.
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 vendor name' uses a specific verb (update) and resource (vendor name), clearly indicating what the tool does. The endpoint [PUT /shop/product-vendors/{vendorId}/update] reinforces the purpose. However, it does not explicitly differentiate from sibling tools, though the verb update contrasts with the same resource's create/delete/get_info tools.
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?
Usage is implied by the phrase 'Update vendor name' — an agent can infer it should be used when a vendor's name needs changing. The description also provides a prerequisite (the 'Manage Team' scope), which is useful context. However, it does not explicitly state when to use this tool versus alternatives like create or delete vendor tools, nor mention 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?
With no annotations provided, the description must disclose behavioral traits. It adds the auth requirement ('Manage Flow' scope), which is useful. However, it does not mention whether the assignment overwrites an existing agent, idempotency, or what happens on success/failure.
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 that communicates the action and a key requirement without wasted words. It is appropriately concise.
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 lack of annotations, output schema, and a partially documented parameter set, the description is too minimal. It omits essential context about the user_ns parameter, return values, and side effects, leaving the agent with incomplete guidance for a mutation operation.
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 no parameter information. The schema covers agent_id (50% coverage) with a helpful description, but user_ns is undocumented in both schema and description. Since schema coverage is not high and the tool description offers no compensation, parameter semantics are 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 clearly states the action: 'Assign agent to chat' with the HTTP endpoint. It distinguishes the tool from siblings like 'cigchat_subscriber_unassign_agent' and 'cigchat_subscriber_assign_agent_group' by specifying it assigns an individual agent to a chat.
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 gives clear context (assigning an agent to a chat) and a prerequisite (requires 'Manage Flow' scope), but does not explicitly mention when to use this tool versus alternatives such as 'assign_agent_group' or 'unassign_agent'. No exclusions or alternative guidance are 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?
The description discloses a key behavioral prerequisite: the token requires the 'Manage Team' scope, which is valuable for an agent to know. However, it omits important behavioral details such as whether the 'members' array replaces the entire member list or merges with existing members, and what happens to members not included. No annotations exist to fill this 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, front-loaded sentence that includes the purpose, endpoint, and required scope. Every element serves a function, with no redundant fluff. The endpoint, while slightly redundant with the tool name, adds precision.
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 team-management tool with no annotations and no output schema, the description lacks sufficient context. It does not explain whether the member update is additive or a full replacement, nor does it disambiguate from closely related team tools. The agent would need to infer critical behavior not covered by the schema.
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 provides no explanation of the parameters. The schema covers 'id' with a description, and 'members' items have user_id/weighting with examples, but the meaning of 'weighting' and the overall semantics of the 'members' array remain unclear. With schema description coverage at 50%, the description does not compensate for the unstated parameter behaviors.
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 'update agent group members', a clear verb+resource that precisely states what the tool does. It distinguishes itself from the sibling tool 'cigchat_team_update_agent_group' by specifying 'members' rather than the group itself. The endpoint and scope requirement further clarify the operation.
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 modifying agent group membership but provides no explicit guidance on when to use it versus alternatives like 'cigchat_team_update_agent_group' or 'cigchat_team_create_agent_group'. There is no mention of exclusions or specific situations where this tool is preferred.
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 must convey behavioral traits. It discloses that this is a POST (mutating) operation and requires a specific OAuth scope. However, it does not mention any side effects, idempotency, or response behavior, which would be valuable for a create operation. The disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes the HTTP method/path and auth requirement. Every piece of information is relevant, with no filler or redundancy.
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?
For a simple create operation, the description gives enough for basic invocation but lacks any mention of the response format or return value (no output schema exists). It also doesn't clarify the notion of a 'closing note' or when to create one in the flow lifecycle. Given the low complexity, the description is adequate 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 contains parameter descriptions, but they are only examples (e.g., 'Example: 2') rather than true semantic explanations. The tool description itself adds no parameter information, so an agent cannot infer the meaning of 'require_summary' or 'require_attachment' beyond guessing. The description fails to compensate for the schema's weak 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 clearly states the action: 'Create a closing note for the current flow' and includes the HTTP endpoint. The verb 'create' distinguishes it from update/delete siblings, and the resource (closing note) and context (current flow) are specific.
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 mentions the prerequisite 'Manage Flow' scope and notes it's for the current flow, which gives some usage context. However, it does not explicitly say when to use this tool versus alternatives like update_closing_note or list_closing_notes, nor does it provide exclusions. Usage is implied but not fully guided.
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?
Despite lacking annotations, the description discloses the HTTP method (PUT), the required 'Manage Flow' scope, and the 20-field limit, providing useful behavioral context. It does not explain effects such as atomicity, partial failure, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose and endpoint, with no wasted words. However, it may be too sparse 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?
The tool lacks an output schema and has a confusing input schema (including an odd anyOf with 'not': {}), yet the description omits the array shape, return values, and error behavior. It also fails to distinguish itself from sibling batch/single-field tools.
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 does not explain the structure of the 'data' parameter, which is an array of objects with var_ns and value. The schema's 0% coverage means the description should compensate, but it remains vague ('multiple bot fields 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?
Description states 'update multiple bot fields value' with a batch limit of 20 and the HTTP endpoint, clearly distinguishing it from sibling tools like cigchat_flow_set_bot_field which handle a single field.
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?
Usage is implied by 'multiple' and the 20-field limit, but there is no explicit guidance on when to choose this over cigchat_flow_set_bot_field or cigchat_flow_set_bot_fields_by_name. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 adds value by specifying the required 'Manage Flow' scope and the PUT endpoint, which are useful. However, it does not disclose whether existing fields are overwritten, what happens on invalid field names, whether the operation is atomic/partial, or what the response contains. This is modest but incomplete transparency 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 one concise sentence that packs in the key facts: action, resource, batch size, endpoint, and auth scope. No wasted words; it is front-loaded and efficiently 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 moderate complexity and lack of an output schema, the description covers auth, endpoint, and batch characteristics. However, it omits details about the request body format (beyond the schema), behavior on errors, or what response to expect. While the schema provides some structure, the overall description leaves gaps for a complete understanding of the tool's 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?
Schema description coverage is 0%, and the description does not explain the 'data' parameter structure. It only hints at 'field name' and 'up to 20 bot fields', but lacks details on the array-of-objects format, required sub-fields (name, value), or any constraints on names/values. The schema shows the structure but with an unusual 'anyOf' and no descriptions, so the tool description must compensate and fails to do so.
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 a specific action: 'update multiple bot fields value by field name'. It identifies the resource (bot fields), the operation (update), the quantity (multiple, up to 20), and the key distinguishing trait (by field name). This differentiates it from siblings like 'flow_set_bot_field_by_name' (single) and 'flow_set_bot_fields' (likely by ID).
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 context via 'multiple' and 'up to 20', suggesting batch updates by name. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond the auth scope. The mention of the endpoint and auth scope gives some contextual clue, but no direct guidance on selecting between similar tools.
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 present, so the description must disclose safety and auth. It explicitly states the required OAuth scope ('Manage Flow') and the HTTP method (GET), implying a read operation. However, it does not describe error behavior or whether the shortcut belongs to a specific flow.
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?
A single sentence with the endpoint and auth requirement, no fluff. Front-loaded with the verb and resource.
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 (one integer parameter, no output schema), and the description gives the endpoint and auth scope. Yet it lacks details on what a shortcut is, how to find IDs, and what the response contains, so it's not fully complete but acceptable for a trivial getter.
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 coverage is 0%, and the description does not explain the 'id' parameter beyond the endpoint path showing 'shortcuts/{id}'. It leaves the meaning of the ID (shortcut ID) implicit, which is insufficient for an agent to know how to obtain it.
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 a shortcut') and the resource scope ('from the current flow'), with an endpoint confirming it fetches a single shortcut by ID. This distinguishes it from list_shortcuts and create/update/delete sibling tools.
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?
It mentions prerequisites (Manage Flow scope) and the 'current flow' context, but does not explicitly state when to prefer this over list_shortcuts or other shortcut-related tools. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the auth requirement and the GET method, indicating a read operation, but it does not describe the return format, pagination behavior, or default limits. This is a minimal but not comprehensive 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 sentence that immediately states the purpose and ends with the auth scope. There is no redundant information, making it highly concise 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?
The tool has no annotations, no output schema, and the description provides minimal context. It fails to explain what the response looks like, whether pagination is handled, or any defaults for page/limit. Given the complexity of multiple optional filters, the description is insufficient for an agent to confidently invoke the tool without additional assumptions.
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% for all five parameters, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides, and it does not mention filtering or pagination 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 'Get' with a clear resource 'list of products' and even includes the API endpoint '[GET /shop/products]'. It clearly distinguishes from sibling tools like list_tags or list_product_types by focusing on products, and from shop_products_get_info by being a list operation.
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 gives the prerequisite of the 'Manage Team' scope but does not explicitly state when to prefer this tool over alternatives such as shop_products_get_info or list_product_vendors. The use case is implied—listing products—without exclusions or alternative guidance, so it remains at an implied level.
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?
The description discloses the required 'Manage Team' scope and the HTTP method, but lacks details about pagination behavior, response format, or explicit affirmation of it being a read-only operation. With no annotations, the description carries the full burden but only partially fulfills 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 a single, front-loaded sentence beginning with the verb and resource, followed by the endpoint and auth requirement. Every element earns its place 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 straightforward list endpoint with all parameters documented in the schema, the description provides the essential purpose, endpoint, and auth. However, it could add a note about pagination via page/limit and that it returns product tags within the shop, leaving a small gap.
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 all three parameters with descriptions (name, page, limit), giving 100% coverage. The description adds no additional parameter semantics, meeting the baseline for high 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 'Get list of product tags' with the HTTP endpoint [GET /shop/product-tags], making the verb and resource explicit. This also distinguishes it from siblings like cigchat_get_product_tag (single tag) and cigchat_list_tags (general tags).
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 only states the action and auth requirement, with no exclusions or references to sibling tools.
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 usefully discloses the required 'Manage Flow' scope and the HTTP GET endpoint, clearly implying a read-only operation. However, it does not explain pagination behavior, return format, or any context around how 'flow' is determined, leaving some behavioral 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 a single, front-loaded sentence that immediately states the purpose and then adds the critical auth requirement. No filler or redundant information; every word earns its place.
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, optional-parameter list endpoint, the description is mostly complete: it identifies the resource, the read-only nature via GET, and the required scope. However, the phrase 'by flow' is vague given there is no flow parameter in the schema, and the description does not clarify how the flow is selected or scoped, which could confuse an agent.
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 provides full descriptions for all three parameters (name, page, limit), so the baseline is 3. The tool description adds no additional meaning beyond the schema; it does not explain how 'name' interacts with segment search or how pagination works in practice.
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 specific action ('Get list of segments') and resource ('/flow/segments'), and the tool name matches. It distinguishes itself from sibling tools like list_tags and list_templates by explicitly naming segments and the flow endpoint.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that segments are distinct from tags, templates, or other list operations, nor does it provide any exclusion criteria or context for when this tool is appropriate.
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. It discloses an authentication/authorization requirement (Manage Flow scope), which is valuable. However, it does not describe pagination behavior, response format, or side effects. The disclosed scope requirement is a meaningful behavioral detail, but other transparency aspects are lacking.
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 includes the action, resource, endpoint, and a prerequisite. Every element serves a purpose, and it is front-loaded with the key action. No unnecessary words or repetition of schema details.
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 (list operation, no output schema, 0 required params), the description covers the essential purpose and scope requirement. However, it lacks details about pagination (the schema includes page/limit), which would be helpful for a listing tool, and does not note whether results are sorted or limited by default.
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?
Schema coverage is 100%, so parameter names and types are fully documented. The description adds context by indicating the endpoint ('/flow/tags') and the token scope, which helps the agent understand the parameter purpose (e.g., 'name' likely filters results). The description complements the schema without needing to repeat parameter details.
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 ('Get list of tags') with a resource ('by flow') and includes the endpoint path, clearly identifying the tool's function. It partially distinguishes from siblings by specifying 'by flow,' though it doesn't explicitly name alternative tools for comparison.
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 a clear usage context (listing tags associated with a flow) and an explicit prerequisite (requires 'Manage Flow' scope). It does not mention when to avoid this tool or offer alternative tools, but the context is sufficient for an agent to determine when this tool is appropriate.
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 burden. It discloses the auth scope and endpoint, but does not explain what 'regenerate' actually does—such as whether it overwrites existing embeddings, what data it acts on, or any side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and endpoint. Every word is useful, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameters, the description must provide more behavioral context. It leaves unclear what triggers the regeneration, what the success criteria are, or what the response looks like. This is insufficient for a tool with side effects.
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 coverage is trivially 100%. The baseline for zero parameters is 4, and the description adds no parameter details because none 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?
Description clearly states the action 'Regenerate embeddings' and gives the HTTP endpoint, which distinguishes it from sibling tools like create, update, delete, or import. The verb and resource are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required 'Manage Team' scope, which is useful context for when the tool can be used, but it does not explicitly say when to prefer this over alternatives like create or update. The verb 'Regenerate' implies usage for refreshing embeddings, but 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 of behavioral disclosure. It adds important context by noting the message is 'real' and requires the 'Manage Flow' scope, but does not mention side effects, idempotency, or return 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?
Two sentences with no filler. The action is front-loaded, and the endpoint reference adds useful precision without bloat.
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?
For a single-parameter tool with no output schema, the description gives the essential action and a scope caveat. However, it omits what user_ns should contain and what happens after sending, leaving the context 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 provides zero description for the required user_ns parameter, and the description never references it directly. 'To subscriber' only implicitly suggests user_ns identifies the recipient, which is insufficient given 0% 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 verb and resource: 'Send main flow to subscriber' and further clarifies 'Delivers a real message to a person.' This distinguishes it from siblings like cigchat_send_subflow and cigchat_send_text, which handle different message types.
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 its use for delivering the main flow but offers no explicit comparison to alternatives like send_subflow or send_text. The scope requirement ('Requires the Manage Flow scope') is a prerequisite, not guidance on when to choose this tool over others.
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 explicitly warns 'Delivers a real message' and states the required 'Manage Flow' scope, which are critical practical implications. However, it omits potential side effects like whether it creates a contact or incurs cost.
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 compact and front-loaded with the primary action, followed by the source for parameters, endpoint, and scope requirement in two sentences. No wasted 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?
Given 4 params, nested objects, and no annotations/output schema, the description covers the key behavioral warning and auth requirement but leaves gaps in optional parameter semantics and explicit use-case boundaries. It does mention the template list source, which is valuable, but lacks enough guidance for a fully informed agent.
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 description directs readers to the template list endpoint for namespace, name, lang, and params, partially compensating for the schema's low 25% description coverage. It does not explain the contact or create_if_not_found parameters beyond the schema's minimal descriptions. The user_id role is implied by the endpoint.
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 sends a WhatsApp template to a subscriber and that it delivers a real message. It does not explicitly differentiate from the sibling send_whatsapp_template, but the tool name and endpoint URL clarify the by_user_id 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?
It tells the agent where to find template values (/api/whatapp-template/list) and states the required scope, but it does not provide explicit guidance on when to use this vs alternatives like broadcast_whatsapp_template_by_user_id or send_whatsapp_template. The phrase 'to a person' implies singular use but leaves exclusions 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 must carry disclosure weight. It discloses the auth requirement ('Manage Team' scope) and the endpoint, which adds useful context. However, it does not state whether this overwrites the entire config, what happens to existing settings, or that the only configurable field is api_key. For a mutation tool, more behavioral detail would be valuable.
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, about 20 words, front-loaded with the action. The auth scope is included without fluff. Every sentence earns its place, making it appropriately concise.
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 tool with one parameter and no output schema, the description covers the essential context: the action, endpoint, and required scope. It does not mention related get/clear tools, but that omission does not cripple usability. It is sufficiently complete for this low-complexity operation.
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 api_key described as 'Api Key'. The description's mention of 'config' is vague and does not add meaning beyond the schema. It neither clarifies the api_key format nor explicitly links it to the config update, leaving the parameter semantics to 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 clearly states 'Update the config of CaludeAi integration' with the specific endpoint [POST /integration/calude], which specifies the verb and resource. It distinguishes from siblings like get_integration_* and clear_integration_* via 'set', though it does not explicitly mention those alternatives. The misspelling 'CaludeAi' could cause minor confusion but matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need to update the CaludeAi integration config. It does not explicitly state when not to use it or mention alternatives such as get_integration_calude for reading or clear_integration_calude for removing. The 'Requires Manage Team scope' gives a prerequisite but not situational 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 carries the burden. It discloses the required scope and the GET method, which implies read-only behavior. However, it does not describe pagination behavior, response format, or potential errors, leaving gaps in the safety/behavioral profile.
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, concise and front-loaded with the core purpose. The endpoint and scope information earn their place, though the bracketed endpoint is somewhat redundant with the tool name.
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 a simple list operation with documented parameters, but there is no output schema and the description does not explain the return value, default page size, or any filtering behavior. The description is adequate but not fully complete for an agent planning to use it.
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 parameters already described. The description adds no extra semantic meaning beyond the endpoint context, so it meets the baseline without exceeding it.
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 ('Get list') and resource ('product variants'), clearly distinguishing it from sibling tools like create/update/delete/get_info. The endpoint reference reinforces the intent.
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 states a prerequisite (Manage Team scope) and the HTTP method, providing some context. However, it does not explicitly mention when to use this tool versus the 'get_info' variant for a single variant, so the guidance is only implied.
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 full burden. It discloses the required 'Manage Team' scope, which is useful authorization context, but it does not describe side effects, success/failure behavior, or any constraints on the operation. The disclosure is minimal but includes a specific behavioral trait.
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 immediately identifies the action and includes the endpoint and a key requirement. There is no wasted content, and it is 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?
For a tool with one simple parameter and no output schema, the description provides the essential action and a permission requirement. However, it omits information about expected return values or success conditions, making it minimally complete but with 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?
The schema has a single 'name' parameter with no description (0% schema coverage). The tool description does not explain the parameter's meaning, format, or constraints beyond the obvious implication that it's the vendor's name. It 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create new vendor') and includes the API endpoint. The resource (product vendor) is evident from the tool name and endpoint, and the verb distinguishes it from sibling tools like update, delete, and get_info.
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 a new vendor and states a prerequisite (Manage Team scope). However, it does not explicitly differentiate from alternatives or state when not to use it. Usage context is reasonably clear but relies on inference.
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?
The description discloses the required 'Manage Team' scope and shows the HTTP method as GET, implying a read-only operation. However, there are no annotations, and the description does not elaborate on return format, error behavior, or other side effects, leaving some burden unmet.
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, front-loaded with the core purpose ('Get vendor info'), followed by the endpoint and auth requirement. No unnecessary words or repetition.
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 read operation, the description provides the essential purpose, endpoint, and authentication need. It lacks explicit alternative guidance but is otherwise sufficient given the low complexity and complete schema.
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 fully documents vendorId as 'Vendor Id', and the description adds no new semantic detail beyond what the endpoint and schema provide. Since schema coverage is 100%, the baseline score 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 states 'Get vendor info' with the specific GET endpoint, indicating retrieval of a single vendor's details. This distinguishes it from siblings like cigchat_list_product_vendors, which lists vendors, and create/update/delete variants.
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 provided on when to use this tool versus alternatives such as listing vendors or creating/updating vendors. The endpoint implies a single-vendor lookup, but there is no direct comparison or prerequisite context.
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 full burden. It does disclose an authentication requirement (Manage Flow scope), which is useful behavioral context. However, it does not explicitly confirm the operation is read-only, nor does it describe response behavior or edge cases, though 'Get' implies a read operation.
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 front-loads the core purpose ('Get subscriber shopping cart detail') and then adds the necessary auth scope. It is concise, with no filler or irrelevant information.
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 simplicity of the tool (one parameter, no nested objects, no output schema), the description is mostly adequate. It states the purpose and auth requirement. However, it does not describe the return format or any limitations, which an agent might need to know, but for a simple GET this is a minor gap.
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 parameter 'user_ns' with a clear description ('Subscriber user_ns'), and schema coverage is 100%. The description adds no further meaning about the parameter, so it does not improve on the schema but also does not need to.
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 ('subscriber shopping cart detail'), with the endpoint for reference. This distinguishes it from sibling tools that add, remove, or empty the cart, and from other subscriber-related actions.
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 related sibling tools (e.g., subscriber_add_to_cart, subscriber_remove_from_cart) or any conditions for choosing this tool, leaving the agent to infer usage purely from the name.
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 full weight. It discloses the scope requirement and the need for phone/email, but does not describe side effects, idempotency, return format, or behavior on duplicate subscribers, which is a notable 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 two short sentences with no filler. The key information (action, prerequisite, requirement) is front-loaded and immediately digestible.
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 7 parameters, no output schema, and 29% schema coverage, the description omits return value expectations, doesn't resolve the required-fields contradiction, and fails to distinguish from create_many. This leaves the agent with an incomplete picture, especially regarding the phone/email requirement.
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 only 29%, so the description must compensate. It adds the crucial 'phone or email is required' condition, but this contradicts the schema's required array listing both fields as mandatory. It does not elaborate on other parameters, though they are mostly self-explanatory.
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 (new subscriber), with the endpoint provided. It distinguishes itself from update/delete siblings through its verb, though it doesn't explicitly reference alternatives like create_many.
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 mentions the required 'Manage Flow' scope, which is valuable usage guidance. However, it doesn't provide context on when to use this tool over creating multiple subscribers (create_many) or when updates are more appropriate, leaving those decisions to the agent.
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 exist, so the description carries the burden of behavioral disclosure. It discloses the HTTP method, a 20-label maximum, and the required 'Manage Flow' scope, which are useful operational details. However, it does not specify return values, error handling, idempotency, or behavior when labels are not found, leaving gaps for such a mutation.
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 that efficiently conveys the action, limit, endpoint, and required scope. No filler or redundancy; every clause adds relevant 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?
Given there are only two parameters and no annotations or output schema, the description covers the core operation but falls short on parameter semantics (especially user_ns) and side effects. The endpoint and scope are useful, but the missing explanation of the subscriber identifier makes it incomplete for autonomous 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 no descriptions, and the description only partially compensates by indicating 'by label name' and the 20-label limit, which maps to the data array. The user_ns parameter is not explained anywhere, leaving its purpose (subscriber identifier) implicit. The array-of-objects structure inside data is also not clarified, so the agent may not know the expected input shape.
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 ('Remove labels from subscriber'), the method ('by label name'), and a constraint ('up to 20 labels'). The inclusion of the DELETE endpoint and scope further clarifies intent. This distinguishes it from related tools like add_labels_by_name and remove_tags_by_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 implies usage for removing labels from a subscriber based on label names, but provides no explicit guidance on when to choose this over alternative tools (e.g., remove_tags_by_name or removing labels by other means). It does state a prerequisite (Manage Flow scope) and a limit, but no exclusions or alternative suggestions. Context from sibling names is not leveraged to clarify the 'labels vs tags' distinction.
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 POST method and required scope, but it does not explain effects on omitted parameters (whether they retain previous values or get hidden), nor does it describe the response. The behavior is implied by 'Show/Hide' and the schema, but significant ambiguity remains.
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 that includes the action, endpoint, and a key requirement. No wasted words; every element earns 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?
Despite having a rich schema, the description lacks critical operational details for a mutation tool with 18 optional parameters. It does not clarify whether omitting a parameter preserves the current setting or resets it, nor is there any explanation of the overall effect or response. This is a significant gap for safe 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 each parameter clearly documenting '1 to show, 0 to hide'. The description itself adds no additional parameter semantics beyond what the schema provides, matching the baseline for high 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 action (Show/Hide workspace Channels) and identifies the specific resource via the HTTP endpoint. It is distinct from siblings like cigchat_workspace_settings_channels, which appears to be a read-only counterpart.
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 a clear prerequisite (requires 'Manage Team' scope) and an HTTP method, giving some usage context. However, it does not explicitly compare with alternative tools (e.g., cigchat_workspace_settings_channels for reading current settings) or state when this update tool should be preferred.
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 present, so the description carries the burden; it adds the required 'Manage Flow' scope and endpoint. However, it does not disclose return shape, pagination semantics, or whether listing has side effects, leaving some burden unmet.
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 focused sentences: front-loads verb and resource, then adds endpoint and auth. No filler or redundant wording.
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?
For a simple list with 3 optional params and no output schema, the description includes endpoint and auth but omits response format and pagination/filtering behavior. It is adequate but leaves gaps that matter when invoking the 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 covers all three parameters with descriptions (100%), so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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?
Clearly states the action ('List'), the resource ('Facebook utility message templates'), and includes the endpoint. This distinguishes it from sibling tools like create/delete/send/broadcast/sync variants for the same resource.
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?
Provides endpoint and auth requirement, but no explicit guidance on when to use this vs alternatives like list_templates or whatsapp_template_list. Usage must be inferred from the verb/resource, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the required 'Manage Flow' scope and the POST method, indicating an authenticated operation. However, it does not mention return format, error behavior, or whether the operation has side effects beyond being a 'View'.
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 concise, front-loaded with the core action, and includes essential context (endpoint and scope) without extraneous words. Every element 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 simple with one parameter and no output schema, but the description does not specify what 'details' are returned or any error/edge-case behavior. Given the lack of output schema, this leaves a gap in the expected response context.
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 single parameter is well-documented in the schema (accepts namespace id or exact name). The description adds no new parameter details, 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 states the action ('View Ai Task details') and identifies the resource (Ai Task), distinguishing it from sibling tools like flow_ai_tasks which likely list tasks. The HTTP endpoint and scope requirement further clarify the specific operation.
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 viewing task details via the word 'View' and provides the endpoint, but it does not explicitly state when to prefer this tool over alternatives such as flow_ai_tasks. No when-not-to-use guidance or alternative references are given.
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 the HTTP method, the closed-conversation filter, and the required 'Manage Flow' scope. It does not mention response format, pagination behavior, or potential side effects, though the read-only nature of GET is implied.
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 front-loads the verb and resource, then adds the endpoint and scope requirement. Every element earns its place with no redundancy or fluff.
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 lack of output schema and annotations, the description provides the essential purpose and auth requirement but omits details about the response structure and pagination semantics. The schema hints at pagination via limit/start_id, but a complete entry would clarify what 'conversation data' includes and how results are returned.
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 already describes all 5 parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it only clarifies the overall closed-conversation filter.
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 gets flow conversation data and specifically filters to closed conversations. The endpoint [GET /flow/conversations/data] reinforces the resource, and the closed-conversation qualifier differentiates it from other flow-related data tools.
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 need closed flow conversations) and provides a required scope prerequisite. However, it does not explicitly mention alternatives or when not to use this tool, leaving comparison to sibling tools to the agent.
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 does add useful context: the required 'Manage Flow' scope and the HTTP method POST. However, it does not disclose whether creation is idempotent, what happens if a field with the same name exists, error conditions, or the response format. This is a partial disclosure but lacks depth expected 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 sentence that front-loads the core action ('create new user field'), then adds the endpoint and scope requirement. There is zero fluff or redundant information. Every part 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 has 5 parameters, no output schema, and no annotations. The description explains the operation and auth requirement but does not cover what the API returns on success or failure, how conflicts are handled, or how a user field affects subscribers. For a moderate-complexity create operation, this is adequate but leaves notable gaps.
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 80%, with rich descriptions for `name`, `value`, `var_ns`, and `var_type` (including examples and allowed values). The only param without a description is `description` (no text provided). The tool description itself adds no parameter information, but the schema already provides strong semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'create new user field', which clearly states the action (create) and the resource (user field). It also includes the endpoint and required scope, making the tool's purpose unambiguous. Among sibling tools like `cigchat_flow_update_user_field` and `cigchat_flow_delete_user_field`, the verb 'create' clearly differentiates it.
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 through the verb 'create' and the resource, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites beyond the scope requirement. There is no explicit reference to related tools like `cigchat_flow_update_user_field` or `cigchat_subscriber_set_user_field`, so the guidance is mostly 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does mention the required scope ('Manage Flow'), which is useful, but it does not disclose pagination behavior, return format, or that this is a read-only operation. While the endpoint suggests GET, the description itself does not explicitly guarantee 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 sentence that includes the action, resource, endpoint, and a key auth requirement. Every piece of information is relevant and there is zero unnecessary text.
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?
For a simple list tool with no output schema, the description provides the essential action and auth requirement. However, it leaves gaps: it does not clarify what 'inbound webhooks' look like in the response, how the 'name' search interacts with 'flow', or pagination defaults. Given the lack of output schema and the 'by flow' wording, the description could be more 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?
The input schema has 100% coverage with descriptions for all three parameters (name, page, limit), so the baseline is 3. The description does not add any additional meaning beyond the schema and actually introduces ambiguity by saying 'by flow' without a corresponding flow parameter in 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's function: 'Get list of inbound webhooks by flow' with a specific resource (inbound webhooks) and verb (get list). It is distinct from sibling tools such as cigchat_flow_summary or cigchat_flow_agents, and the endpoint is provided for precision.
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 when to use this tool (to list inbound webhooks for a flow) and includes a prerequisite (requires 'Manage Flow' scope). However, it does not explicitly state when not to use it or provide alternatives, which is particularly notable given the large number of flow-related sibling tools.
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 does disclose a permission requirement ('Requires the Manage Team scope'), which is useful. However, it does not describe read-only nature, response format, pagination behavior, or any side effects, leaving a gap for an agent relying solely on this text.
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 that front-loads the action and resource, then adds the endpoint and a necessary permission note. There is no filler or redundancy.
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 tool with three well-documented parameters, but the description is minimal. It does not state whether it returns all types when no filter is applied, what the response structure resembles, or how it differs from a 'get single' tool. Given the absence of an output schema and annotations, more context would be helpful, though the core purpose is clear.
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 fully documents name, page, and limit. The description adds no additional meaning about how to use these parameters, so it neither enhances nor detracts from 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 states the specific action ('Get list of product types') with a clear resource, and includes the API endpoint ('[GET /shop/product-types]'). This clearly differentiates it from sibling tools like list_tags or list_templates, and from related CRUD tools like shop_product_types_get_info.
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 when to use the tool (when you need a list of product types) and notes a prerequisite (Manage Team scope). However, it does not explicitly compare to alternatives such as shop_product_types_get_info for retrieving a single type, nor does it provide exclusions or richer context.
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 available, the description carries the full burden of behavioral disclosure. It explicitly warns that this 'Delivers a real message to a person', which is a critical side-effect for an agent to know, and states the required 'Manage Flow' scope, providing auth context. It does not detail failure modes or return values, but the key behavioral traits are disclosed effectively.
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 concise and front-loaded with the purpose. It packs useful information (parameter source, real-message warning, required scope) into three short sentences without fluff. Every sentence earns its place, and the structure is efficient for an agent 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?
Given the moderate complexity (nested object, no output schema, low schema coverage), the description provides essential context: where to get template details, that it sends a real message, and the required scope. However, it leaves gaps such as the meaning of user_ns, expected behavior on failure, and what the response contains. It is adequate but not fully complete for an agent to execute without some guesswork.
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 description coverage is 0% for the top-level parameters, and the description partially compensates by directing the user to find 'namespace, name, lang, params' from an external API list. This adds meaning about where to source parameter values, but it does not explain the semantics of 'user_ns' or how the 'content' object maps to a template. The nested structure is not elaborated, so the agent still needs to infer some meanings 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 clearly states the action ('Send Whatsapp Template to subscriber') with a specific verb and resource, making the purpose obvious. However, it does not explicitly differentiate from the sibling tool 'cigchat_send_whatsapp_template_by_user_id', which likely targets a subscriber via a different identifier. The inclusion of the endpoint path adds specificity but not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to send a WhatsApp template to a subscriber) and provides some context on how to find template parameters (from an external list endpoint). It also warns that this delivers a real message and requires the 'Manage Flow' scope, which helps the agent understand prerequisites. However, it lacks explicit guidance on when not to use this tool versus alternatives like broadcast or by_user_id variants, and does not state 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?
With no annotations, the description carries the transparency burden. It discloses the HTTP method and required OAuth scope, but does not explain side effects (e.g., overwriting existing config), reversibility, or response shape. This is basic but incomplete 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, front-loaded sentence containing the action, resource, endpoint, and a critical auth requirement. Every element earns its place with no waste.
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?
For a straightforward update operation with fully documented schema parameters, the description is mostly sufficient. However, with no output schema or annotations, missing details about effect on existing config and return values prevent a higher score.
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 parameter-specific semantics, earning the baseline score of 3.
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 ('Update') and resource ('S3 Storage integration'), clearly distinguishing it from sibling tools like get_integration_s3storage and clear_integration_s3storage. Including the HTTP endpoint adds further specificity.
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 clearly implies its use for updating S3 Storage integration settings and notes the required 'Manage Team' scope, but it does not explicitly state when to use it over alternatives or mention any exclusions or prerequisite steps beyond the token scope.
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?
Without annotations, the description discloses the required 'Manage Team' scope and the HTTP endpoint, which adds meaningful context. However, it does not describe side effects, overwrite semantics, or confirmation behavior beyond the config update.
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 concise sentence that front-loads the action and includes the endpoint and auth requirement. No wasted 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 tool is simple with three self-descriptive parameters, and the description includes endpoint and scope. However, it lacks any mention of return value or success verification, which are not covered by an output schema.
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 already provides descriptions for all three parameters (url, token, api_key) with an example, so the description adds no additional parameter semantics. Baseline of 3 applies due to 100% 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?
Clearly states 'Update the config of WooCommerce integration' with a specific verb and resource. The endpoint and sibling tools (get/clear) differentiate it from related operations.
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?
Does not explicitly state when to use this tool versus alternatives like get or clear integration, but the 'Update' verb implies its purpose for modifying existing config. No exclusions or alternative conditions are 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 reveals the required scope ('Manage Team'), which is useful, but it does not describe what information is returned, error conditions, or whether the operation is read-only (though 'get' implies it). The auth requirement adds some transparency, but other behavioral aspects are left unspecified.
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, containing only two sentences: one stating the action and endpoint, and one about the required scope. Every word earns its place, and the key information is front-loaded. No redundancy or filler.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description is adequate but not complete. It lacks any mention of the return value or response structure, which would be helpful for an agent to know what to expect. However, the tool's purpose is clear and the parameter is fully documented by the schema.
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 parameter 'code' has a description ('Discount Code'). The tool description adds no additional semantics about the parameter format, case sensitivity, or examples. With the schema already fully covering the parameter, 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 states the action ('Get discount code info') and the resource ('by code'), with the HTTP endpoint included. It distinguishes itself from siblings like 'cigchat_list_discount_codes' and 'cigchat_shop_discount_codes_get_info' by specifying the lookup key, making the tool's 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 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 specific discount code to look up, but it does not explicitly state when to use this tool versus alternatives like listing all codes or getting info by another identifier. There are no explicit exclusions or context cues, so usage guidance is only implied.
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. It discloses the required 'Manage Team' scope and the HTTP method, which is useful transparency. However, it does not mention idempotency, partial vs full update semantics, or response format, leaving significant gaps 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?
Two concise sentences: one for purpose and endpoint, one for auth requirement. Every word earns its place, no redundancy or filler.
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?
With 14 parameters and no output schema or annotations, the description provides only auth context. It is minimally viable because the schema covers parameter names and examples, but it lacks critical behavior details like whether unspecified fields are retained or reset, and what the return value looks like.
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 description does not discuss parameters, but schema coverage is high (93%) with example values for most fields. The examples hint at allowed values (e.g., type: percentage, amount, free_shipping), but the description adds no additional 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?
Description clearly states 'Update discount code' with the PUT endpoint, distinguishing it from create/delete/get siblings. It identifies the specific resource and action with no ambiguity.
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 (use when you need to update an existing discount code) but does not explicitly state when not to use or list alternatives like create/delete. The auth requirement provides some context but no exclusions or alternative tool references.
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. It discloses the required 'Manage Team' scope and the HTTP endpoint, which is useful. But it omits side effects, return value, and error behavior, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the action and includes the endpoint and scope. No unnecessary words or repetition.
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 5 parameters, no output schema, and no parameter descriptions, the description is too sparse. It doesn't explain what constitutes a valid address/coordinates, the role of 'note', or what the response will contain. It also lacks context on how this fits with sibling location tools.
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 provides no parameter guidance. The parameter names are self-explanatory, but the agent gets no information about value formats, constraints, or the purpose of 'note'.
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 new location' with the specific endpoint, making the verb+resource unambiguous. It distinguishes from sibling location tools like update/delete/get_info/list.
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 for when to use this tool (creating a new location), and the sibling list includes alternative location operations. However, it doesn't explicitly mention when not to use it or name alternatives.
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 full burden. It discloses the required scope, which is useful context, and the 'Get' verb implies a read-only operation. However, it does not describe response format, error behavior, or any other 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 one sentence that packs the action, endpoint, and auth requirement with zero waste. It is appropriately front-loaded, and the typo does not affect overall structure.
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?
For a simple one-parameter get tool, the description covers the essential call path and permission requirement. However, it does not state what 'location info' includes, and with no output schema, the agent lacks full context about expected return data.
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 fully documents the single parameter (locationId) with a description, so the baseline is 3. The description adds no extra parameter meaning beyond referencing the locationId in the endpoint path.
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 lcoation info') and the resource (shop location), with the HTTP endpoint disambiguating it from list-style siblings like cigchat_list_shop_locations. The typo 'lcoation' is minor and does not obscure the intended meaning.
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 gives an explicit auth prerequisite (Manage Team scope) but provides no explicit when-to-use guidance or exclusions. The purpose is clear enough to infer usage, but it does not mention alternatives or contrast with listing operations.
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 adds the required scope and the HTTP endpoint, which are useful behavioral constraints. However, it does not disclose side effects, response format, or any ordering rules, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, resource, endpoint, and requirement with no filler. Every word earns 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?
For a tool with 13 parameters, no output schema, and no annotations, this description is severely under-specified. It fails to explain required inputs, the nature of the created order, or expected outcomes, making it difficult for an agent to 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?
The schema covers only 62% of top-level parameters, leaving user_ns (required), note, items, tracking_no, and reference_no undescribed. The description adds no parameter guidance, so an agent cannot infer the meaning of these essential fields, especially the ambiguous user_ns.
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 ('Create') and the resource ('new order for bot user'), distinguishing it from sibling tools like cigchat_shop_orders_get_info and cigchat_shop_orders_update. Including the endpoint and required scope adds further specificity.
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 establishes a clear context: creating an order for a bot user, and explicitly mentions the required 'Manage Flow' scope. However, it does not contrast with update/get alternatives or state when not to use the tool, so it lacks full exclusion 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 provided, the description carries the full burden. It adds the auth requirement ('Manage Team' scope) and the HTTP method (GET), which hints at read-only behavior. However, it does not disclose what data is returned, error handling, or potential side effects (even if none), leaving some behavioral 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 a single, compact sentence that front-loads the purpose, includes the endpoint, and adds a critical auth requirement. Every word contributes meaning, with no redundancy or filler.
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 (one parameter, no output schema), but the description still leaves gaps: it does not describe the return payload structure, possible error scenarios, or how this tool fits with order-related siblings like 'cigchat_list_orders' or 'cigchat_shop_orders_update'. Given the absence of an output schema, more detail on expected output would improve completeness.
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 fully documents 'orderId' with a brief description ('Order Id'), and the endpoint path reinforces its role. The description adds no extra semantic value beyond confirming that orderId is the path parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 ('order info'), making the tool's purpose immediately clear. It also includes the exact endpoint path, which distinguishes it from sibling tools that fetch info for other entities (e.g., products, discount codes, locations).
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 required 'orderId' parameter implies this tool should be used when a specific order ID is known. However, the description does not explicitly state when to use this versus the sibling 'cigchat_list_orders' tool or any other alternatives, nor does it provide exclusions or context for selection.
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 full burden. It does disclose the required 'Manage Team' scope, adding valuable auth context. However, it does not mention return format, error behavior, or confirm that this is a read-only operation, leaving some ambiguity for a GET endpoint.
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, compact sentence that includes the endpoint and auth requirement. Every word earns its place with no redundancy or fluff.
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?
For a simple 2-parameter GET tool with no output schema, the description provides the essential endpoint and scope. However, it does not clarify what 'variant info' includes (e.g., price, SKU), which could lead to uncertainty about the return value. It is adequate but not comprehensive.
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 basic descriptions ('Product Id', 'Variant Id'), so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides, but the parameters are straightforward and self-explanatory.
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 'Get' with a clear resource ('product variant info') and includes the full endpoint template. It differentiates from sibling tools like cigchat_shop_products_variants (which likely lists variants) by targeting a single variant via its ID.
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 retrieving a specific variant's details, but it does not explicitly state when to use this over alternatives, nor does it mention any exclusions. It does provide a prerequisite (Manage Team scope), which is helpful guidance but not comparative.
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 usefully reveals the auth requirement ('Manage Team' scope) and implies a persistent mutation, but it does not mention side effects, duplicate handling, or return 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 a single concise sentence that front-loads the action, includes the endpoint, and states the auth requirement. No unnecessary content.
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 simple single-parameter schema, no output schema, and no annotations, the essential information (action, endpoint, auth) is present. It is slightly incomplete due to not describing expected return values, but this is not critical for a simple create operation.
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 a single required 'name' parameter with no description and 0% schema coverage. The description does not mention the parameter or provide additional meaning beyond 'create a type', so it fails to compensate for the schema's lack of detail.
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 ('Create new type') and the endpoint, and the tool name identifies the resource as shop product types. This distinguishes it from sibling tools like cigchat_shop_product_types_update, _delete, and _get_info.
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?
It provides a clear prerequisite by stating the required 'Manage Team' scope, which helps the agent know if it can invoke the tool. However, it does not explicitly discuss when to use create versus update or list alternatives.
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?
There are no annotations, so the description carries the burden. It discloses the required 'Manage Team' scope, which is useful behavioral context. However, it does not describe side effects, reversibility, error behavior, or return payload, leaving some transparency gaps 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 extremely concise: one sentence plus endpoint and scope. Every phrase contributes useful information (action, endpoint, permission requirement) with no filler.
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 (2 parameters, no output schema), but the description does not explain what the response looks like or what happens on success/failure. Since there is no output schema, the description should clarify return values, but it omits this, leaving the context incomplete.
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 50% (only typeId has a description). The description adds meaning to the 'name' parameter by stating 'Update type name', making it clear that name is the new name. However, no additional detail like format or constraints is provided, so it only partially compensates 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 the action ('Update type name') and identifies the resource (product type) and the field being modified. It distinguishes itself from sibling tools like create, delete, and get_info for product types.
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 need to update a product type's name) via the verb 'Update', but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. No alternative tools are referenced.
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 must carry the transparency burden. It discloses the required auth scope ('Manage Flow') and describes message type semantics (in/out/agent/note/system), which is useful. However, it does not explicitly state that this is a read-only operation, describe pagination, or mention potential side effects or response format, leaving gaps in 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 concise and front-loaded: a single clear sentence stating the tool's purpose, followed by a compact enumeration of message types, the endpoint, and an auth requirement. No unnecessary words or filler—every sentence serves a purpose.
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 9 parameters and no output schema, and no annotations. The description provides the endpoint, auth scope, and message type meanings, but it does not explain the response structure, how the include_* flags behave, or clarify that either user_id or user_ns must be provided (though the schema does). It is adequate for a basic listing tool but lacks deeper context about return values and edge cases, making it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, with each parameter (limit, user_id, user_ns, start_time, end_time, msg_type, include_bot, include_note, include_system) having its own description. The tool description does not add meaningful parameter-level detail beyond the schema; it does explain the 'type' field in the response, but that is not a parameter. Thus, the schema carries the heavy lifting, yielding a baseline score of 3.
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 function: 'Get list of subscriber chat messages.' It specifies a concrete verb ('Get'), a resource ('subscriber chat messages'), and the endpoint. The sibling tool 'cigchat_subscriber_chat_messages_by_mids' implies this one is for listing, distinguishing it from retrieving specific messages.
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 retrieving chat messages but does not explicitly state when to use it over alternatives, such as the 'by_mids' variant, or provide exclusions. It mentions the required 'Manage Flow' scope, which is a prerequisite rather than a usage guideline. No clear guidance on selection among siblings is given.
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. It discloses the HTTP method (POST) and the required 'Manage Flow' scope, which is useful. However, it does not describe return format, potential side effects, or error behavior, and 'and more' is vague about the actual payload structure.
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 that states the verb, resource, examples of contents, endpoint, and auth requirement. There is no repetition of schema information and no 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?
With only one parameter, a well-documented schema, and no output schema, the description covers the essential purpose and access requirements. However, 'and more' leaves the full return payload unspecified, and without an output schema, a slightly more detailed enumeration of returned fields would increase completeness.
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 only parameter, ai_agent_ns, is fully documented in the input schema (namespace id or exact name, server resolves automatically, example provided). Since schema description coverage is 100%, the baseline is 3, and the tool description adds no additional parameter context beyond what the schema already provides.
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 starts with the specific verb 'View' and clearly identifies the resource: 'Ai Agent details'. It enumerates what is included (description, prompts, ai function list) and distinguishes this from sibling tools like cigchat_flow_ai_agents (list agents) and cigchat_flow_ai_task_info (task details) by focusing on a single agent's full detail set.
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 tool's purpose implies usage—'View Ai Agent details' suggests it is for retrieving agent information—but there is no explicit instruction on when to use this versus other agent-related tools, nor any exclusion criteria. The scope requirement is noted, but no alternatives or context are 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?
The description discloses that the operation is a GET request (read-only) and requires a specific scope, which is helpful given the absence of annotations. However, it does not describe pagination behavior, default limits, or response format, leaving some behavioral traits 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 concise, front-loaded with the main action, and includes only essential details: purpose, HTTP method, and scope requirement. Every word earns its place, with no unnecessary 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-only list operation with no output schema and complete parameter schemas, the description is largely sufficient. It includes the endpoint and authentication requirement, but could go slightly further by indicating the response is a collection. Overall, it provides adequate context for an agent to use the 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?
The input schema covers all three parameters (code, page, limit) with descriptions, so the schema already provides full parameter semantics. The description adds nothing beyond this, aligning with the baseline score of 3 for high 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 'Get list of chat button widgets' with a specific verb and resource, and includes the HTTP method and path. This distinguishes it from sibling tools like cigchat_list_tags and cigchat_list_shortcuts by focusing on the unique resource type.
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 a prerequisite by stating 'Requires the Manage Flow scope on the token', which is useful context. However, it does not explicitly mention when to use this tool versus alternatives or when not to use it. The usage context is implied by the purpose but not fully elaborated.
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. It discloses the HTTP method (POST), required scope ('Manage Flow'), and the list of accepted providers, which are useful behavioral hints. However, it does not describe whether existing defaults are overwritten, error behavior, or the response format, leaving notable gaps 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 sentence that front-loads the primary action ('Set default ai provider and model') and then includes the endpoint, provider list, and scope requirement without redundancy. Every phrase contributes to identifying the operation and its constraints, making it appropriately compact.
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 with a fully self-describing schema and no nested objects, the description covers the core function, endpoint, required scope, and provider options. It is weak only in not indicating the return value or overwrite behavior, but given the tool's low complexity and the absence of an output schema, the description is largely sufficient.
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 both parameters with full descriptions: ai_provider lists the valid values and ai_model gives an example. The description repeats the provider list but adds no additional semantic depth beyond the schema, such as clarifying that ai_model is optional or explaining how the two parameters interact. With 100% schema coverage, 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 states 'Set default ai provider and model', which is a specific verb-resource pair. It also enumerates the allowed values for ai_provider, differentiating it from sibling tools like cigchat_flow_settings_get_default_ai_provider. The endpoint and scope requirement further clarify the operation.
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 from the verb 'set' and the resource name but does not explicitly mention when to use this tool versus alternatives such as cigchat_flow_update_ai_agent_provider or get_default_ai_provider. The scope requirement ('Manage Flow') provides a prerequisite, not a decision rule. No exclusions or alternative recommendations are given.
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 present, so the description carries the full burden. It discloses the authentication requirement and implies a read-only operation via 'Get list', but it fails to mention response format, pagination behavior, or error cases, which are useful for a list endpoint.
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 with the endpoint and permission front-loaded. Every word serves a purpose, and there is no redundant or fluff content.
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 list operation with optional pagination parameters fully described in the schema and an auth requirement noted, the description is largely complete. It could be improved by clarifying the distinction from the sibling template_installs tool or describing the response, but the core usage is covered.
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?
Both parameters (page and limit) are fully documented in the input schema with descriptions, so the tool description adds no additional parameter semantics. With 100% schema coverage, baseline 3 is appropriate.
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 ('list of template installs in this flow'), plus the HTTP endpoint. It clearly identifies the tool's scope ('in this flow') but does not explicitly differentiate it from the similarly named sibling tool cigchat_template_installs.
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 clearly states the required token scope ('Manage Flow'), which gives a concrete access prerequisite. However, it provides no guidance on when to use this tool versus the closely related cigchat_template_installs or other list tools.
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 transparency burden. It discloses the HTTP method and path, the required 'Manage Flow' scope, and the allowed provider values. However, it doesn't describe side effects (e.g., whether existing model/max_tokens are overwritten), reversibility, or return values. The scope requirement is useful context, but overall behavioral disclosure is limited.
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?
Single sentence, front-loaded with the action, includes essential context (endpoint, scope, provider list) without fluff. Perfectly concise.
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 combination of description and schema covers the essentials: what it does, how to call it (endpoint), prerequisites (scope), and parameter descriptions. Missing explicit usage guidance and behavioral side effects, but for a simple update tool this is largely adequate. Slight gap because no output schema means return format isn't described, but that may be standard.
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 descriptions for all four parameters, so the baseline is 3. The description's mention of valid ai_provider values duplicates the schema's enum-like description. It adds no new parameter semantics beyond confirming provider and model are updatable.
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 'update Ai Task provider and model' with a specific resource (Ai Task). It also includes the endpoint and scope, making the purpose unambiguous. It distinguishes from sibling cigchat_flow_update_ai_agent_provider by the 'Ai Task' resource.
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 when to use (to update an AI task's provider/model) but does not explicitly mention alternatives or exclusions, such as using cigchat_flow_update_ai_agent_provider for AI agents. The required scope is a precondition, not usage guidance. So usage context 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.
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 the required auth scope, which is useful, but does not explicitly state that this is a read-only operation, nor does it describe pagination behavior, sorting, or what the response contains. The GET verb implies read-only, but more detail would improve 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 a single sentence with no wasted words. It front-loads the action and resource, then includes the endpoint and auth requirement. Extremely concise and structurally clear.
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 list operation with 3 optional params and no output schema, the description is mostly complete: it gives purpose, endpoint, and auth scope. It does not mention response format or any pagination details, but the simplicity of the tool and clear schema compensate. Slight gap compared to the best examples.
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 100% of parameters with descriptions (name, page, limit). The tool description itself adds no parameter information, so the baseline of 3 is appropriate given the schema already provides meaning.
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 ('Get') and resource ('list of user fields'), with context 'by flow' and the API endpoint. It clearly distinguishes from sibling tools like flow_bot_fields and flow_create_user_field.
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 states a required OAuth scope ('Manage Flow'), which is a prerequisite, but does not explicitly say when to use this tool versus alternatives (e.g., when to list user fields vs. bot fields). Usage is implied by the title and description.
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?
Annotations are absent, so the description carries the burden of disclosing behavior. The verb 'Get' implies a read-only operation, and the scope requirement is disclosed. However, it does not mention what the config contains, response format, or possible errors beyond the scope constraint.
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?
A single, focused sentence that front-loads the purpose and includes the endpoint and token scope. No filler or redundant information, making it highly concise and easy to parse.
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, zero-parameter getter, the description is mostly complete: it states what is retrieved (config), the endpoint, and the required scope. However, with no output schema, it could benefit from a brief note on the shape of the config or any caveats, but this is minor given the tool's simplicity.
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 an empty schema, so there is nothing for the description to add regarding parameter semantics. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.
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 ('config of shopify integration'), and includes the endpoint. It unambiguously distinguishes this tool from sibling get_integration_* tools by naming Shopify specifically.
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 (e.g., get_integration_dropi, set_integration_shopify). The only usage-related detail is the required 'Manage Team' scope on the token, which is a prerequisite rather than comparative 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 provided, the description carries the full burden. It adds a GET endpoint and a required scope, giving some behavioral context, but it does not disclose pagination behavior, return format, or side effects, leaving transparency limited.
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 with no redundant details. It front-loads the core purpose and adds the endpoint and scope requirement efficiently, earning a high score for conciseness.
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 list tool with fully described parameters, the description is adequate: it states the purpose, endpoint, and scope requirement. However, it does not explicitly differentiate from the singular get_closing_note tool or describe the output shape, which is a minor gap.
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 fully documents all three parameters (name, page, limit) with descriptions, so the description does not need to add parameter details. It adds no extra meaning beyond what the schema already provides, justifying the baseline score of 3.
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 a specific verb ('Get'), resource ('closing notes'), and scoping ('current flow'), which distinguishes it from list operations on other resources. Including the endpoint further reinforces its purpose.
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 on when to use this tool versus cigchat_get_closing_note or other list tools. The 'current flow' scoping and the required 'Manage Flow' scope provide some usage context and prerequisites, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It explicitly indicates the HTTP method (GET) and the required scope, implying read-only access, but it does not detail response structure or pagination behavior. Some context is provided, but not rich behavioral depth.
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 terse sentences with no filler. The primary verb and resource are front-loaded, and the auth requirement is stated efficiently.
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 a simple filtered-list tool with 4 optional parameters fully described in the schema, the description covers the essential endpoint and auth scope. It is complete enough for a read operation, though lack of an output schema means the agent must infer response format.
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 baseline is 3. The description does not add parameter-level details, though 'member-uploaded' clarifies the context for user_id (workspace member). No additional value beyond 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?
Specific verb 'Get' with a clear resource 'member-uploaded media' and the explicit endpoint [GET /media-library]. This clearly distinguishes it from sibling tools as the media retrieval 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 description implies usage (when you need member-uploaded media) and states an access prerequisite ('Manage Team' scope), but it does not explicitly compare with alternatives or provide when-not-to-use guidance beyond that prerequisite.
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 explaining behavior. It discloses the HTTP method (POST), endpoint, and a specific auth requirement ('Manage Team' scope). However, it does not describe the effect on existing settings (e.g., whether it overwrites or merges), success/failure response, or any side effects. This is partial but not full 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 a single, concise sentence that includes the core action, the endpoint, and the required permission. There is no redundant information or filler. Every word earns its place.
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 tool with two well-documented parameters and no output schema, the description is largely complete: it states the action, endpoint, and auth requirement. However, it lacks any mention of when to use it versus the related get/clear integration tools, and it does not disclose whether the operation is idempotent or creates the integration if it does not exist. These gaps are minor given the low complexity.
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 clear descriptions for both parameters ('url' and 'api_key'), including an example URL. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the config of Dropi integration'. It uses a specific verb (update) and resource (config of Dropi integration), and the endpoint [POST /integration/dropi] adds specificity. This distinguishes it from siblings like get_integration_dropi (read) and clear_integration_dropi (delete).
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 updating the Dropi integration config, but it does not explicitly mention alternatives or exclusions. It does not compare against get_integration_dropi or clear_integration_dropi, nor does it state when not to use this tool. The required scope is a prerequisite, not a usage guideline.
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. It reveals the auth requirement and endpoint, which is useful. However, it doesn't mention side effects, idempotency, or response behavior for a mutation operation, leaving some 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?
A single sentence includes the purpose, endpoint, and auth scope, with no wasted words or redundant content.
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 tool is simple with only two required parameters and no output schema. The description covers the core action, endpoint, and auth. It could add more context, such as what config fields are affected or how to verify changes, but it is reasonably complete for the complexity.
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 provides descriptions for both parameters (token, dataset_id) covering 100% of them. The tool description does not add extra parameter-level detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 names the exact resource ('config of Meta Conversions Api integration'), plus the endpoint. It clearly distinguishes from sibling get_ and clear_ tools by specifying 'Meta Conversions Api'.
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 states the required 'Manage Team' scope but does not explicitly discuss when to use this tool versus alternatives like get_integration_meta_conversions_api for reading or clear_integration_meta_conversions_api for clearing. Usage is implied by the verb 'Update' but not directly contrasted with siblings.
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. It discloses the HTTP method (POST) and the required authorization scope ('Manage Team'), which is useful behavior context. However, it does not mention whether the update overwrites existing configuration, any irreversible effects, or the response shape.
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 includes the purpose, HTTP method, endpoint, and scope requirement. No wasted 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?
The tool is a simple config update with two parameters. The description covers the purpose, endpoint, and permission requirement. While it doesn't mention return values or side effects, the brevity is acceptable given the low complexity and full schema coverage.
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 ('Api Key', 'Organization Id'). The description does not add additional parameter semantics beyond what the schema already provides, so 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 the specific verb 'Update' and identifies the resource as 'the config of OpenAi integration'. It also includes the HTTP endpoint, clearly distinguishing it from sibling tools like get_integration_openai (read) and clear_integration_openai (delete).
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 states a prerequisite: Requires the 'Manage Team' scope on the token. However, it does not explicitly state when to use this tool versus alternatives (e.g., get vs update), nor does it mention any exclusion criteria. The usage context is implied by the verb 'Update'.
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. It discloses the HTTP method, endpoint, and required permission scope, but does not describe side effects (e.g., overwriting the existing API key), idempotency, or error/response behavior. It adds some behavioral context beyond the schema but lacks depth.
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-load the action and endpoint, followed by the permission requirement. No wasted words; all content is relevant.
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 configuration update, the description provides purpose, endpoint, and permission. It does not explain the return value or explicitly contrast with sibling set/clear tools, but given low complexity and high schema coverage, it is reasonably 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 coverage is 100% (single api_key param described as 'Api Key'), so baseline is 3. The description does not add further meaning about the parameter—it never mentions that api_key is the configuration value being updated—but the schema is sufficient given the simple 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 ('Update the config of XAi integration') and provides the specific HTTP endpoint, distinguishing it from sibling get_integration_xai (read) and clear_integration_xai (delete) tools.
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?
It notes the required 'Manage Team' scope, which implies a privileged write operation, but does not explicitly mention when to use this vs. get/clear integration tools or what scenarios call for it. The guidance is implied but not explicit.
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. It discloses that the operation is an update to product info and requires 'Manage Team' scope. However, it does not mention whether the update is partial or full replacement, what happens to unspecified fields, or the response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose. The second sentence packs an alternative and a permission requirement, but the bracketed endpoint is somewhat cluttered and may confuse; still, every sentence earns 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?
Given a 10-parameter update tool with no output schema and no annotations, the description is incomplete. It omits which fields can be updated, how to provide the required productId, potential errors, and return behavior. The provided permission scope and variant alternative are useful but insufficient 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the tool description adds no explanation for any parameters. It does not clarify the meaning of fields like 'id', 'name', 'type', 'vendor', or 'description' beyond the schema. 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 the tool updates product info, using the specific verb 'Update' and resource 'product info'. It also distinguishes itself from variant updates by directing users to the sibling tool, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use a different tool for variants ('To update variants, use /shop/products/update-variant'), providing a clear alternative. It also states a required permission scope ('Requires the "Manage Team" scope'), helping the agent decide when this tool is appropriate.
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 full burden. It discloses the core action and auth requirement, but does not explain side effects (e.g., what happens to ongoing conversations, whether the pause is reversible, or how long it lasts). This is adequate but has gaps.
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 action and resource, and includes the endpoint and auth requirement. Every sentence earns its place with no wasted 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?
For a simple mutation with 2 parameters and no output schema, the description gives the action, endpoint, and scope, but omits parameter semantics and behavioral details. It is minimally complete but leaves the agent to infer key usage details.
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 coverage is 50%: only 'minutes' has a weak description ('Example: 30'), while 'user_ns' is undocumented. The tool description adds no parameter meaning, so it does not compensate for the schema's minimal info. Parameter semantics are largely 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 a specific action ('Pause bot automation to subscriber') and includes the endpoint. This verb+resource phrasing distinguishes it from sibling tools like resume_bot or unsubscribe_from_bot.
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 a clear prerequisite ('Requires the Manage Flow scope on the token'), giving context for when the tool can be used. It does not explicitly mention alternatives or exclusions, but the scope requirement offers useful usage guidance.
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 and does well by disclosing the required auth scope ('Requires the Manage Flow scope') and the batching limit ('up to 20 tags'). It clearly labels the destructive action ('Remove'), though it does not discuss reversibility or behavior when exceeding the limit.
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 with no redundant wording. It front-loads the core action, then packs the endpoint and auth requirement efficiently.
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?
For a 2-parameter mutation with no output schema and no annotations, the description covers the operation, limit, and auth, but the missing parameter semantics for 'data' and especially 'user_ns' leave a notable gap. An agent may not be able to correctly invoke the tool without additional inference.
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 that tags are provided by name. The required 'data' array structure (objects containing 'tag_name') and the 'user_ns' field are not explained, leaving the agent to guess how to format the request.
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 ('Remove'), identifies the resource ('tags from subscriber'), and clarifies the method ('by tag name') with an explicit endpoint. It distinguishes itself from sibling tools like 'cigchat_subscriber_remove_tag_by_name' by specifying batch operation up to 20 tags.
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 batch usage via 'up to 20 tags' and the plural 'tags', but it does not explicitly state when to choose this over singular alternatives like remove_tag_by_name or list_tag removal tools. No alternatives or exclusions are mentioned, only implied.
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 full burden for behavioral disclosure. It reveals the HTTP method (GET) which implies a read-only operation, and states the required scope. However, it does not mention pagination behavior, return format, or any implications of using the token. This is acceptable for a simple list tool but leaves some gaps.
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 exactly two sentences: one for the action and resource, one for the authentication requirement. Every word earns its place, with no redundancy or filler. The endpoint is included as a useful hint.
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 list operation with 100% parameter schema coverage and no output schema, the description is sufficiently complete. It identifies the resource, the auth requirement, and the HTTP method. It could mention the relationship to sibling list tools, but the name and endpoint make the purpose clear.
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 fully covers all three parameters (name, page, limit) with descriptions, achieving 100% coverage. The description adds no parameter-specific details, but baseline 3 is appropriate since the schema already provides the necessary 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 clearly states 'Get list of ticket lists' with a specific verb and resource, and includes the HTTP endpoint. This distinguishes it from siblings like cigchat_team_ticket_lists_items (which retrieves items within a list) and mutation tools (create/delete/update).
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 naming the resource and providing the endpoint, but it does not explicitly state when to use this over related tools like cigchat_team_ticket_lists_items or fields. It does mention the required scope ('Manage Team'), which provides some context, but no explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the auth requirement ('Manage Team' scope) and identifies the HTTP method as GET, which implies a read-only operation. However, it does not disclose pagination behavior, error cases, or return format, which would be valuable for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action ('Get list of installs'), then provides the endpoint and auth requirement. Every piece of information earns its place, with no wasted 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 list tool with three parameters, the description covers the essential context: the resource (template namespace), the HTTP endpoint, and the required scope. The absence of an output schema is partially mitigated by the clear name and purpose, but it could be more complete by mentioning pagination defaults or the type of installs returned. Overall, it is sufficiently complete for 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?
The input schema has 100% description coverage, so parameters are already well-documented. The description only adds that results are filtered 'by template ns', which aligns with the templateNs parameter. It does not add extra semantics for page or limit beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Get list of installs by template ns', with a specific resource (template namespace) and the HTTP endpoint. This clearly distinguishes it from sibling list tools like list_templates or list_tags, which operate on different resources.
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 used to fetch installs for a given template namespace, and it notes the required 'Manage Team' scope. However, it does not explicitly state when to choose this over other list tools or provide exclusions/alternatives, so usage guidance is only implied.
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. It discloses the required 'Manage Flow' scope and the GET method, which implies read-only behavior. However, it does not explain response format, pagination behavior, or edge cases.
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 efficiently states the action and auth requirement, with no unnecessary words. It front-loads the core purpose and includes only essential additional context.
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 a simple list operation with no output schema. The description mentions the endpoint and scope but lacks details on the response structure and default pagination. Given the schema covers filters, it is adequate but minimal.
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?
All 5 parameters have descriptions in the schema, covering their semantics. The description does not add any parameter-specific information, but with 100% schema coverage, 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 states the tool's function as 'Get list of ai tasks by flow', including the HTTP method and path. It distinguishes from sibling tools like cigchat_flow_ai_task_info by indicating it returns a list rather than details of a single task.
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 for when to use this tool (listing AI tasks) but does not explicitly mention alternatives or when not to use it. No reference to sibling tools like cigchat_flow_ai_task_info is made, 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?
The description discloses the required 'Manage Flow' scope and the HTTP PUT method, providing useful context. However, it does not mention behavior for non-existent fields, whether the operation is destructive, or the response format. With no annotations, this is only partially 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?
A single sentence with no filler, including the endpoint and scope requirement. Excellent front-loading and zero waste.
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?
For a simple update tool with two string params, the description covers the core intent but lacks guidance on return values, error conditions, and behavior when the field doesn't exist. Without an output schema, some of this context would be helpful.
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 description clarifies that 'name' is the bot field name and 'value' is the value to set, directly mapping to the two parameters. Given the schema has 0% description coverage, this is valuable, though it lacks format or constraint details beyond the schema's string types.
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 'update' and resource 'bot field', and explicitly states the identification method 'by bot field name'. This distinguishes it from sibling tools like set_bot_field (likely ID-based) and set_bot_fields_by_name (plural).
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 used when you have the bot field name rather than an ID, but it does not explicitly compare with alternatives or provide exclusions. It mentions the required scope but not when to prefer this over other field update tools.
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. It discloses the required 'Manage Flow' scope and the HTTP POST method, which provides some behavioral context. However, it does not explain side effects (e.g., overwriting existing settings), idempotency, or response behavior, leaving gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and packs essential details (endpoint, auth, allowed values) compactly. The comma-separated list is slightly unwieldy but acceptable for the information density.
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 single-parameter setter, the description covers the key aspects: what it does, what values are allowed, and the required permission. It doesn't specify the response format or explicitly note that it overwrites the current setting, but given the tool's simplicity, this is reasonably complete.
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 input schema only defines stt_model as a required string with no description or enum. The description compensates by enumerating all accepted values (none, whisper-1, gpt-4o-transcribe, etc.), which is critical for correct invocation. It could add more context about the meaning/default but largely fills the schema 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 clearly states the tool's function: 'Set audio transcription' with a specific resource and action. The list of available values and the endpoint further disambiguate it from sibling set_* tools, making the purpose unmistakable.
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 (changing the audio transcription model) and includes a prerequisite (Manage Flow scope), but it doesn't explicitly state when to use this tool versus alternatives or when not to use it. No alternative tools 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?
The description discloses that a 'Manage Flow' scope is required on the token, which is a useful permission detail. However, without annotations, it doesn't mention other behavioral aspects like whether the user field must exist, side effects, or what the response contains. The auth requirement is the main contribution.
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 succinctly states the purpose, includes the endpoint, and notes the required token scope. It is front-loaded with the action and has no unnecessary 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 description is adequate for a simple update operation but lacks clarity on prerequisites (e.g., must the field exist?), required property combinations (must at least one of name/display_type be provided?), and the return value or success indication. Since there is no output schema and no annotations, these gaps affect completeness.
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 description explains that 'Update user field name or display_type' directly maps to the 'name' and 'display_type' parameters, adding meaning to the 'name' parameter which lacks a schema description. It also reinforces what var_ns refers to through the context, though the schema already describes it well.
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 'Update user field name or display_type' with a specific resource (user field) and the specific attributes that can be changed. It also includes the endpoint, which adds clarity. This distinguishes it from sibling create/delete tools.
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 does not explicitly state when to use this tool vs alternatives such as create/delete user field. The verb 'update' implies it's for modifying existing fields, but no explicit when/when-not guidance or alternative references are 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 transparency burden. It does disclose the HTTP method and required scope, which is helpful. However, it does not explicitly state that this is a read-only operation with no side effects, nor does it describe the contents of the config or potential 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 concise sentence that includes the endpoint and a key prerequisite. Every word adds value, with no redundancy or filler.
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 low complexity and no parameters, the description is mostly adequate. However, there is no output schema, so the agent does not know what the returned config contains. The description could briefly mention typical fields or that the config may be absent if unset. It is minimal but not severely incomplete.
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?
There are zero parameters, so the input schema trivially covers everything. Baseline for 0 params is 4; the description adds no parameter info because none exist, which 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 uses a specific verb 'Get' and clearly identifies the resource as 'the config of WooCommerce integration'. It distinguishes from sibling tools by including the platform name and API endpoint, making it unambiguous.
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 when to use this tool (when needing WooCommerce integration config) but does not explicitly state when not to use it or name alternatives like set_integration_woocommerce for modifications. The scope requirement is useful but not full usage guidance.
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 burden. It discloses the irreversible side effect ('real message') and the required 'Manage Flow' scope, which are important behavioral details. It does not mention rate limits or cost, but the key warnings are present.
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, front-loaded with the action and endpoint, and adds critical behavioral notes without 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 2-parameter tool with no output schema and no annotations, the description covers the essential purpose, delivery nature, and auth requirement. It lacks an explicit definition of user_ns, but overall is adequate.
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 coverage is only 50% (content has a description, user_ns does not). The description does not clarify what 'user_ns' means or provide additional parameter context, leaving a gap for the agent.
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 it sends SMS content to a subscriber, using a specific verb and resource. It also distinguishes from sibling tools by explicitly naming SMS, unlike send_email or send_whatsapp_template.
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?
It implies usage by saying 'Delivers a real message to a person,' indicating this actually sends a message rather than simulating. However, it does not explicitly compare to alternatives 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.
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 disclosing side effects. It does note that this 'Delivers a real message' and requires a specific scope, but it lacks details on reversibility, failure modes, or rate limits. Still, it provides essential context beyond the bare action.
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 brief, front-loaded with the primary action, and includes only necessary details (endpoint, side effect, auth scope). Every sentence contributes value without redundancy.
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?
For a sending tool with two parameters and no output schema, the description covers the core action and auth but does not mention the expected return behavior or what happens on success/failure. This is acceptable but leaves the agent without a full mental model of the tool's response.
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 covers sub_flow_ns well but leaves user_id with no description. The description compensates by clarifying that user_id is 'the unique user id from each channel', adding meaning that the schema does not. This partially bridges the 50% coverage 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 clearly states the action ('Send sub flow'), the target ('to subscriber by the unique user id'), and reinforces that it 'Delivers a real message to a person'. This distinguishes it from sibling tools like send_subflow_by_name and send_main_flow by the explicit user_id targeting.
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 user_id to address a subscriber. However, it does not explicitly state when to use this tool versus alternatives like send_subflow_by_name, nor does it mention any exclusions or prerequisites beyond the auth scope.
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 transparency burden. It discloses that the tool 'Delivers a real message to a person,' which is a critical side effect, and states the required auth scope ('Manage Flow'). This goes beyond a bare mutation description, though it does not mention reversibility or what happens to the cart contents.
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 includes the endpoint plus a critical side-effect warning. Every sentence earns its place, with no filler or repetition.
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?
For a mutation tool with 14 parameters, no output schema, and no annotations, the description provides the essential action, side effect, and auth requirement, but omits details like whether the cart is cleared, whether an order record is created, or what the response contains. It is adequate but incomplete for full operational clarity.
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 71%, so most parameters are already described in the schema. The description adds no parameter-specific meaning, leaving the schema to handle semantics. This aligns with the baseline for high 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's function: 'Checkout subscriber shopping cart and mark as paid.' The verb 'checkout' and the resource 'subscriber shopping cart' are specific, and the action of marking as paid distinguishes it from sibling tools like add_to_cart, remove_from_cart, and empty_cart.
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 when to use the tool—when you need to checkout a subscriber's cart—but does not explicitly state alternatives or exclusion conditions. The prerequisite 'Requires the Manage Flow scope' gives context but does not explain when to prefer this over, for instance, shop_orders_create. The usage context is clear but not fully articulated.
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. It discloses the HTTP method (GET) and required authorization scope, which are useful behavioral signals. However, it does not describe the response type, fields, or explicitly confirm read-only behavior beyond the GET method.
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 stating the action, endpoint, and scope requirement. Every piece of information earns its place with no redundancy.
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?
For a no-parameter GET tool, the description provides the essential request details (endpoint, method, scope) but omits any explanation of the return value. Since there is no output schema, an agent may not know what data to expect, leaving a notable gap.
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 is empty, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description adds no parameter information because none is needed.
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 a GET operation for workspace settings related to Channels, with the endpoint provided. The verb 'Get' distinguishes it from the sibling update_channels tool, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving channel settings but does not explicitly state when to use this tool versus the update_channels sibling or mention any alternatives. It includes a prerequisite (Manage Team scope), but that is an authorization requirement, not usage 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?
No annotations are provided, so the description carries the burden. It discloses the required 'Manage Team' scope, which is valuable auth context, and the endpoint. However, it does not describe the return structure, potential errors, or confirm read-only behavior beyond the verb 'Get'. This is a moderate level of 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 a single sentence that combines purpose, endpoint, and auth requirement with no filler. It is front-loaded with the main action and immediately useful.
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?
Even without an output schema, the description gives the essential context: what the tool returns (config of XAi integration), how to call it (GET endpoint), and what permission is needed. Given the simplicity of a no-parameter getter, this is reasonably complete, though it could hint at the shape of the config.
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?
With 0 parameters and 100% schema coverage (empty schema), the description need not explain parameter semantics. The baseline for 0 params is 4, and there is nothing to add.
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 ('Get') and resource ('config of XAi integration'), and clearly distinguishes this from sibling tools like get_integration_openai or set_integration_xai. The endpoint '[GET /integration/xai]' reinforces the exact operation.
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: call this tool when you need to retrieve the XAi integration config. However, it does not explicitly mention when not to use it or provide alternatives (e.g., set_integration_xai for updates, or other get_integration_* tools for different integrations).
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?
No annotations are present, so the description carries the transparency burden. It discloses the HTTP method (GET) and the required 'Manage Team' scope, providing key behavioral context. It does not describe response format or error behavior, but for a simple GET this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with the endpoint and scope requirement. No wasted words; front-loaded with the action.
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 tool with one parameter and no output schema, the description provides the essential action, endpoint, and auth scope. It lacks explicit response details but is adequate for a get-info operation.
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 the tagId parameter described as 'Tag Id'. The description adds no additional parameter meaning, but the schema fully documents it, so 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?
Clearly states 'Get tag info' with the exact endpoint [GET /shop/product-tags/{tagId}/get-info], unambiguously identifying it as a read operation for a single product tag by ID. Distinct from siblings like list_product_tags (list all) and create/update/delete.
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 this tool versus alternatives. The endpoint and parameter imply it is for retrieving a single tag's info (vs list_product_tags for listing), but this is not stated. The scope requirement gives some usage context but not when/where.
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 full behavioral disclosure burden. It usefully reveals the required OAuth scope and the HTTP method, but does not mention pagination behavior, return format, or confirm the read-only nature beyond the verb 'Get'. This is adequate but not rich.
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?
A single sentence conveys the action, resource, context, endpoint, and authentication requirement. Every element is functional, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list operation with a fully described schema and clear endpoint, the description is largely sufficient. It lacks explicit return format or pagination details, but those are inferable from the endpoint and parameters. A slightly richer note on response structure would make it fully 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?
The schema already provides 100% coverage with descriptions for all three parameters (name, page, limit). The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('shortcuts'), and the contextual scope ('current flow'). It also includes the exact HTTP endpoint, which fully disambiguates it from sibling list tools like list_tags or get_shortcut.
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 a clear context indicator ('current flow') and a critical prerequisite ('Requires the Manage Flow scope'). It does not explicitly name alternative tools like get_shortcut or flow_create_shortcut, but the purpose is specific enough to guide usage.
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 exist, so the description alone must disclose behavior. It adds useful context about opaque ids ('f123t456') and the ability to disambiguate, but it does not specify the output structure, behavior on no matches, or explicitly confirm that it is read-only. The cap of 100 is only in the schema, not in the description.
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?
Three sentences, all purposeful: first states the core function, second explains why opaque ids matter, third gives usage direction. No redundant filler or repetition of schema content.
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 two-parameter lookup tool with no output schema, the description covers purpose, usage timing, and domain context. It lacks explicit return-format details, but the schema's 'capped at 100' note and the description's mention of 'list what is available' collectively give an agent enough to act. The 'show the human' phrase implies a list of options, which is helpful.
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?
Both parameters are fully described in the schema (100% coverage), so the description adds little param-specific detail beyond the schema. It does reinforce the semantics of 'name' as optional ('list what is available') and explains the need to resolve names to ids, but this is context rather than new parameter syntax.
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 phrase ('Look up the namespace id') and names the resource types (tag, flow, field, segment, agent). It also clarifies the tool's broader capability ('or list what is available'), distinguishing it from sibling list tools by framing it as a resolver for opaque ids.
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 states when to use this tool: 'when you want to show the human the available options, or to disambiguate when a name matched more than one thing.' It also provides a when-not by noting 'Most tools accept a plain name and resolve it for you.' It stops short of naming specific sibling tools like cigchat_list_tags, but the guidance is clear.
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. It discloses the HTTP method (GET) indicating a read-only operation and the required auth scope. However, it does not describe the response format, error behavior, or any potential side effects, leaving some uncertainty about what the agent can expect after calling.
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 leads with the core action 'Get store business hours', then concisely includes the endpoint and auth requirement. Every word adds value, with no redundancy or unnecessary detail.
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, no-parameter getter with no output schema, the description provides adequate context: the purpose, endpoint, and authentication requirement. It could optionally mention that the response contains the hours data, but the function name and endpoint make this highly obvious. The tool is simple enough that the description is largely complete.
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?
With zero parameters and an empty schema (100% schema description coverage), there is nothing for the description to add about parameter semantics. The baseline of 4 for zero-parameter tools applies, as the description correctly omits any parameter details.
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 function: 'Get store business hours'. It specifies the HTTP endpoint 'GET /shop/business-hours/info' and distinguishes itself from sibling tools like 'cigchat_shop_business_hours_update' through the verb 'Get' versus 'Update'. This is a specific verb+resource construction.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. It does provide a prerequisite ('Requires the Manage Team scope'), which implies the tool is for authenticated read access, but no guidance on when to prefer it over similar tools. Usage context is present but 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.
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 does disclose the authentication requirement ('Manage Team' scope) and the GET method, which is valuable context. However, it omits details about pagination defaults, sorting, or error behaviors, making it only moderately 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 a single, front-loaded sentence that states the verb and resource, followed by the endpoint and scope requirement. There is zero waste, 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?
Given that it's a simple list operation with no output schema, the description is reasonably complete. It includes the endpoint and auth context, and the schema covers parameter details. It could mention response shape, but the 'list' verb and sibling tools provide enough context for most agents.
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 provides descriptive text for all three parameters (name, page, limit) with 100% coverage. The description adds no additional parameter semantics beyond what the schema already includes, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get list of Agent Groups' with the endpoint, making the action and resource explicit. It distinguishes itself from sibling tools like cigchat_team_create_agent_group or cigchat_team_update_agent_group by focusing on the list/retrieve operation.
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 for when to use this tool (listing agent groups) and explicitly notes the required 'Manage Team' scope, which is a crucial prerequisite. It doesn't explicitly mention alternatives, but for a simple list operation the usage context is sufficiently clear.
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 must carry the transparency burden. It discloses the required authorization scope ('Manage Team' scope) and implies read-only behavior through the verb 'Get'. However, it does not describe pagination behavior, response format, or potential errors, which are relevant for a list endpoint without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose ('Get list of workspace members'), includes the endpoint for reference, and notes the required scope. Every element adds value with no wasted 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 list tool with well-documented parameters and a clear read-only purpose, the description is adequate. It includes the auth requirement and makes the return type (a list) implicit. The lack of an output schema means the agent must infer the response structure, but the simplicity of the operation mitigates this. A perfect score would require more detail on return format or pagination behavior.
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 already provides comprehensive descriptions for all four parameters (name, page, role, limit), achieving 100% schema description coverage. The tool description adds no additional parameter semantics beyond what is in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function: 'Get list of workspace members' with a specific verb (Get) and resource (workspace members). It also includes the endpoint for additional clarity and is distinct from sibling tools like team_agent_groups (lists groups) and team_bot_users (lists bot users).
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 context is clear: use this tool to fetch the list of workspace members. It also mentions a prerequisite (requires 'Manage Team' scope), which aids in deciding when this tool is appropriate. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 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?
No annotations are present, so the description carries the burden. It discloses the required 'Manage Team' scope, the endpoint, and pagination behavior. However, it does not state that it is read-only (though GET implies it), nor describe response format or error behavior. It adds some behavioral context but 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 a single sentence that conveys purpose, endpoint, and scope without any fluff. Every element (GET, paginated, workspace, scope) is meaningful and contributes to understanding.
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 tool is a simple list operation with 7 optional, clearly documented filter parameters. The description covers the core purpose, pagination, endpoint, and required scope. It does not describe the return payload, but that is somewhat mitigated by the absence of an output schema and the simplicity of the operation. Given the schema richness, the description 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%, so each parameter already has a clear description. The tool description adds no param-specific meaning beyond what the schema provides; 'paginated' loosely relates to page/limit but is already evident from the param names. 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 opens with 'Get paginated WhatsApp call logs for the workspace' — a specific verb, resource, and scope. Including the endpoint and required scope ('Manage Team') further clarifies the operation. There are no sibling tools for call logs, so it 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context (workspace-level call logs, pagination) and the required permission scope. It does not explicitly name alternatives or exclusions, but since no other tool handles call logs, usage is implied without confusion. This is more than the 'no guidance' case but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive and irreversible nature ('DESTRUCTIVE: irreversible'), the required confirmation workflow, and the necessary scope. This goes beyond typical descriptions and gives the agent a clear safety profile.
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 only three sentences, each carrying essential information: purpose/danger, confirmation workflow, and permission requirement. It is front-loaded, direct, and contains no filler.
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 covers purpose, destructive risk, confirmation protocol, and scope. Given the two-parameter schema with high coverage and no output schema, this is nearly complete. It loses a point because it doesn't address how this tool relates to sibling tag-deletion tools, which is important given the extensive sibling list.
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 both parameters thoroughly (tag_ns accepts id or exact name; confirm is a token from the previous response). The description only restates the confirmation behavior without adding new parameter-level meaning, so baseline 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 states 'Delete tag' and gives the endpoint 'DELETE /flow/delete-tag', making the verb and resource clear. It does not explicitly differentiate from sibling tools like `cigchat_flow_delete_tag_by_name` or `cigchat_delete_product_tag`, so it is clear but lacks 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions: 'Call once without `confirm` to get an impact statement first' and states the required 'Manage Flow' scope. However, it does not explain when to choose this tool over the sibling `cigchat_flow_delete_tag_by_name` or other delete-tag variants, so alternative selection guidance is missing.
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 clearly flags the operation as DESTRUCTIVE and irreversible, explains the two-step confirm flow, and requires the 'Manage Flow' scope. This goes beyond the basic schema and gives the agent critical safety 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 composed of three concise sentences: purpose, destructive warning, and usage/scope. It front-loads the essential action, clearly flags danger, and provides necessary prerequisite information without any filler or repetition.
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 destructive operation with no annotations and no output schema, the description covers the critical aspects: purpose, destructive irreversibility, required action flow, and scope. It could mention what happens after deletion or provide a note about accepting both namespace id and name, but the schema fills some gaps. Overall, it is sufficient for an agent to use the tool safely and correctly.
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?
Schema description coverage is 100% for both parameters, so the schema already handles parameter details. The description adds meaningful context by explaining the `confirm` parameter's role in the two-step process (getting an impact statement first). This is not redundant with the schema and helps the agent understand the expected workflow.
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: 'Delete user field' with the HTTP DELETE endpoint. It specifies the resource and action. However, it does not differentiate this tool from its sibling 'cigchat_flow_delete_user_field_by_name', which also deletes user fields.
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 explicit usage steps: call once without `confirm` to get an impact statement, then pass the confirmation token after approval. It also states the required scope. However, it does not mention when to use this tool over alternative deletion tools like 'delete_user_field_by_name' or 'subscriber_clear_user_field'.
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 usefully states the required 'Manage Flow' scope and the POST endpoint, but it does not disclose consequences such as overwriting the existing default, return behavior, or error handling. This is a meaningful but incomplete transparency profile.
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 purpose is front-loaded in a single sentence, and every clause contributes: purpose, special 'main' value, endpoint, and auth scope. It is slightly repetitive with 'start flow' and 'main flow' but remains concise and readable.
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 one-parameter setter with no output schema, the description covers the essential context: target widget, purpose, parameter special value, endpoint, and required scope. It omits return/error details and does not explicitly distinguish from the sibling set_default_start_flow, but those are minor gaps for this simple mutation.
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 already documents sub_flow_ns fully (namespace id or exact name, server resolves automatically). The description adds the valuable special-case hint to use 'main' for the main flow, which goes beyond the schema and helps the agent pick the correct 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 opens with the specific action 'Set default start flow for web chat widget', clearly identifying the verb, resource, and target. The 'web chat widget' qualifier differentiates it from the sibling tool cigchat_flow_set_default_start_flow.
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 that this is for configuring the web chat widget and explicitly advises using 'main' to set the main flow. It does not explicitly name alternative tools or exclusion cases, but the widget-specific context makes usage clear.
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 the required 'Manage Flow' scope and the API endpoint, which is valuable. However, it omits behavioral details such as return format, error handling (e.g., user not found), or any side effects. For a simple read operation, this is adequate but not rich.
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 that states the action, the parameter type, examples, endpoint, and auth requirement. No redundant information; every component 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 simple (one parameter, no output schema), so the description covers the essential purpose and auth. However, it does not mention what the response contains (e.g., full subscriber object) or behavior when no subscriber matches, which would be helpful for a complete picture.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that the user_id is a channel-specific unique ID (not an internal ID), which is not evident from the schema's bare 'Subscriber user_id'. This raises the score above baseline.
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 subscriber info using a channel-specific unique ID, with concrete examples (Facebook, WhatsApp, WeChat). This distinguishes it from sibling tools like 'cigchat_get_subscriber' which likely uses an internal ID, and provides a specific verb+resource+scope.
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 gives clear context for when to use the tool: when you have a channel-specific user ID (e.g., Facebook, WhatsApp). It does not explicitly mention alternatives or exclusions, but the examples effectively imply the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and succeeds: it explicitly labels the operation 'DESTRUCTIVE: irreversible', explains the two-step confirmation flow via impact statement, and states the auth scope (Manage Team). This goes well beyond what the schema alone conveys for a destructive mutation.
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?
Three short sentences lead with the purpose, follow with the critical destructiveness warning, and close with the usage prerequisite. Every sentence contributes unique information with zero waste, making it exemplary in economy and structure.
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-parameter destructive tool with no annotations or output schema, the description covers the essential context: the operation, irreversibility, the confirmation flow, and the required scope. It falls slightly short of a 5 by not describing what the impact statement contains or what the response looks like in either call mode, though the schema's `confirm` note fills in part of that gap.
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 both `code` and `confirm` are already documented in the schema, including a detailed explanation of the confirmation token flow. The description merely restates the confirm workflow without adding new parameter-level meaning (e.g., code format or lookup behavior), so it hits the baseline without exceeding it.
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 ('Delete discount code by code') and includes the HTTP endpoint, making the purpose unambiguous. However, it doesn't explicitly differentiate from the sibling tool `cigchat_shop_discount_codes_delete`, which likely deletes by a different identifier (e.g., ID), so the distinction is only implicit in the name and phrase 'by code'.
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 actionable workflow guidance: 'Call once without `confirm` to get an impact statement first' and explains the required 'Manage Team' scope. However, it does not mention alternatives or when-not-to-use scenarios relative to other discount code tools, so the when-to-use context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly warns 'DESTRUCTIVE: irreversible' and explains the two-step confirmation process, which is critical for a delete operation. The mention of the required token scope adds important context about auth requirements.
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, densely informative sentence that front-loads the action ('Delete location') and includes the endpoint, destructiveness warning, usage instructions, and auth requirement. Every element is necessary and earns its place, with no unnecessary 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?
The description covers the core aspects: what it does, how to use it safely, required permissions, and the impact statement step. Since there is no output schema, it does not describe return values or post-deletion effects, but for a destructive delete tool this is a minor gap. Overall, the context is sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the `confirm` parameter already described in detail in the schema (confirmation token from previous response, call without it first, show impact statement, pass token after approval). The tool description adds no additional parameter-specific meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 deletes a shop location and includes the explicit API endpoint [DELETE /shop/locations/{locationId}/delete], making the action unambiguous. However, it does not explicitly differentiate itself from sibling tools like other delete operations (e.g., cigchat_shop_products_delete), relying on the tool name for distinction.
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 a clear usage workflow: call once without `confirm` to receive an impact statement, then pass the confirmation token after human approval. It also states the required permission scope ('Manage Team'), offering concrete guidance. It does not mention alternatives or explicitly describe when not to use the tool, but the destructive nature and confirm flow are well conveyed.
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 of behavioral disclosure. It reveals important traits: the limit of 100 mids, the meaning of the type field (in/out/agent), the HTTP endpoint, and the required OAuth scope. It does not describe return format or error behavior, but the 'type' explanation and auth note add valuable context beyond the schema.
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 dense sentence that front-loads the primary action and then adds limit, type semantics, endpoint, and auth requirements. It is concise and each piece of information is relevant. Minor typo ('Ougoing') and lack of structured formatting prevent a 5, but overall it is compact and readable.
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 tool with one parameter and no output schema, the description covers the essential aspects: what it returns (chat messages), the input constraint (mids up to 100), the message type taxonomy, the endpoint, and authorization. It does not describe the response structure or pagination, but for selecting and invoking the tool, this is largely sufficient. A more detailed return description would push it higher.
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 only parameter, mids, has full schema coverage with a description and example. The tool description repeats the 'up to 100 mids' limit but does not explain what a mid is or add formatting details. Since the schema already documents the parameter, the description adds marginal value beyond the schema, 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 the tool's purpose: 'Get chat messages by multiple mids, up to 100 mids.' It identifies the specific resource (chat messages), the key qualifier (by multiple mids), and a limit. This distinguishes it from the sibling tool cigchat_subscriber_chat_messages, which likely fetches messages by subscriber rather than by mids.
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 for when to use the tool: when you have a list of mids (message IDs) and need their content. It also includes prerequisite access requirements (Manage Flow scope). However, it does not explicitly mention alternative tools or when not to use it, so it misses the top score.
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 full responsibility for disclosing behavior. It explicitly flags 'DESTRUCTIVE: irreversible' and describes the confirmation step, which are critical safety traits. However, it does not detail what the impact statement contains or whether related data (e.g., conversations) is cascade-deleted.
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 compact and front-loaded: a single action statement, a destructive warning, the confirmation workflow, and the required scope. Every sentence earns its place with no redundancy or 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 destructive mutation tool with no annotations and no output schema, the description covers the most critical aspects: irreversibility, confirmation flow, and auth requirement. It lacks explanation of `user_ns` semantics and any post-deletion effects, but overall it is sufficiently complete for a delete operation.
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 50%: `confirm` is well-documented in the schema, but `user_ns` has no description. The tool description does not explain what `user_ns` represents, nor does it add meaning to `confirm` beyond the schema. Thus the description adds minimal parameter 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 clearly states 'Delete subscriber' with an explicit endpoint, making the tool's purpose unambiguous. It is easily distinguishable from sibling subscriber tools like remove_tag or unsubscribe_from_bot, as it targets the subscriber record itself.
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 specific usage guidance: call without `confirm` first to get an impact statement, then pass the confirmation token after human approval. It also states the required 'Manage Flow' scope. It does not explicitly name alternative tools for non-destructive actions, but the two-step confirmation workflow is clear.
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 burden of behavioral disclosure. It transparently reveals that this is a GET request (read-only) and states the required authentication scope. While it does not describe the response format or error behavior, for a zero-parameter getter this is adequate 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 a single sentence that leads with the action and resource, then includes the endpoint and scope requirement. It is concise, front-loaded, and contains no fluff or 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 has no output schema, so the description should ideally explain what the returned Live Chat Sidebar settings contain. It does not, leaving the exact structure of the response undefined. However, for a simple read operation with no parameters, the name and endpoint may be sufficient in context, but the missing response detail prevents a higher score.
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 already covers this completely (100% coverage). The description does not need to add parameter-level details, and it does not attempt to, making this a baseline score for a no-parameter 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 ('workspace settings - Live Chat Sidebar'), explicitly noting the HTTP GET endpoint. This distinguishes it from the sibling update tool (cigchat_workspace_settings_update_live_chat_sidebar) which modifies settings instead of reading them.
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 the required 'Manage Team' scope as a prerequisite, which is useful context. However, it does not explicitly indicate when to use this tool versus alternatives, and there is no mention of the read-only nature being a reason to prefer it over update operations. Usage is implied by the tool's name and purpose rather than explicitly stated.
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 full burden. It discloses that the action is DESTRUCTIVE and irreversible, and explains the two-step confirmation process. It also states the required scope. This is strong behavioral disclosure for a destructive 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 three concise sentences, each earning its place: purpose/endpoint, destructive warning with first-step instruction, and required scope. It is well-structured and front-loaded.
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 destructive operation with one parameter, the description covers the essential aspects: what it does, how dangerous it is, the confirmation flow, and required permissions. It could optionally detail success responses, but that is not critical for safe use.
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 description for 'confirm' already thoroughly explains the confirmation token flow, achieving high coverage. The tool description repeats this guidance but adds little new semantic value beyond what the schema already provides.
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 action: 'Clear the config of Meta Conversions Api integration'. It includes the HTTP DELETE method and explicitly names the specific integration, distinguishing it from other clear_integration_* siblings by 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for usage: 'Call once without `confirm` to get an impact statement first' and requires 'Manage Team' scope. It also warns of destructiveness. However, it does not explicitly mention alternatives such as the corresponding get_integration_* tool or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses the endpoint, the required scope, and a reset behavior, but does not elaborate on side effects (e.g., impacts on existing conversations or whether the change is reversible beyond the main reset). This is adequate but not rich, hence a 3.
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 packs purpose, reset behavior, endpoint, and authorization scope without redundancy. It is front-loaded with the primary action and uses no unnecessary words, earning a high score.
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 parameter, no output schema), the description covers the essential aspects: what it does, how to reset, the endpoint, and the required scope. It does not mention the effect on new vs. existing conversations, but for a configuration setter, the provided details are sufficient for most use cases.
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 already describes sub_flow_ns as accepting a namespace ID or exact name with automatic resolution. The description adds valuable parameter-level guidance by specifying that passing 'main' resets the flow, which is not in the schema. This extra semantic information enhances usability 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's function: 'Set default bot start flow.' It also includes a specific reset behavior ('use main to reset the start flow to main flow'), adding distinct purpose beyond the name. The endpoint and scope requirement further clarify its role, distinguishing it from sibling tools like the web chat widget variant.
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 a concrete usage instruction for resetting the flow ('use main to reset the start flow to main flow') and mentions the required authorization scope ('Requires the Manage Flow scope'). This gives context on when and how to use the tool, though it does not explicitly name alternatives like the web chat widget tool.
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 that the operation is a GET (read-only) and requires the 'Manage Team' scope, providing meaningful behavioral context. It does not describe response format or error cases, but for a simple config retrieval this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary purpose, and includes essential context (HTTP method and scope requirement) without any fluff. Every word earns its place.
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, parameterless GET tool, the description is complete: it states what is retrieved, the endpoint, and the required permission. It lacks an explicit explanation of the config's contents or response structure, but given the simplicity and absence of an output schema, the description is sufficient.
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 schema coverage is 100%, so the baseline is 4. The description correctly adds no parameter details since none exist, and no further semantics are needed.
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 'Get the config of Ainvented integration' with the specific verb 'Get' and resource 'config of Ainvented integration', distinguishing it from sibling integration tools by explicitly naming 'Ainvented'. The inclusion of the HTTP endpoint '[GET /integration/ainvented]' further reinforces the specific operation.
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 retrieving the Ainvented integration config and mentions the required 'Manage Team' scope, but does not explicitly contrast with alternatives like set_integration_ainvented or other get_integration_* tools. It provides context but no clear when-not 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds the auth requirement ('Requires the Manage Team scope'), which is useful, but it does not explain response shape, idempotency, or error behavior. The GET verb and 'Get' wording imply a safe read, but that is not explicitly stated.
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 packs the purpose, endpoint, and auth requirement without unnecessary words. It is immediately scannable and every element contributes to correct invocation.
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 zero-parameter GET tool, the description is mostly complete: it names the resource, includes the HTTP path, and gives the required scope. It could mention what the config contains or that it returns the integration settings, but the absence of an output schema does not seriously impair selection or invocation here.
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 there are no parameter semantics to explain. The schema is empty and the description does not need to compensate for undocumented inputs. The baseline of 4 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 states a specific verb-resource pair: 'Get the config of Meta Conversions Api integration'. It is easily distinguished from sibling tools like get_integration_shopify, set_integration_meta_conversions_api, and clear_integration_meta_conversions_api.
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 a clear prerequisite: 'Requires the Manage Team scope on the token.' It does not explicitly discuss when to use this versus set/clear alternatives, but the verb 'Get' and the presence of sibling set/clear tools imply read-only usage.
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?
There are no annotations, so the description carries the full burden. It discloses the HTTP method (GET) and the auth requirement, implying a read-only operation. However, it doesn't go beyond that to mention any potential side effects, rate limits, or response structure. For a simple read tool, this is adequate but minimal.
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 that includes the action, resource, HTTP endpoint, and auth requirement. No unnecessary words or repetition. It is easily scannable and informative.
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 (no parameters, no output schema), the description is mostly complete. It names the resource, action, endpoint, and auth need. It doesn't explain what the returned config contains, but for a straightforward GET config tool, this is sufficient and aligns with similar integration getters.
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 coverage is 100% (vacuously). The description adds no parameter details because none exist. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description doesn't need to compensate.
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 function: 'Get the config of OpenAi integration', naming the specific resource (OpenAI integration) and the action (get). It also includes the HTTP endpoint, which reinforces the read-only nature. This distinguishes it from sibling tools for other integrations (e.g., get_integration_dropi, set_integration_openai).
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 a clear usage context by specifying the required auth scope: 'Requires the "Manage Team" scope on the token.' This tells the agent when the tool can be used (with proper token). However, it does not explicitly mention alternatives or when not to use it, but the sibling set and verb 'get' imply it's for retrieval.
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 transparency burden. It discloses the HTTP method (GET) and the required OAuth scope, which are useful behavioral details. However, it does not describe what the configuration contains, how it is returned, or any potential limitations or rate limits. The description is not misleading but leaves the agent guessing about the response structure.
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, front-loaded with the core purpose ('Get the config...'), followed by the endpoint and scope requirement. Every element earns its place, with no wasted 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 zero-parameter GET tool, the description covers the essential points: what it retrieves, the endpoint, and the required scope. However, since there is no output schema, the description could have elaborated on the shape of the returned config (e.g., fields like bucket name, region, access keys). The gap is small because the purpose is simple and well stated, but not entirely complete.
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 baseline is 4. The description adds no parameter-related details, but there is nothing to add; the schema is empty and the description accurately reflects that no inputs are required.
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: fetching the configuration of the S3 Storage integration. It is specific about the resource (S3 Storage integration) and the action (get config), distinguishing it from sibling get_integration_* tools by explicitly naming the integration type. The inclusion of the endpoint and required scope further clarifies intent.
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 implies when to use the tool: whenever the S3 Storage integration config is needed. It also provides an explicit prerequisite (the 'Manage Team' scope), which helps the agent decide if it can invoke the tool. However, it does not explicitly contrast with alternatives like set_integration_s3storage or clear_integration_s3storage, so it lacks explicit exclusion guidance.
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 burden of disclosing behavior. It reveals the required scope ('Manage Team'), the API endpoint pattern, and the auth-type restriction. It does not detail side effects (e.g., overwriting existing keys) or error handling, but the provided context is substantial 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 that packs in the verb, resource, constraint, endpoint, and required scope. No wasted words, and all essential information is immediately visible.
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 relatively simple update tool, the description covers the key aspects: action, resource, auth requirement, and endpoint. It lacks details about return values or behavior on invalid input, but since no output schema exists and the operation is straightforward, this is acceptable. The main gap is the unclear role of the api_key parameter.
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 baseline is 3. The description does not add meaningful parameter-level detail beyond the schema; the api_key parameter's semantics remain somewhat ambiguous (the schema says 'property name is defined in the mini app'), and the description doesn't clarify whether this is a new value or a property reference.
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 ('Update the config'), the target resource ('Installed mini app'), and a key constraint ('only for the mini app with auth type apikey'). This distinguishes it from sibling tools like the list operation, 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?
Provides explicit usage constraints: limited to apikey-auth mini apps and requires the 'Manage Team' scope. This gives clear context for when to use the tool, though it does not explicitly name alternative tools or when not to use it beyond the stated restriction.
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 and does well by flagging the operation as DESTRUCTIVE and irreversible. It also discloses the confirm-flow requirement and the required scope, which are essential behavioral traits. Minor gap: it doesn't describe what happens after deletion (e.g., response format or side effects), but the safety-critical details are present.
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, well-structured sentence that front-loads the action and includes the endpoint, destructiveness, workflow, and scope. Every clause earns its place, with no redundancy or filler.
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 simple 2-parameter schema and lack of output schema, the description covers the essential context: what it does, that it's irreversible, how to handle confirmation, and required permissions. It could optionally note what kind of impact statement to expect, but it is largely complete for safe 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?
The input schema already provides 100% coverage: `productId` is described as 'Product Id' and `confirm` has a full explanation of the confirmation token flow. The description reinforces the call-without-confirm-first workflow but adds little parameter meaning beyond what the schema states, 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 opens with 'Delete product' and includes the exact endpoint, making the tool's purpose immediately clear. The resource (product) and action (delete) are specific, and the endpoint disambiguates it from sibling tools like shop_products_variants_delete.
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 usage instructions: call without `confirm` first to get an impact statement, then call with the token after human approval. It also notes the required 'Manage Team' scope. However, it does not explicitly contrast with alternatives or state when not to use the tool, so it misses the top score.
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 the HTTP method (GET), the endpoint, and the required OAuth scope, which are important behavioral/security traits. It does not describe return format or pagination behavior, but for a simple read-only list tool the provided context is substantial.
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, information-dense sentence. It states the action, endpoint, and auth requirement with no filler, making it easy to scan and understand.
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 list endpoint with optional filters and no output schema, the description covers the essential context: what it does, the endpoint, and required permissions. It does not describe the response fields, but that is not critical for a list operation. The explicit scope requirement and endpoint compensate for the lack of 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?
All three parameters (name, page, limit) have descriptions in the input schema, so schema coverage is 100%. The description adds no additional parameter-level information beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get list of labels' with the specific endpoint '/team/labels', identifying both the action and resource. The tool name 'cigchat_team_labels' and endpoint distinguish it from sibling tools for creating/deleting labels and from product tag list tools.
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 a clear prerequisite: 'Requires the Manage Team scope on the token,' which tells the agent when the tool can be used. It does not explicitly mention alternatives or when not to use it, but the endpoint and name make the context unambiguous.
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 full burden. It discloses irreversibility, the confirmation process, and required token scope. It does not describe the impact statement contents or post-delete behavior, but covers core behavioral safety.
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, dense sentence that front-loads the verb and resource, then states the endpoint, destructive warning, confirmation procedure, and scope requirement. Every clause earns its place.
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 destructive delete tool with no output schema, the description covers purpose, safety, confirmation flow, and auth requirement. It lacks detail about what the impact statement contains or the final response, but is largely complete 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 coverage is 100%, so baseline is 3. The schema already describes the 'confirm' token flow, and the description reinforces it but does not add substantial meaning beyond what the schema provides. listId and listItemId remain minimally described.
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 'delete a ticket' and includes the exact endpoint. It distinguishes this tool from siblings like update/create/list operations and clearly signals its destructive nature.
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 explicit usage guidance: call once without 'confirm' to get an impact statement first, and requires the 'Manage Team' scope. It does not explicitly mention alternatives, but the destructive confirmation flow is strongly contextual.
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 of behavioral disclosure. It names the required OAuth scope, which is a key behavioral constraint. It does not explicitly state that the operation is read-only, but the 'Get' verb conveys this. It stops short of describing response format or error behavior, but for a simple GET, the disclosed auth requirement adds meaningful 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 a single, compact sentence that conveys the operation, endpoint, and required scope. Every word is necessary; there is no redundancy or filler. It is appropriately front-loaded with the main action.
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 simplicity of the tool (one required parameter, no output schema), the description covers the essential elements: purpose, endpoint, and authentication. It does not detail the response structure, but for a list-fetching operation, the high-level description is adequate. A slightly richer description of what constitutes a 'field' could push it to 5, but the current level is sufficient.
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 for the single parameter 'listId', including a description. The tool description adds no additional information about the parameter beyond what the schema already provides. Per the baseline rule for high schema coverage, a score of 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 action ('Get list of ticket list fields') and includes the exact endpoint path, making the tool's purpose unambiguous. It distinguishes itself from sibling tools like 'cigchat_team_ticket_lists' and 'cigchat_team_ticket_lists_items' by specifying it retrieves fields for a specific list.
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 a clear prerequisite ('Requires the Manage Team scope on the token'), which is a useful usage condition. It does not explicitly name alternatives or exclusions, but the endpoint context implies when to use it (when you have a listId and need its fields). Thus it has clear context but no 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It discloses that the token maps to exactly one bot and that the call returns the account, but it does not explicitly state whether the operation is read-only or has side effects, though 'Verify' and 'GET' imply a safe read.
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?
Three short sentences plus an endpoint hint, all directly useful. No filler.
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?
For a simple, parameterless tool, the description covers the core purpose, usage timing, and a key invariant. It doesn't need to explain return structure beyond the account/bot identity.
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 provides complete coverage. The description doesn't need to explain parameters; baseline 4 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 tool verifies the configured API token and returns the account it belongs to, with an explicit [GET /me] reference. However, it does not distinguish this from the sibling tool cigchat_me, so while the purpose is specific, it misses 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: call first on 401 or to confirm the connected bot. It does not mention alternatives or when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It explicitly discloses that the operation is destructive and irreversible, explains the two-step confirmation workflow, and states the required OAuth scope. This is exemplary for a deletion 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 two sentences, front-loaded with the action, and every phrase adds value (destructiveness, confirmation step, scope). No wasted words.
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?
For a simple but destructive tool with no output schema, the description covers the essential context: what it does, how to use it safely, required permissions, and the confirmation flow. The agent can confidently invoke it correctly.
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%: both parameters (`var_ns` and `confirm`) are thoroughly described in the input schema. The description adds no additional semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete bot field') and includes the endpoint, making the purpose unambiguous. However, it does not differentiate from sibling tools like cigchat_flow_delete_bot_field_by_name, which likely serves a related but distinct purpose, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear, critical usage guideline: call once without `confirm` to obtain an impact statement before proceeding. It also notes the required 'Manage Flow' scope. Lacking explicit 'when not to use' or comparison to alternatives, it earns a 4 rather than 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?
No annotations are provided, so the description must carry the burden. It discloses the return content (toolsets, tool counts, enabled status) and implies a read-only operation via 'List.' However, it does not mention permissions, authentication needs, or potential data sensitivity, leaving some behavioral aspects unspecified.
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 long, front-loaded with the action and resource, and the second sentence provides a practical use case. No unnecessary words or repetition; it efficiently conveys both functionality and diagnostic purpose.
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 (zero parameters, no output schema), the description covers everything necessary: what is listed, the details returned, and a clear usage scenario. It is fully complete for an operation of this complexity, even without sibling comparisons or additional 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 zero parameters, and the input schema is empty. The description adds no parameter-level details, but none are needed. The description clarifies the tool's scope and output, providing sufficient semantic context for a parameterless operation.
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 clear resource ('toolset this server can expose') and specifies the exact output fields (tool count, enabled status). It distinguishes itself from other list tools by focusing on server-level toolsets rather than domain entities like tags or templates.
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 explicit guidance on when to use this tool: 'Use this when a tool you expected is missing — the toolset may be off.' It lacks when-not-to-use instructions or named alternatives, but the context is clear and actionable.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly declares the required 'Manage Team' scope, which is valuable auth context beyond the schema. It also implies a read-only operation via 'Get', though it does not detail return format or error behavior, which is acceptable for a simple single-id GET.
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 front-loads the purpose, then gives the endpoint and scope requirement. Every element earns its place with no redundancy or filler.
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?
For a tool with one parameter, no output schema, and no nested objects, the description is complete: it states the operation, the resource, the path, and the required scope. The agent has enough information to select and invoke the tool correctly without further clarification.
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 defines id with type and a description ('Agent Group Id'), which is 100% coverage. The description's endpoint [GET /team/agent-group/{id}] adds the context that the id is a path parameter, but it does not provide additional guidance on how to obtain or interpret the id (e.g., from a list tool). This meets the baseline for schema-covered parameters.
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 states a specific action ('Get') on a specific resource ('agent group information and members'), and the endpoint [GET /team/agent-group/{id}] reinforces this. This clearly distinguishes it from sibling tools like cigchat_team_agent_groups (which likely lists groups) and cigchat_team_create_agent_group (which creates).
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 implies usage: you need a specific agent group id and the 'Manage Team' scope on the token. It does not explicitly name alternatives or state 'use X instead', but the singular 'agent group' and the {id} endpoint make it clear this is for fetching one group's details, differentiating it from list/create/update/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 does so excellently. It warns that the tool sends to many subscribers at once, costs money, cannot be undone, requires confirmation, and needs a specific OAuth scope. This goes far beyond the schema.
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?
Three sentences pack purpose, danger, required workflow, and scope requirement with zero waste. Information is front-loaded and each clause earns its place.
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 high-impact, irreversible operation like this, the description conveys the essential safety protocol and prerequisites. It could mention the shape of the first response (e.g., audience size) explicitly, but the schema already covers parameters and the confirmation flow is clearly described.
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 already documents all parameters with detailed descriptions (100% coverage), so the description adds limited extra parameter semantics. The mention of the `confirm` flow reinforces the schema's explanation but doesn't introduce new meaning beyond it.
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 states a specific action ('Broadcast sub flow') and scope ('by segments'), clearly distinguishing it from sibling tools like cigchat_broadcast_by_tag and cigchat_broadcast_by_user_id. It also lists the available channel types, making the tool's purpose immediately clear.
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 gives detailed procedural guidance: call without `confirm` to get an audience estimate, show the human, then re-call with the confirmation token. It doesn't explicitly contrast with alternative broadcast tools, but the segment-based scope is clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full behavioral disclosure. It clearly flags the tool as DANGEROUS, states consequences (sends to many subscribers, costs money, irreversible), explains the confirmation mechanism, and lists the required 'Manage Flow' scope. This exceeds basic expectations.
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 with high information density: danger warning first, then the required two-step confirmation process, then the scope requirement. Every sentence earns its place; the endpoint in brackets is optional but harmless.
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 complexity (nested object, 6 params, no output schema, no annotations) the description focuses on the most critical aspects: safety, confirmation flow, and prerequisites. It doesn't describe the response format from the estimate call or edge cases, but the schema covers parameters, and the workflow is adequately specified for an agent to proceed.
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 descriptive parameter texts, so the baseline is 3. The description adds context for the `confirm` parameter's purpose in the workflow, but it doesn't provide additional semantics for parameters like `tags` or `max_per_minute` 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 uses a specific verb ('Broadcast'), a clear resource ('Facebook utility message template'), and a target ('by tags'), which precisely distinguishes it from sibling broadcast tools like broadcast_by_user_id or broadcast_whatsapp_template_by_tag. The inclusion of the POST path further eliminates ambiguity.
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 the critical usage workflow: call once without `confirm` to get an audience estimate, show it to a human, then re-call with the confirmation token. While it doesn't explicitly name alternative broadcast tools, the 'by tags' targeting makes the use case clear among the broadcast siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 goes well beyond the schema by revealing that the tool sends to many subscribers, costs money, cannot be undone, requires the 'Manage Flow' scope, and uses a confirmation-token audience-estimate flow. This is rich and honest 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 compact and front-loaded: it states the action, endpoint, and danger immediately, then gives the critical workflow and auth requirement. Every sentence earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested template object, dangerous broadcast) and lack of an output schema, the description covers the essential operational context: danger, confirmation flow, and required scope. It does not describe the exact estimate response format, but it provides enough for an agent to safely execute the intended two-step flow.
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 each parameter already has a meaningful description, so the baseline is 3. The description adds context about the 'confirm' parameter's role in the two-step approval flow, but it does not add substantive meaning to the other parameters (e.g., user_id_list, scheduled_time, facebook_utility_message_template) beyond what the schema already states.
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 action ('Broadcast'), the specific resource ('Facebook utility message template'), and the targeting scope ('by user ids'). It includes the exact endpoint, which removes ambiguity. The 'by user ids' qualifier also helps distinguish from tag-based or WhatsApp template broadcast siblings.
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 an explicit two-step usage workflow: call once without 'confirm' to get an audience estimate, show it to the human, then re-call with the confirmation token. It strongly warns about the action's dangerous nature (mass send, cost, irreversibility). However, it does not explicitly compare this tool to alternative broadcast 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behavioral traits: sends to many subscribers, costs money, cannot be undone, requires confirmation, and requires the 'Manage Flow' scope. This is unusually transparent for a dangerous mass-send 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 three sentences, all informative: purpose, danger warning, confirmation workflow. It's slightly run-on with comma-separated instructions, but every sentence earns its place and the key info is front-loaded.
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 complexity (6 params, nested object, dangerous side effects, no output schema), the description covers the purpose, danger, confirmation flow, auth scope, and template sourcing. It's enough for an agent to safely invoke it with human oversight.
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?
All 6 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds a pointer to /api/whatapp-template/list for finding template namespace/name/lang/params and clarifies the use_default_values vs params choice, but doesn't add substantial new 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 (broadcast), the resource (WhatsApp template), and the targeting method (by tags). This distinguishes it from sibling tools like broadcast_by_user_id or send_whatsapp_template, and the 'by tags' mechanism is explicit.
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 workflow for the confirm parameter: call without it to get audience estimate, show the human, then re-call with token. Also gives a hint on where to find template data and warns about danger. However, it doesn't explicitly state when NOT to use this vs a single-send tool, so no direct alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It explicitly warns 'DESTRUCTIVE: irreversible', states the required 'Manage Team' scope, and explains the confirmation flow. This exceeds typical descriptions for destructive operations.
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 cover purpose, destructive nature, confirmation workflow, and auth requirement. Every clause adds essential information with no redundancy or filler.
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 covers the critical context for a destructive operation: what it does, irreversibility, required scope, and confirmation protocol. It does not detail the impact statement's contents or post-clear state, but for a one-parameter destructive tool with a clear workflow, this is highly 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 coverage is 100% and the schema already explains the `confirm` parameter in detail, including the need to call without it first and show the human the impact statement. The description adds no new parameter semantics beyond the schema, aligning with the baseline 3 for high 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's action ('Clear the config of CaludeAi integration') with a specific verb and resource. It is easily distinguished from sibling tools like set_integration_calude (which configures) and get_integration_calude (which retrieves).
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 explicit usage guidance, especially the two-step confirmation process: call without `confirm` first, then pass the token after human approval. It does not explicitly name alternatives (e.g., use set_integration_calude to update), but the destructive context makes the intended use clear.
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 transparency burden. It explicitly flags the operation as 'DESTRUCTIVE: irreversible' and explains the two-step confirmation process to prevent accidental deletion. This is strong disclosure, though it doesn't mention the exact response shape or post-deletion 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 three compact sentences that immediately state the purpose, the destructive risk, and the required workflow. It is front-loaded and contains no filler.
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 destructive mutation with no output schema and no annotations, the description covers the essential context: what the tool does, the irreversible nature, the two-step confirmation protocol, and the required permission. It falls just short of perfect because it doesn't specify what the impact statement contains or what the final response looks like, but these are less critical given the clear workflow.
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 already describes both parameters (tagId and confirm) at 100% coverage, so the baseline is 3. The description adds meaningful workflow context by explaining that `confirm` is only obtained after an initial call and must be shown to a human for approval, which goes beyond the schema's static parameter description.
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 'Delete tag' and includes the exact DELETE endpoint, making the action and resource unmistakable. It clearly differentiates from sibling tools like cigchat_create_product_tag, cigchat_update_product_tag, and cigchat_get_product_tag.
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 a critical usage workflow: call without `confirm` first to receive an impact statement, then pass the returned token after human approval. It also states the required 'Manage Team' scope. It doesn't explicitly contrast with alternatives, but there is no alternative for this specific product-tag deletion, so the context is clear.
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?
No annotations are present, so the description carries the transparency burden. It discloses the key behavioral trait: the change is session-scoped ('for the rest of this session') and takes effect immediately. It does not discuss edge cases like idempotency or errors, but the core side effect is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and scope, followed by a practical usage hint. No filler or redundant restatement of the tool name.
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 one-parameter tool with no output schema and no annotations, the description covers what the tool does, its scope, and when to use it. It doesn't describe the return value, but for a side-effect-oriented enable operation this is a minor gap.
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 describes the toolset parameter as 'Toolset id, as returned by cigchat_list_toolsets.' The description reinforces this by saying to use it after listing, but adds no new parameter-level detail beyond what the schema provides.
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: 'Switch a toolset on for the rest of this session, making its tools available immediately.' It clearly distinguishes this from sibling tools by tying it to the companion list tool and the action of enabling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use after cigchat_list_toolsets shows the one you need is disabled.' This tells the agent exactly when to invoke the tool and names the prerequisite sibling tool, which is strong contextual guidance.
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 properly discloses destructive and irreversible behavior, the confirmation requirement, and auth scopes. This goes beyond the bare schema and gives the agent essential safety context, though it does not describe error cases or 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 three concise sentences, front-loaded with the core purpose, then the destructive warning, usage pattern, and auth requirement. No filler or redundancy—every sentence adds value.
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 two-parameter delete tool without an output schema, the description covers all essential operational aspects: purpose, destructive nature, required confirmation, and token scope. It is complete enough for an agent to use safely, though it could mention response expectations or error handling for extra polish.
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 already covers 100% of parameters, but the description adds workflow context around `confirm` ('Call once without `confirm`...') and explains the impact statement process, enhancing the parameter semantics beyond the schema descriptions.
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 'Delete a shortcut from the current flow' with a specific verb and resource, and the HTTP endpoint. It distinguishes from siblings like create/update shortcut by specifying the delete action and scope.
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 explicit usage guidance: the two-step confirm workflow ('Call once without `confirm` to get an impact statement first') and the required 'Manage Flow' scope. It lacks explicit alternatives or when-not-to-use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the operation is destructive and irreversible, requires the 'Manage Flow' scope, and instructs a two-step confirmation process. This is strong 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?
Two sentences pack the essential information: what it does, destructive warning, scope requirement, and confirmation workflow. Every word earns its place, 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 destructive tool with no output schema, the description covers the critical aspects: action, danger, prerequisites, and confirmation procedure. It omits details like the content of the impact statement or response format, but these are less critical and likely covered by the API's actual responses. Overall, it is adequate for an agent to use safely.
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 description clarifies that 'name' refers to the tag name, compensating for the schema's lack of description for that parameter. The 'confirm' parameter's purpose is explained in the schema, and the description reinforces the workflow. With 50% schema coverage, the description adds meaningful context for the undocumented 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 it deletes a tag by tag name, with a specific verb and resource. The name and description distinguish it from sibling tools like flow_delete_tag (which likely deletes by ID) and from subscriber tag removal tools.
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 a procedural guideline to call without confirm first to get an impact statement, which is useful. However, it does not explicitly compare against alternative deletion tools or state when to prefer this over flow_delete_tag, so usage differentiation 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the HTTP method (GET), endpoint path, and authorization scope requirement. It does not explicitly state that the operation is side-effect-free or describe the response shape, but the GET semantics and 'get config' phrasing provide reasonable behavioral clarity.
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 that states purpose, endpoint, and scope requirement. Every element carries useful information, with no redundancy or filler.
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 zero-parameter config retrieval tool with no output schema, the description provides the essential context: what is retrieved, the endpoint, and required permissions. It could mention the return format, but that is not critical for such a simple read operation.
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 input schema has zero parameters, so the baseline is 4. There are no parameter semantics to add, and the description doesn't need to compensate for any schema 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 a specific verb+resource construction: 'Get the config of Dropi integration', and reinforces it with the HTTP endpoint [GET /integration/dropi]. This clearly distinguishes it from sibling integration tools like set/clear or get_integration_* for other services.
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 implies the appropriate use case through 'Get' and explicitly states the required 'Manage Team' scope on the token, giving clear operational context. It does not explicitly contrast with set/clear integration alternatives, but the read-only verb and endpoint make the intended usage obvious.
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 takes on the full burden. It discloses the required 'Manage Team' scope and the date-specific protocol for api_key/token fields. It does not detail side effects, reversibility, or return values, but it does add meaningful behavioral context beyond just saying 'update'.
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 primary action, and every sentence adds value. It efficiently combines purpose, conditional guidance, and a prerequisite.
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, combined with the 100% schema coverage, sufficiently explains the tool's purpose and input requirements. It lacks return value or error handling information, but for a config update tool, the provided context is reasonably complete given the sibling tools and schema.
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?
Schema coverage is 100%, so baseline is 3. The description adds specific semantic guidance for api_key and token, clarifying exactly which values to use for new custom apps after 2026-02-01, which is more precise than the schema's general descriptions.
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 'Update the config of shopify integration' with a specific verb and resource. It distinguishes itself from sibling tools like get_integration_shopify (read) and clear_integration_shopify (delete), and from other set_integration_* tools by naming the platform.
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 conditional usage guidance: for new custom app integrations after 2026-02-01, specific field mappings are given. It also mentions a required scope. However, it does not explicitly state alternatives or when not to use this tool, 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, the description fully discloses destructive and irreversible behavior, the confirmation flow, and 'Manage Team' scope requirement. It stops short of detailing the impact statement's contents, but the schema's confirm parameter clarifies the token mechanism.
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 entire description is two sentences, front-loaded with the operation and endpoint, and each clause adds essential information (destructiveness, confirm workflow, scope). No wasted 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 destructive delete operation, the description gives the essential workflow (non-confirming call first), irreversibility warning, and auth prerequisite. Since there is no output schema, the lack of response details is acceptable, but the description could have briefly mentioned what the first call returns beyond an impact statement.
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 input schema already documents both parameters, and the description adds critical behavioral context for the confirm parameter—saying it should be omitted on the first call to receive an impact statement. This goes beyond the schema's static field description.
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?
States 'Delete vendor' with the exact REST endpoint, making the action and resource unmistakable. This clearly distinguishes it from sibling tools for creating, reading, or updating product vendors.
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 to call once without confirm to get an impact statement before confirming, and warns of irreversibility. It also names the required auth scope, though it does not mention alternative tools for non-destructive modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly flags 'DESTRUCTIVE: irreversible', explains the two-step confirmation flow, and discloses the required scope. This is strong transparency 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 compact: purpose, destructive warning, and usage in about 30 words. It is front-loaded with the verb and resource, then warning, then actionable steps. No redundant phrases.
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 destructive delete without annotations or output schema, the description covers essential aspects: irreversible nature, confirmation workflow, and scope requirement. It lacks details about the impact statement contents or error cases, but is sufficiently complete for safe 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 50% (only `confirm` has a description). The description adds context for `confirm` (call without it first, get impact statement), but `id` semantics are left to inference from tool name and endpoint. It partially compensates but not fully for the undocumented `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 states 'Delete label' with the specific endpoint '/team/delete-label', making the verb and resource clear. It also distinguishes from sibling 'cigchat_team_delete_label_by_name' by implicitly targeting deletion by ID (as required by the schema).
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 explicit usage guidance: 'Call once without `confirm` to get an impact statement first' and requires the 'Manage Team' scope. It doesn't explicitly compare with alternatives or state exclusions, but the confirmation protocol is clearly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly warns 'DANGEROUS: sends to many subscribers at once, costs money and cannot be undone' and explains the confirmation token mechanism to prevent accidental sends. Also discloses the required auth scope.
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?
Three sentences: purpose/types, danger warning, and workflow. Front-loaded with the core action, no redundant details. Every sentence earns its place; the inclusion of the HTTP endpoint is minor but not distracting.
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?
For a dangerous tool with 10 parameters, no annotations, and no output schema, the description plus rich schema covers all essential details. The two-step confirmation process and irreversible-cost warning are critical and explicitly included, making the tool safe and usable.
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 covers all 10 parameters with descriptions (100% coverage), so the baseline is 3. The description adds some context for `confirm` and `type`, but largely mirrors schema descriptions without providing significant new parameter-level meaning.
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 'Broadcast sub flow by tags' with a specific verb and resource, and lists available types (EMAIL, SMS, WHATSAPP_TEMPLATE, FACEBOOK_NOTIFICATION). This distinguishes it from sibling broadcast tools that operate by segment, user ID, or template type.
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 two-step workflow: call without `confirm` for an audience estimate, show the human, then re-call with the confirmation token. Also states the required 'Manage Flow' scope. Does not explicitly name alternative tools, but the tag-based targeting is clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly labels the tool as DANGEROUS, states it sends to many subscribers at once, costs money, cannot be undone, requires a two-step confirmation, and demands the 'Manage Flow' scope. This is exceptional transparency for a high-impact 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 two sentences and tightly packed: the first states action and types, the second bundles danger, cost, irreversibility, confirmation flow, and scope. It includes the endpoint as useful context and contains no filler or redundant text.
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?
For a high-risk broadcast tool with no output schema and no annotations, the description covers all essential decision-making information: what it does, target audience, channels, financial/irreversibility warning, confirmation protocol, and auth requirement. Combined with a rich 100%-coverage schema, nothing critical is missing.
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 baseline is 3. The description does reinforce the two-step `confirm` workflow and lists the allowed `type` values, but the schema already fully explains each parameter with examples and descriptions. The added value over the schema is minimal, so a 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 starts with a specific verb+resource ('Broadcast sub flow') and the targeting dimension ('by user ids'), then enumerates allowed channel types. This clearly distinguishes it from sibling broadcast/send tools that target by segment, tag, list, or single user (e.g., cigchat_broadcast_by_segment, cigchat_send_subflow_by_user_id).
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 gives explicit usage guidance: call once without `confirm` to get an audience estimate, present it to the human, then re-call with the token. It also warns about costs, irreversibility, and the required scope. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls just 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It clearly warns that this operation is DANGEROUS, sends to many subscribers at once, costs money, and cannot be undone. It also discloses the required 'Manage Flow' scope and explains the two-step confirmation process, giving the agent all necessary safety information.
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 concise, front-loaded with the core purpose, and includes no redundant information. Each sentence earns its place: the first explains what it does and the types, the second covers the danger and the critical confirmation workflow, and the third states the required scope. It is well-structured for quick parsing.
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?
Despite the tool's complexity and the absence of an output schema, the description covers all critical operational aspects: the target selection (user ns list), the available message types, the dangerous and irreversible nature, the necessary confirmation flow, and the required OAuth scope. It also leaves schedule and rate-limit parameters to the schema, which is sufficient for an agent to use the tool correctly.
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 provides 100% coverage, with every parameter having a clear description (e.g., `confirm` explains the token, `user_ns_list` explains comma-separated format, `max_per_minute` explains rate limit). The description adds minimal extra semantics beyond re-stating the confirmation flow and types, so it does not need to compensate. 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 function: 'Broadcast sub flow by user ns list', with a specific verb (broadcast), resource (sub flow), and target list (user ns). It also lists the available types (EMAIL, SMS, WHATSAPP_TEMPLATE, FACEBOOK_NOTIFICATION), which immediately distinguishes it from other broadcast tools like broadcast_by_segment or broadcast_by_tag.
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 explicit usage guidance: it tells the agent to first call without `confirm` to get an audience estimate, show it to the human, then re-call with the confirmation token. It also warns about the dangerous nature and required scope. However, it does not explicitly compare to alternative broadcast tools (e.g., when to use broadcast_by_segment instead), though the name and description make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly flags the tool as DESTRUCTIVE: irreversible, requires a specific scope, and describes the confirmation process to prevent accidental deletion. This goes beyond basic safety labeling and gives the agent essential operational 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, tightly worded sentence that front-loads the core purpose, then clearly states the destructive nature, the confirmation flow, and the required scope. No unnecessary words or repetition.
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 (one optional parameter, no output schema), the description covers all necessary context: what it does, its destructive/irreversible nature, the required scope, and the two-step confirmation workflow. The schema handles the parameter details. The sibling context includes clear counterparts for other integrations, making this description sufficient for an agent to select and use the tool correctly.
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 already fully describes the `confirm` parameter, including its purpose and the required workflow. The description's mention of calling without `confirm` reinforces the schema but adds no new parameter information. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Clear the config of Ainvented integration', using a specific verb and resource. It is easily distinguished from sibling tools like get_integration_ainvented and set_integration_ainvented, as well as clear_integration tools for other integrations.
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 two-step usage: call without `confirm` to get an impact statement, then pass the confirmation token after human approval. Also notes the required 'Manage Team' scope. Does not explicitly mention alternatives like 'use get_integration_ainvented to view config or set_integration_ainvented to update', but the usage flow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive nature ('DESTRUCTIVE: irreversible'), the two-step confirmation behavior, and required permissions. It explains the 'confirm' parameter's role and the impact statement flow, providing transparency about what happens before the actual deletion.
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 concise and front-loaded with the core purpose and danger warning. It includes the HTTP method, destructive flag, confirmation workflow, and scope requirement in just two sentences, with no wasted words.
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?
For a single-parameter tool with no output schema and no annotations, the description covers all necessary contexts: what it does, how destructive it is, the exact invocation sequence, and the required permission. It is complete enough for an agent to 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'confirm' is already well-described in the schema. The description adds workflow context ('Call once without confirm...') but does not introduce additional parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear the config of OpenAi integration', with a specific verb ('Clear') and resource ('config of OpenAi integration'). It is easily distinguished from sibling tools like get_integration_openai and set_integration_openai, and the HTTP method [DELETE] reinforces the intent.
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 usage guidance for the destructive workflow: 'Call once without confirm to get an impact statement first' and then pass the token once approved. It also specifies the required 'Manage Team' scope. However, it does not explicitly name alternatives or state when not to use the tool, though the sibling names make this inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It openly warns that the operation is DESTRUCTIVE and irreversible, mandates a two-step confirmation workflow, and specifies the required OAuth scope. This gives agents the key safety and prerequisite information needed to invoke it responsibly.
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?
Three short sentences, front-loaded with the destructive warning and endpoint; all content is necessary, no filler.
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?
For a destructive single-parameter tool with no output schema, the description is complete: purpose, confirmation workflow, irreversibility, and auth scope are all covered. The agent knows exactly how to perform a safe delete.
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 covers 100% of parameters, and the confirm schema already explains the confirmation-token workflow. The description's mention of calling without confirm first reinforces but does not add substantially new parameter semantics, so 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 clearly states the action ('Clear the config of XAi integration') and explicitly identifies the resource, distinguishing it from sibling integration clear/set/get tools. The appended HTTP method and destructive label reinforce specificity.
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 gives explicit operational guidance: call once without confirm to obtain an impact statement, then pass the confirmation token after human approval. It also states the required 'Manage Team' scope, but does not explicitly address when not to use it or name alternatives for inspecting the config before deletion.
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?
The description discloses the tool's behavior by stating it returns variable keys, namespace, and language, and implies a read-only lookup. However, it does not cover edge cases like behavior when the template name is not found, error handling, or authentication requirements, which would be useful given no annotations are 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 two sentences with an endpoint reference, front-loading the primary purpose and then providing usage guidance. Every sentence contributes value with no filler.
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?
For a simple lookup tool with one parameter and no output schema, the description adequately explains the return contents (variable keys, namespace, language) and the critical usage context. It is complete for an agent to 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage with the 'name' parameter described as 'Exact template name as approved in cig.chat.' The description's mention of lookup 'by name' adds no additional semantics beyond what the schema provides, 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 the tool looks up a Facebook utility message template by name and returns the variable keys, namespace, and language. This specific verb+resource distinguishes it from sibling describe tools like cigchat_describe_whatsapp_template and send/broadcast tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this before cigchat_send_fb_utility_template or cigchat_broadcast_fb_utility_template_by_tag, explaining that incorrect or missing keys lead to rejection and expensive broadcast failures. This provides clear when-to-use guidance with named alternatives.
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 burden of disclosing behavior. It clearly frames the operation as a lookup with no side effects, and adds context about template rejection and broadcast cost. It does not explicitly state edge cases (e.g., template not found), but for a simple read operation this is adequate 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?
Two sentences: the first states the tool's purpose and output, the second provides essential usage guidance with a consequence. No redundancy, no filler, perfectly front-loaded.
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?
The tool is simple (1 param, no output schema, no annotations), and the description fully covers what the tool does, what it returns, when to use it, and why it matters. It also includes the API endpoint for reference. Nothing critical is missing.
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 covers 100% of the single parameter with a clear description ('Exact template name as approved in cig.chat'). The description adds no new parameter semantics beyond 'by name', but since schema coverage is complete, 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 uses a specific verb ('Look up') and resource ('WhatsApp template by name'), clearly stating what is returned (variable keys, namespace, language). It distinguishes itself from sibling send/broadcast tools by focusing on lookup rather than sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call this tool BEFORE sending or broadcasting templates, names the sibling tools (cigchat_send_whatsapp_template, cigchat_broadcast_whatsapp_template_by_tag), and explains the consequence of not doing so (rejection, expensive for broadcasts). This is exemplary when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 clearly discloses that the operation is DESTRUCTIVE and irreversible, requires a confirmation flow, and needs a specific OAuth scope. This is thorough behavioral disclosure 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?
Two dense, front-loaded sentences with no filler. It covers destruction, confirmation flow, and auth requirements efficiently. Every word earns its place.
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 complexity of a destructive operation with a confirmation mechanism, the description covers all critical aspects: irreversible nature, the need for a confirmation token, and authentication scope. No output schema exists, but the description adequately sets expectations for the two-step flow. This is sufficient for an agent to execute correctly.
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 50%: `confirm` has a description in the schema, but `name` does not. The description adds context about the two-step confirmation flow but does not explain what `name` refers to. Since the tool name implies it's the template name, the absence is partially mitigated. The description partially compensates for the schema gap but not fully.
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: 'Delete Facebook utility message template' with the endpoint. It differentiates from sibling tools like create, list, sync, and send by focusing on deletion and adding the destructive warning. The verb-resource pair 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: call without `confirm` first to get an impact statement, then pass the token only after approval. Also mentions the required 'Manage Flow' scope. It doesn't explicitly mention alternatives, but for a destructive delete operation, the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently warns that the operation is 'DESTRUCTIVE: irreversible', states the required permission scope, and explains the confirmation flow. This is exemplary 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?
Two dense sentences: the first states the purpose and endpoint; the second packs the destructive warning, confirmation workflow, and permission requirement. No wasted words, clearly front-loaded.
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?
For a simple delete operation with only two parameters and no output schema, the description covers the essential aspects: what it does, that it's irreversible, the prerequisite scope, and the required confirmation sequence. It is complete for the tool's complexity.
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% for both parameters, so the baseline is 3. The description adds context about 'confirm' but this is largely redundant with the schema's description. The 'id' parameter is only hinted at by the phrase 'from the current flow' and not explicitly described, so no additional boost beyond baseline.
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 states a specific verb and resource: 'Delete a closing note from the current flow', with the HTTP endpoint also provided. This clearly distinguishes it from sibling tools like cigchat_flow_create_closing_note, cigchat_flow_update_closing_note, and cigchat_get_closing_note.
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 usage guidance: 'Call once without `confirm` to get an impact statement first' and the required 'Manage Flow' scope. This is a clear explanation of the two-step invocation pattern. However, it does not explicitly compare against alternative actions (e.g., update instead of delete), so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries full responsibility. It clearly marks 'DESTRUCTIVE: irreversible', explains the confirmation token mechanism, and specifies the required OAuth scope. This thoroughly discloses the tool's safety profile and behavioral requirements.
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?
Three short sentences efficiently convey the purpose, destructive nature, usage workflow, and auth requirement. Information is front-loaded and there is no redundant phrasing—every sentence adds value.
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?
For a simple 2-parameter destructive operation with no output schema, the description fully covers the action, danger, confirmation workflow, and required scope. The schema handles parameter semantics comprehensively, so nothing essential is missing.
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 descriptions are already very detailed (100% coverage), fully explaining the `confirm` token purpose and the `sub_flow_ns` naming flexibility. The description itself adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Delete sub flow', a specific verb-resource pair that clearly states the action. The HTTP path '[DELETE /flow/delete-sub-flow]' further reinforces the purpose, and it is distinct from sibling tools like list_subflows or send_subflow.
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 an explicit two-step usage workflow: call without `confirm` to receive an impact statement, then pass the token after human approval. It also mentions the required 'Manage Flow' scope. However, it does not explicitly state when not to use this tool or mention alternative deletion methods, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and handles it well. It explicitly flags the operation as DESTRUCTIVE and irreversible, requires a vulnerable scope, and discloses the two-step confirmation flow. This gives the agent essential safety information beyond what the schema provides.
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, information-dense sentence that front-loads the verb and resource. It packs in the destructive nature, the confirmation workflow, and scope requirement without unnecessary verbosity. Every clause adds value.
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?
Despite the absence of an output schema, the description communicates the critical workflow: destructive irreversible operation, mandatory two-step confirmation, and required scope. This is sufficient for an agent to correctly invoke the tool and handle the safety mechanism. No essential context is missing.
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 50%. The optional `confirm` parameter is well explained in the schema, and the description adds meaningful context about the confirmation token and impact statement. The required `name` parameter lacks explicit schema description, but the tool name and description make its meaning clear. The description partially compensates for the coverage 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 tool name and description combine to clearly state the action: 'Delete user field by name'. The endpoint is included, which reinforces specificity. This distinguishes it from siblings like cigchat_flow_delete_user_field, which likely operate by ID rather than by name.
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 procedural guidance: call once without `confirm` to get an impact statement, then pass the confirmation token after human approval. It also states the required 'Manage Flow' scope. However, it does not explicitly mention alternatives (e.g., using `cigchat_flow_delete_user_field` when an ID is available), so it falls short of full alternative guidance.
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 the authentication requirement (Manage Flow scope) and the HTTP method (GET), implying a safe read operation. It does not describe response format or rate limits, but for a zero-parameter getter, the disclosed scope and endpoint provide 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that packs in the purpose, available values, endpoint, and scope. Every word is informative, with no filler. It is well-structured and immediately front-loads the core function.
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?
For a zero-parameter GET tool with no output schema, this description is complete. It covers what the tool does, the domain values, the exact endpoint, and the required scope. The lack of response format details is acceptable given the simplicity, and the description provides all necessary context for selection and invocation.
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 baseline is 4 per the rubric. The description adds value by listing the valid AI provider values, which helps the agent interpret the return value even though no parameters exist. There is no schema to compensate for, and the description enriches understanding of the data domain.
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: to get the default AI provider and model. It lists the available provider values (openai, deepseek, etc.) and includes the REST endpoint, which distinguishes it from the sibling setter tool and other provider-related tools. The verb 'get' and resource 'default ai provider and model' are 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to retrieve the default AI provider and model. It also specifies the required 'Manage Flow' scope, indicating a prerequisite. It does not explicitly mention alternatives (e.g., 'use set_default_ai_provider to change it'), but the GET semantics and sibling tool names make the intended usage obvious.
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 burden of behavioral disclosure. It reveals that this is a read-only GET operation through the endpoint, and it discloses the required authorization scope ('Manage Team'), which is essential for invocation. It does not explicitly state that no changes are made, but the GET method strongly implies it, and the scope requirement adds valuable operational 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 a single, concise sentence that leads with the action ('Get the config'), specifies the resource, includes the endpoint, and states the required scope. There is no wasted verbiage 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?
For a simple GET tool with no parameters, the description is complete: it names the resource, gives the endpoint, and notes the permission requirement. The return value is implied by 'config', and there is no output schema to complicate matters. This provides sufficient context for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially fully covered. Per the guidelines, a tool with 0 parameters receives a baseline score of 4. The description adds no parameter-specific details, but none are needed.
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 'Get the config of CaludeAi integration' with the HTTP endpoint '[GET /integration/claude]', specifying both the action and the exact resource. The tool name and description unambiguously distinguish this from sibling get_integration_* tools for other services like Dropi, OpenAI, or Shopify.
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 for when to use this tool: when you need the Claude AI integration configuration. It also notes a prerequisite ('Requires the "Manage Team" scope on the token'), which guides usage. However, it does not explicitly mention alternatives like set_integration_calude or when not to use it, so it lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It clearly warns 'DESTRUCTIVE: irreversible,' explains the two-step confirmation protocol, and states the required OAuth scope, which are critical behavioral disclosures for a delete operation.
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 concise, front-loaded sentences with no wasted words. It immediately states the verb and resource, then the critical warnings and usage protocol.
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 that this is a destructive delete tool with a well-described confirm flow, scope requirement, and clear endpoint, the description is complete enough for an agent to invoke it safely without additional context.
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 thoroughly documents both parameters (codeId and confirm), including the confirmation flow, and schema coverage is 100%. The description adds little beyond what the schema provides, only reinforcing the destructive context, so it meets the baseline.
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 ('Delete discount code') with the specific resource and endpoint, distinguishing it from sibling tools like create/update/get_info and delete_by_code by using the codeId path. This 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit instructions to call without confirm first for an impact statement and then pass the token after human approval, which is critical for destructive actions. However, it doesn't explicitly mention alternatives like delete_by_code, so it lacks full alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states the operation is destructive and irreversible, instructs the two-step confirmation flow (call without confirm first), and names the required token scope. This goes beyond just describing the action and properly warns the agent of the risk.
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 concise, front-loaded sentences that cover purpose, danger, workflow, and permission. Every sentence contributes essential information, and there is no unnecessary verbiage.
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 simple two-parameter schema and absence of an output schema, the description provides all necessary context: what is deleted, irreversibility, confirmation sequence, and required scope. It is complete enough for an agent to safely invoke the tool correctly.
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 'id' and 'confirm' already described in the input schema. The description adds little beyond what the schema provides; the 'call once without confirm' advice mainly reinforces the confirm parameter's behavior rather than introducing new parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
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 begins with the specific verb+resource 'Delete agent group' and includes the HTTP endpoint, making the tool's purpose immediately clear. This distinguishes it from sibling tools like cigchat_team_create_agent_group and cigchat_team_update_agent_group, which modify rather than delete.
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 gives clear usage context: it is a destructive irreversible operation that requires a preliminary call without 'confirm' to receive an impact statement, and it mandates the 'Manage Team' scope. However, it does not explicitly mention alternative update/unassign tools or state when not to use this tool, so it falls short of a perfect score.
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 and effectively does so: it flags the operation as DESTRUCTIVE and irreversible, discloses the impact-statement-first requirement, and notes the required permission scope. It could detail what the impact statement contains, but the current coverage is strong for safety awareness.
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 sentences, with the core action front-loaded ('Delete label by label name') followed by essential warnings and usage steps. Every clause earns its place; 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?
The tool is a destructive delete with a confirmation mechanism, and the description covers the necessary context: the operation, the irreversibility, the two-step confirmation, and the required scope. With no output schema and only two simple parameters, this is sufficient for an agent to use the tool correctly.
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 only describes the 'confirm' parameter; 'name' lacks a description (50% coverage). The tool description compensates by clarifying that name is the label name used for deletion, and it reinforces the confirm parameter's purpose through the call-first-then-confirm guidance. This adds meaningful meaning beyond the bare 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 states a specific verb ('Delete'), resource ('label'), and method ('by label name'), which clearly distinguishes it from the sibling tool cigchat_team_delete_label (likely delete by ID). It also includes the HTTP DELETE endpoint, leaving no ambiguity about the operation.
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 clear guidance on the two-step confirmation flow: call without 'confirm' first to get an impact statement, then with the token after approval. Also states the required 'Manage Team' scope. It does not explicitly list when to prefer this over alternates, but the 'by name' phrasing serves as a differentiator.
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 discloses that the Authorization header is handled automatically and warns that this tool lacks the safety checks of dedicated tools, implying potential risk. It also provides the base URL and API reference. However, it does not detail error handling, response format, or side-effect risks beyond the safety caveat.
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 four sentences, front-loaded with purpose ('Call any cig.chat API endpoint directly'), and every sentence adds value: usage guidance, safety warning, auth note, and API reference. 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 generic API call tool with no output schema and no annotations, the description provides comprehensive context: purpose, when to use, auth handling, token safety, base URL, and reference link. It doesn't explicitly state that response structure varies by endpoint, but the API reference link covers that gap. Missing explicit error-handling behavior, but it is a generic wrapper.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter-related context: 'never put a token in the arguments' applies to body/query, and the base URL helps interpret the path parameter. This goes beyond the schema's basic descriptions.
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 explicitly states 'Call any cig.chat API endpoint directly, for endpoints without a dedicated tool.' It clearly identifies the verb (call), resource (cig.chat API endpoints), and scope (endpoints without dedicated tools). It also distinguishes itself from siblings by advising 'Prefer the dedicated tool when one exists.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call any cig.chat API endpoint directly, for endpoints without a dedicated tool.' It also explains why to prefer dedicated tools: 'it has a validated schema and safety checks that this does not.' Additional usage rules include never putting a token in the arguments and the base URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 the irreversible destructive nature, the two-step confirmation process, and the required authorization scope—all critical behavioral traits beyond the schema.
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?
Three sentences, each informative: action+endpoint, destructive warning, and usage instruction. No redundancy; every sentence earns its place.
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 destructive delete tool, the description covers the essential workflow (impact statement, confirmation token, scope). It does not detail the content of the impact statement or post-deletion response, but given no output schema and the simplicity of the operation, it is largely complete.
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?
Schema already describes both parameters (id and confirm) with 100% coverage. However, the description adds meaningful context for `confirm` by explaining it is a token from a prior response and that using it after human approval is required, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete embedding', a clear verb+resource pairing, and reinforces it with the exact DELETE endpoint. This directly distinguishes it from sibling tools like cigchat_openai_embeddings_create or cigchat_openai_embeddings_update.
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 instructs to call once without `confirm` to receive an impact statement, and states the required 'Manage Team' scope. It does not explicitly mention when to use this over alternatives, but the destructive nature and confirmation flow provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 excels: it explicitly labels the operation DESTRUCTIVE and irreversible, discloses the confirmation flow requirement, and states the required authentication scope. This is exemplary transparency 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?
Two sentences deliver all essential info: action, endpoint, destructive warning, confirmation process, and scope requirement. No filler, perfectly front-loaded with the most important warning.
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?
Despite no output schema, the description covers the destructive nature, confirmation flow, and permission requirement, which are the main concerns for a delete tool. It does not describe the final success response, but the impact statement is mentioned, making it sufficiently complete for its complexity.
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 description adds critical meaning to the confirm parameter by explaining the two-step flow: first call omits it to receive an impact statement, then only pass the token after human approval. Although the schema already describes confirm well, the description reinforces the workflow and makes the parameter's purpose unambiguous.
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: 'Delete Whatsapp template' with the exact endpoint. This specific verb+resource combination distinguishes it from sibling tools like cigchat_whatsapp_template_create, list, and sync.
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 gives explicit step-by-step guidance: call once without confirm to get an impact statement, then pass the token after approval. It also notes the required 'Manage Flow' scope. No alternatives are mentioned, but none exist for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully owns behavioral disclosure. It clearly labels the operation as 'DESTRUCTIVE: irreversible', explains the two-step confirmation mechanism, and states the auth requirement. This is exemplary for a destructive 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?
Three sentences, each adding distinct value: purpose, destructive warning, and usage instructions. The front-loaded danger warning is highly effective, and there is no redundant text.
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 no annotations and no output schema, the description covers all essential context: what it does, that it's irreversible, how to invoke safely, and what permissions are required. It is fully self-sufficient for safe usage.
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 single 'confirm' parameter is fully described in the schema, so the description adds little beyond referencing the flow. Schema coverage is 100%, meeting the baseline. The description's mention of 'confirm' reinforces but doesn't extend the schema 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 a specific verb-resource pair: 'Clear the config of Dropi integration'. This clearly distinguishes it from sibling tools like cigchat_clear_integration_shopify or cigchat_set_integration_dropi. The HTTP DELETE method adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the caller to invoke without 'confirm' first to receive an impact statement, and only then pass the token after human approval. Also specifies the required auth scope ('Manage Team'). This is strong when-to-use/sequence guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive and irreversible nature ('DESTRUCTIVE: irreversible'), the confirmation workflow, and the required auth scope. This is strong behavioral transparency beyond what schema or annotations would provide.
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?
Three concise sentences cover purpose, danger/confirmation workflow, and auth requirement—each earning its place. No fluff or redundancy, fully front-loaded.
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?
For a destructive operation with one optional param and no output schema, the description covers the action, impact, confirmation pattern, and prerequisites. It is sufficiently complete for an agent to invoke correctly without further info.
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 sole parameter `confirm` is already well described in the schema (100% coverage). The description adds meaningful context by explaining the two-step call sequence, which clarifies when and how to use the parameter. This goes beyond a simple schema repetition.
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 starts with a specific verb and resource: 'Clear the config of S3 Storage integration', clearly distinguishing it from sibling get/set integration tools. The explicit HTTP DELETE reference further reinforces the precise action.
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 step-by-step usage guidance: call without `confirm` first to get an impact statement, then pass the confirmation token after approval. It also states the required 'Manage Team' scope. Does not explicitly compare against alternative tools, but the destructive nature makes the workflow guidance highly relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description takes full responsibility. It clearly labels the operation as 'DESTRUCTIVE: irreversible', calls out the need for a confirmation step, and states the required token scope. This is strong disclosure of behavioral traits.
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 compact (two sentences) and front-loads the most critical information—purpose and destructiveness—while preserving essential usage/safety details.
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 a single parameter and no output schema, the description covers the key aspects: what it does, when to use it (with confirmation flow), and prerequisites (scope). It fully supports safe 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?
While the schema already describes the `confirm` parameter, the description adds important context about the two-step invocation pattern—calling without it first to get an impact statement, then passing the token after approval. This enriches the semantics 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 explicitly states 'Clear the config of shopify integration' with the HTTP DELETE endpoint, clearly identifying the action and resource. This distinguishes it from sibling tools like get_integration_shopify and set_integration_shopify.
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 usage instructions: 'Call once without `confirm` to get an impact statement first' and requires 'Manage Team' scope. However, it doesn't explicitly compare against alternative tools (e.g., other clear_integration_* tools) other than implying the target resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses that the operation is destructive and irreversible, outlines the confirmation workflow, and specifies the required auth scope. This is comprehensive behavioral disclosure 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 two sentences: the first states the action and the destructive irreversible nature; the second covers the confirmation workflow and required scope. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and the presence of a confirmation parameter, the description fully covers what an agent needs: the action, the safety protocol, the required scope, and the parameter flow. The lack of an output schema is acceptable because the tool's response is an impact statement, which the description implicitly covers via the confirmation workflow.
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 description of `confirm` already explains the two-step confirmation process in detail. The tool description adds no new parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear the config of WooCommerce integration') and includes the HTTP endpoint. It distinguishes from siblings like set_integration_woocommerce and get_integration_woocommerce through the verb 'clear' and the resource 'config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and how-to-use guidance: call once without `confirm` to get an impact statement, then pass the confirm token. It also states the required token scope ('Manage Team'). This clearly instructs the agent on the safe invocation sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive and irreversible nature, the two-step confirmation workflow, and the required scope. This is critical behavioral context beyond the schema.
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 action and destructive warning, followed by the step-by-step confirmation guidance and scope requirement. No wasted words.
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?
For a simple delete-by-name tool, the description covers the essential workflow, safety warning, and authorization requirement. No output schema is needed for a delete operation, and the sibling list provides related tools for listing/checking bot fields.
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 description clarifies that `name` refers to the bot field name, compensating for the schema's missing description on that parameter. It also reinforces the `confirm` workflow described in the schema, though the schema already covered `confirm` well.
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 phrase 'Delete bot field by name' clearly identifies the action (delete), resource (bot field), and identifier (by name). It also distinguishes from sibling tools like cigchat_flow_delete_bot_field (likely by ID) and other *_by_name delete tools for different resources.
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 gives explicit usage guidance: call once without `confirm` to get an impact statement, then pass the token after human approval. It also states the required 'Manage Flow' scope, but does not explicitly compare to alternative delete-by-ID or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly warns 'DESTRUCTIVE: irreversible', explains the two-step confirmation flow, and discloses the required auth scope. This is thorough for a delete operation.
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?
A single sentence packs the purpose, endpoint, destructive warning, usage guidance, and auth requirement with no redundant words. Front-loaded with the key action.
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?
For a destructive mutation with no output schema, the description covers purpose, safety, auth, and the required confirmation sequence. It is complete enough for an agent to correctly invoke and handle the tool, especially with detailed schema descriptions.
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?
Schema coverage is 100% for all three parameters, so the baseline is 3. The description adds value by explaining the confirm parameter's role ('Call once without confirm to get an impact statement first') and the endpoint path clarifies productId/variantId usage.
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 'Delete product variant', a specific verb+resource pairing, and includes the full endpoint path. This clearly distinguishes it from sibling tools like create/update/get_info for variants.
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 usage context: call once without 'confirm' to get an impact statement, then pass the token after approval. It also states the required 'Manage Team' scope. However, it does not explicitly mention alternatives or when not to use, though the tool name and sibling set make this obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 boldly states 'DANGEROUS: sends to many subscribers at once, costs money and cannot be undone', and explains the confirmation token mechanism. It also discloses the required 'Manage Flow' scope. This is exemplary behavioral transparency for a high-risk 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 three sentences yet packs in the purpose, the template parameter source, the confirmation protocol, the danger warning, and the auth scope. Every sentence earns its place and the most critical information is front-loaded. No 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?
For a complex, dangerous action with a nested template object, no annotations, and no output schema, this description is remarkably complete. It covers the safety-critical confirmation flow, the source for parameter values, and the required scope. The schema handles the rest (scheduling, rate limit, ID format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaningful semantics beyond the structured definitions. It tells the agent to source template details from a specific endpoint and clarifies the choice between use_default_values and params. This helps the agent correctly populate the nested wa_template object, which is the most complex part of 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 begins with a specific verb+resource: 'Broadcast whatsapp template by user ids'. This clearly distinguishes it from sibling broadcast tools like broadcast_by_segment, broadcast_by_tag, and send_whatsapp_template_by_user_id. The endpoint is also included, reinforcing the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent where to find the namespace, name, lang, and params (from /api/whatapp-template/list), and advises using either use_default_values or params for the wa_template. It also provides a precise two-step confirmation workflow (call without confirm, show estimate, re-call with token), which is critical for a dangerous bulk operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description clearly discloses the destructive and irreversible nature of the tool, and explains the two-step confirmation mechanism. It also states the required 'Manage Team' scope on the token, providing essential behavioral and auth context beyond the schema.
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 concise and front-loaded: it begins with the action and endpoint, immediately warns of destructive behavior, then gives clear step-by-step usage instructions and a scope requirement. Every sentence adds essential information without 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?
For a destructive delete operation with no output schema, the description fully explains the confirmation workflow, the irreversible nature, and the required scope. It answers the key questions an agent would have: what it does, how to proceed safely, and what credentials are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with clear descriptions, but the description adds crucial semantics: it explains that 'confirm' is the token from a prior requires_confirmation response and that calling without it returns an impact statement. This goes beyond the schema's basic field descriptions.
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 starts with the specific verb 'Delete type' and the exact endpoint path, clearly identifying the resource being deleted. It also distinguishes itself from sibling tools by including the 'DESTRUCTIVE: irreversible' warning and the confirmation flow, which is specific to this delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: call once without 'confirm' to get an impact statement, then pass the confirmation token only after human approval. This directly instructs when and how to use the tool, and implicitly distinguishes it from read-only or non-destructive sibling tools.
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:

[![cig-chat-mcp MCP server](https://glama.ai/mcp/servers/eyalbarash/cig-chat-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eyalbarash/cig-chat-mcp)

Score Badge

Copy to your README.md:

[![cig-chat-mcp MCP server](https://glama.ai/mcp/servers/eyalbarash/cig-chat-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eyalbarash/cig-chat-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/eyalbarash/cig-chat-mcp'

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