Provides tools for administering Zendesk configuration, including full CRUD on triggers, automations, macros, views, SLA policies, groups, ticket fields, ticket forms, and webhooks; read-only audit logs; and read-only inventory of account settings, installed apps, brands, agent roles, tags, and locales.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zendesk Admin MCP Server list all active triggers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local MCP server for Zendesk admin/config work — the companion to @sniebauer/zendesk-mcp (day-to-day support).
54 tools: full CRUD on triggers, automations, macros, views, SLA policies, groups, ticket fields, ticket forms, and webhooks; a read-only audit log; and a read-only inventory of account settings, installed apps, brands, agent roles, tags, and locales.
Destructive and live-routing writes (deletes, and updates to triggers/automations/SLAs/trigger-order) are guarded with a preview-then-confirm step.
Open your Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add a zendesk-admin entry under mcpServers:
{
"mcpServers": {
"zendesk-admin": {
"command": "npx",
"args": ["-y", "@sniebauer/zendesk-admin-mcp"]
}
}
}Capture credentials (skip if you already ran setup for @sniebauer/zendesk-mcp — they share the same config file):
npx -y @sniebauer/zendesk-admin-mcp setupYou'll be prompted for your Zendesk subdomain, email, and an API token (generate at https://<your-subdomain>.zendesk.com/admin/apps-integrations/apis/api-tokens). Stored at ~/.config/zendesk-mcp/config.json (mode 0600).
Restart Claude Desktop.
Same, but the config file is ~/.claude.json.
Related MCP server: Zendesk MCP Server
This package reads the same ~/.config/zendesk-mcp/config.json as @sniebauer/zendesk-mcp. Run setup once (from either package) and both servers are authenticated. Env vars (ZENDESK_SUBDOMAIN / ZENDESK_EMAIL / ZENDESK_API_TOKEN) override the file.
Heads up: a Zendesk API token carries your full account permissions. This server can modify live business rules. The
require_confirmguard (below) is the safety net — there is no read-only token scope in Zendesk.
require_confirm guardGuarded operations — every delete, every update to triggers / automations / SLA policies, and zda_reorder_triggers — do not execute on the first call. Instead they return the object's current state (and, for updates, the proposed change) and ask you to re-invoke with require_confirm: true. This forces a deliberate two-step on anything that can break live ticket flow.
Creates and updates to lower-risk objects (macros, views, groups, fields, forms, webhooks) execute directly.
Business rules — full CRUD (list / get / create / update / delete each)
zda_*_trigger(s) · zda_*_automation(s) · zda_*_macro(s) · zda_*_view(s) · zda_*_sla_policy/policies
zda_reorder_triggers — reorder trigger evaluation precedence (guarded)
Ticketing config — full CRUD
zda_*_group(s) · zda_*_ticket_field(s) · zda_*_ticket_form(s) · zda_*_webhook(s)
Audit (read-only, Enterprise)
zda_audit_logs — who changed what, filterable by type/actor/time
zda_audit_logs_for_object — all events for one object
Inventory (read-only)
zda_account_settings · zda_list_apps · zda_list_brands · zda_list_agent_roles · zda_list_tags · zda_list_locales
npm test # unit tests (schemas, error wrapper, guard, audit URL builder)
npm run smoke # reads-only end-to-end (requires credentials)Guarded writes need two calls. First call previews; second call with require_confirm: true applies.
Audit logs need Zendesk Enterprise. Non-Enterprise accounts get a 403 with a clear message.
Conditions DSL is passthrough. Create/update accept the object's full structure (e.g. conditions: {all,any}); Zendesk validates semantics.
Credentials precedence. Env vars override the shared config file.
Smoke test is reads-only. It never creates or deletes config.
MIT — see LICENSE.
Read the Zendesk account settings (branding, tickets, agents, etc.). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Read-only', which implies safety but lacks detail on return format, potential size, or any side effects. For a read operation, more transparency about what 'account settings' entails (e.g., a single object, multiple fields) would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient. Every word adds value, specifying the resource and its read-only nature. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable overview of what the tool does and what it covers (branding, tickets, agents, etc.). It could mention that it returns all account settings in one go, but the listed examples give adequate context. The simplicity of the tool (no params) makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. According to guidelines, 0 parameters yields a baseline of 4. The description's mention of specific included items provides some context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the Zendesk account settings' with specific examples like branding, tickets, agents. This distinguishes it from sibling tools that read specific resources (e.g., zda_get_group, zda_list_views). The verb 'Read' matches its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or situations where other tools like zda_list_brands or zda_list_ticket_fields might be more appropriate. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Zendesk audit log (who changed what, when). Filter by source_type, actor_id, and time window. Read-only. Requires Zendesk Enterprise. Use this to verify a change landed or to detect config drift.
| Name | Required | Description | Default |
|---|---|---|---|
| actor_id | No | Filter by the acting user's ID. | |
| source_type | No | Filter by object type, e.g. 'trigger', 'automation', 'macro', 'view', 'user', 'group'. | |
| created_after | No | ISO 8601 timestamp; only events at/after this time. | |
| created_before | No | ISO 8601 timestamp; upper bound of a time range. Must be paired with created_after — Zendesk's audit filter is a range, so created_before alone is ignored as an upper bound. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only and requires Zendesk Enterprise. With no annotations provided, this adds necessary behavioral context. However, it does not mention pagination behavior, rate limits, or error handling, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description adequately covers the tool's purpose, filtering options, read-only nature, and enterprise requirement. It is missing an explanation of the return format (e.g., the fields in the audit log entries), which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description paraphrases the filtering parameters (source_type, actor_id, time window) but does not add significant new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the Zendesk audit log' with a specific verb and resource. It also mentions filtering capabilities. However, it does not explicitly differentiate from the sibling tool 'zda_audit_logs_for_object', which likely has a similar but more focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific use cases: 'verify a change landed or to detect config drift.' It states the tool is read-only, implying safe usage. However, it does not explicitly mention when not to use it or alternatives (e.g., when to use zda_audit_logs_for_object).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all audit-log events for a specific object (by source_type + source_id). Read-only. Requires Zendesk Enterprise. The natural 'did my change land / what happened to this trigger' lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | Yes | The object's ID. | |
| source_type | Yes | Object type, e.g. 'trigger', 'automation', 'macro', 'view'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of transparency. It declares the tool is 'Read-only' and requires Enterprise, which is good. However, it lacks details about response format, pagination, rate limits, or other behavioral traits, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence covers purpose, read-only nature, and requirement; second sentence provides a relatable use case. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should at least hint at what the response contains. It does not describe the events' structure, limiting the agent's ability to interpret results. Adequate for a simple read operation but incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description only reiterates the schema's parameter examples ('trigger', 'automation') without adding new semantic meaning. Baseline 3 is appropriate as the schema already sufficiently documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'audit-log events for a specific object', and the method of specifying via source_type and source_id. It distinguishes from the sibling tool 'zda_audit_logs' by being object-specific and provides a concrete use case ('did my change land').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires Zendesk Enterprise' and gives a contextual usage hint ('natural lookup after change'). It implicitly differentiates from general audit logs but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk automation. Common fields: title, conditions {all,any}, actions, active. Automations are time-based.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'time-based' but does not disclose side effects, permissions, validation, or what happens on creation. Minimal behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. No extraneous words, but could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about the return value, error handling, permissions, or validation rules. For a creation tool with nested objects and no output schema, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the 'data' parameter. The tool description lists common fields (title, conditions, actions, active) but these are already implied by the schema. No additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk automation,' providing a specific verb and resource. It adds context about time-based nature, but does not explicitly differentiate from sibling create tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like triggers or macros. The description lacks context for decision-making between similar creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk group. Common fields: name, description, default, is_public.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as permissions, side effects, or rate limits. It only says 'Create a new Zendesk group' and lists common fields, omitting any cautionary or authorization context, which is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence plus a comma-separated list of common fields. It is front-loaded with the main purpose. Slight improvement could be bullet-pointing the fields, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and simple input, the description covers the basics but misses details like required fields within 'data', the response format (e.g., created group object), and any constraints. For a create tool, this leaves some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a generic 'data' object with 100% description coverage, but the description adds value by listing specific group fields ('name, description, default, is_public'), providing domain context beyond the schema. This compensates for the schema's genericity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk group' with a specific verb and resource, distinguishing it from sibling tools that operate on different Zendesk objects (e.g., automations, macros).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating groups but provides no explicit guidance on when to use it versus alternatives, prerequisites, or when not to use it. Since it is the only create-group tool, ambiguity is low, but proactive guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk macro. Common fields: title, actions, active, restriction.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states creation and lists fields, omitting side effects, permissions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus a field list) and front-loads the action. Could benefit from slightly more structure but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple creation tool, the description is adequate but lacks details on success responses, error handling, or required permissions. The high schema coverage partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the 'data' parameter. The tool description adds value by listing common fields like title, actions, active, restriction, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk macro' with a specific verb and resource. Listing common fields adds clarity but does not differentiate from sibling create tools like zda_create_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include many other create tools, but no context is provided for selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk sla_policy. Common fields: title, description, filter {all,any}, policy_metrics (priority/metric/target/business_hours).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only lists common fields but does not discuss mutation effects, required permissions, idempotency, side effects, or constraints (e.g., duplicate creation behavior). This is insufficient for an agent to assess risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose, the second lists common fields. No filler or redundancy. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists common fields but omits details about return values (no output schema), error handling, or validation rules. Given the tool's complexity (nested object parameter), additional context on expected response or failure modes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'data' parameter generically, but the tool description adds specific field names relevant to sla_policies (title, description, filter, policy_metrics). This goes beyond the schema, giving the agent actionable details for constructing the payload. Schema coverage is 100%, but description still adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk sla_policy', specifying the verb and resource. Among sibling create tools (e.g., create_automation, create_group), it distinctly identifies the SLA policy resource, allowing an agent to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating an SLA policy but provides no explicit context on when to use this tool versus alternatives (e.g., update_sla_policy, delete_sla_policy) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk ticket_field. Common fields: type, title, description, required, active, custom_field_options (for dropdowns).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states creation but does not mention idempotency (e.g., if duplicate fields cause errors), required permissions, or any side effects. The description is insufficient for an agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence followed by a short list of common fields. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple structure (one parameter, no output schema), the description covers purpose and parameter guidance. It lacks details on response format or error handling, but for a basic create tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, but the description adds semantic value by listing common fields (type, title, description, required, active, custom_field_options for dropdowns). This helps the agent understand what to include in the data object, going beyond the generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk ticket_field' with a specific verb and resource. It lists common fields, providing context. The tool is easily distinguishable from sibling create tools (e.g., zda_create_automation, zda_create_group) by its explicit reference to ticket_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a ticket field but does not provide explicit when-to-use guidance, exclusions (e.g., when to use update instead), or prerequisites. It lacks alternatives or conditions, making the usage context clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk ticket_form. Common fields: name, display_name, ticket_field_ids (ordered), active, end_user_visible.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a write operation (creation) but lacks details on authentication, rate limits, error handling, or side effects like whether existing forms are overwritten, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a list of common fields, with no wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and parameter structure, it omits return values, error behavior, and does not fully explain the nested object complexity (e.g., conditions, actions). This leaves gaps for a create operation, though the input schema description partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description adds crucial meaning beyond the raw schema: it explains the 'data' parameter is passthrough, lists example fields, and warns against wrapping in an envelope. The tool description also lists common fields, fully compensating for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk ticket_form' with a specific verb and resource, and lists common fields, distinguishing it from sibling create tools for other objects like automations or views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., update or other create tools), nor does it mention prerequisites or exclusion scenarios, offering only the basic context of creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk trigger. Common fields: title, conditions {all,any}, actions, active, category_id.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Create a new trigger' and lists fields, without explaining side effects, permissions, or what happens on success (no output schema). Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus a list) with no superfluous content. It efficiently conveys the purpose and key fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers acceptable fields but omits details like return value (no output schema), default values, or error conditions. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by listing commonly used fields (title, conditions, actions, active, category_id) and hinting at their structure (e.g., 'conditions {all,any}'). This helps compensate for the open-ended 'data' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk trigger' with a specific verb and resource. It lists common fields, which aids understanding. However, it does not differentiate from sibling create tools (e.g., zda_create_automation) beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling creation tools, explicit advice on when to choose this one would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk view. Common fields: title, conditions {all,any}, execution (columns/sorting), active, restriction.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as required permissions, side effects, rate limits, or safety. It only lists common fields, lacking transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a bullet list of common fields. Extremely concise, front-loaded with the verb and resource, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects (conditions, execution) and no output schema, the description is incomplete. It lists common fields but omits details on structure, required fields, or return values. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a generic description for the 'data' parameter. The description adds specific field names (title, conditions, execution, active, restriction), providing meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new Zendesk view' with 'Common fields' listed, making the verb and resource clear. It distinguishes from sibling tools like zda_create_ticket_field or zda_create_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other creation tools). No when-not or context for selection. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Zendesk webhook. Common fields: name, endpoint, http_method, request_format, status, subscriptions, authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action and lists common fields, omitting details like authentication requirements, rate limits, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with exactly two sentences. It is front-loaded with the primary action, and every word contributes meaning. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more completeness. It lists common fields but does not indicate which are required, what the response looks like, or any constraints. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already describes the 'data' parameter. The description adds value by listing specific common fields (name, endpoint, etc.) that should be included, which the generic schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Zendesk webhook', specifying the verb and resource. It lists common fields, which helps differentiate from other create tools, though it does not explicitly distinguish from siblings like zda_create_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., other create tools, or when to use update instead). There is no mention of prerequisites or context for webhook creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk automation. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the guarded preview-then-confirm behavior, indicating the first call is a safe read and the second is a destructive write. Lacks details on permanence or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second explains critical usage pattern. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description explains the safe usage pattern well. Could mention whether deletion is reversible or affects related objects, but the guarded approach addresses major concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to require_confirm by tying it to the preview/apply workflow, beyond the schema's default-only description. The id parameter is already well-described in the schema, so minimal added value there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'Zendesk automation', distinguishing it from sibling tools like zda_get_automation or zda_update_automation. The guarded preview behavior further clarifies its unique action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step usage pattern: preview without require_confirm, then apply with require_confirm: true. Provides clear context when to use each call but does not compare with non-deletion alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk group. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the guarded (two-step) pattern, explaining that the first call is a preview and the second is destructive. This is key behavioral information. However, it omits side effects, permissions, or what happens if the group has dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. First sentence states the action, second explains the guarded usage pattern. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (delete with preview), the description covers the main usage flow. However, it lacks details on what the preview returns (likely the group object) and error conditions. For a guarded tool, knowing the preview output is valuable. Still, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only id described). The description fully explains both parameters: 'id' implicitly identifies the group, and 'require_confirm' is described in the guarded pattern as the flag to switch from preview to apply. This compensates for the missing schema description of require_confirm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Zendesk group', which is a specific verb and resource. It distinguishes from sibling tools like create, update, get, and list by specifying delete. The guarded preview pattern adds nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: call without require_confirm to preview, then with require_confirm: true to apply. This tells the agent when to use each mode. However, it does not exclude other approaches (e.g., deactivation) or compare to other delete tools for different objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk macro. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses the guarded delete behavior: preview then confirm. This is beyond typical for deletion tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence states purpose, second explains usage pattern. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema, the description explains the process adequately. Could mention success/error indicators but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to both parameters: 'require_confirm' is explained in the guarded pattern. Schema covers only 'id' with generic description, so description compensates with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for deleting a Zendesk macro, using specific verb+resource. It distinguishes from sibling tools like zda_get_macro and zda_update_macro by specifying deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on the two-step process: preview without require_confirm, then apply with require_confirm:true. It implies when to use each mode, though explicit when-not-to-use is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk sla_policy. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
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 transparency. It explains the guard mechanism (preview vs actual delete), which is a key behavioral trait. However, it does not disclose what the preview returns, what happens on successful deletion, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the purpose, second explains the guarded usage. Both sentences are essential and there is no verbose or redundant content. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and no output schema. The description covers purpose and guard mechanism, but it does not explain return values (e.g., what the preview returns, what a successful delete returns) or error behavior (e.g., invalid id). For a delete operation, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only 'id' has a description ('Numeric object ID'). The description compensates for 'require_confirm' by explaining its role in the guarded workflow (preview vs apply). This adds semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Zendesk sla_policy', specifying the verb (delete) and resource (sla_policy). This distinguishes it from sibling tools like create, update, and get for SLA policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the guarded two-step process: first call without require_confirm to preview, then re-call with require_confirm: true to apply. This tells the agent how to use the tool safely, though it doesn't explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk ticket_field. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It discloses the guarded delete behavior, including the preview step before actual deletion, which informs the agent about the tool's safety mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. The purpose is front-loaded, and the guarded pattern is explained efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's behavior for agent selection, but lacks information about return values or success indicators, which would be helpful given no output schema. For a delete tool, it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the require_confirm parameter's role in the guarded pattern, adding context beyond the schema's default value. The id parameter is briefly described in the schema, but the description compensates for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Delete a Zendesk ticket_field' which clearly states the action and resource. It distinguishes from sibling delete tools by specifying the exact entity type (ticket_field vs automation, group, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the guarded two-step process: first call without require_confirm to preview, then with require_confirm: true to apply. It does not explicitly mention when not to use, but the pattern is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk ticket_form. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly discloses the guarded (preview-then-confirm) behavior. However, it omits details like required permissions, what happens upon successful deletion, or side effects on related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous words. The first sentence states purpose, the second explains the guarded pattern. Efficiently packs necessary information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description could mention return value (e.g., preview object or success confirmation). It also lacks context on error scenarios or prerequisites. Given the simple two-parameter schema, it reasonably covers the core behavior but misses minor details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (id described). The description adds meaning by explaining that require_confirm controls whether to preview or delete, and that calling without it shows what would be deleted. This compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Zendesk ticket_form' with a specific verb and resource. The guarded pattern (preview before delete) distinguishes it from sibling delete tools that may not have such a mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit steps: first call without require_confirm to preview, then with require_confirm: true to apply. It does not compare with sibling delete tools or state when not to use, but the two-step process is clearly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk trigger. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description alone must convey behavior. It explains the guarded deletion pattern (preview then apply), which is critical. However, it does not mention permissions, error handling, or reversal options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second explains guarded usage. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no output schema or annotations, the description covers the essential guard mechanism. It could mention expected outcomes or failure modes, but is adequate given the simple parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (id and require_confirm). The description adds meaning to require_confirm by detailing its role in the guarded flow. The id parameter's semantics are not expanded, but the schema already describes it as 'Numeric object ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Zendesk trigger', specifying the verb 'Delete' and the resource 'Zendesk trigger'. This distinguishes it from sibling tools like zda_delete_automation or zda_delete_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit two-step usage: preview without require_confirm, then confirm with require_confirm: true. This guides the agent on the correct invocation sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk view. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| require_confirm | No |
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 preview-then-delete behavior via the 'GUARDED' mechanism, which is a key behavioral trait. However, it does not mention irreversibility, permissions, or error conditions, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the primary action (delete) and immediately providing the critical usage pattern. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a delete operation (no output schema), the description covers the core behavior and the guarded approach. It omits details about what happens after delete (e.g., immediate effect, cascading) and error handling, but the preview pattern reduces the need for such details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (id has a description). The description adds semantic value by explaining that require_confirm controls preview vs. delete, which is not evident from the schema alone. For id, it relies on the schema, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'Zendesk view'. It distinguishes this tool from sibling tools like zda_get_view and zda_list_views by focusing on deletion, and the 'GUARDED' prefix emphasizes the deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage pattern: call without require_confirm to preview, then call with require_confirm:true to apply. This guides the agent on how to safely use the tool, though it doesn't explicitly state when not to use it or compare with other delete tools, which are differentiated by the object type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Zendesk webhook. GUARDED: call without require_confirm to preview the object that would be deleted; re-call with require_confirm: true to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | String object ID | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the guarded nature and the two-step process, which is crucial for a delete tool. However, it does not specify error behavior or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: first states purpose, second explains guarded usage. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a delete tool, explaining the guarded process. It does not describe return values or error handling, but the complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the require_confirm parameter's role (preview vs. delete), adding meaning beyond the schema. The id parameter only has a basic schema description, but overall compensation for 50% coverage is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a Zendesk webhook,' providing a clear action and resource. Among sibling tools like zda_delete_automation, it is uniquely identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: call without require_confirm to preview, then with require_confirm: true to apply. This explains the guarded workflow but does not discuss alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk automation by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It does not mention that the tool is read-only, any authentication requirements, side effects, or rate limits. The description only states the operation without addressing safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no extraneous information. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with one parameter and no output schema, the description is complete. It specifies the input (by ID) and the result (including its full definition). No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described as 'Numeric object ID'. The description adds 'by ID' but does not provide additional semantics beyond what is in the schema. According to guidelines, baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch a single Zendesk automation by ID', which specifies the verb (Fetch), resource (automation), and method (by ID). This distinguishes it from sibling tools like zda_list_automations (list all) and zda_create_automation (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a specific automation by ID, which is clear from the tool name and sibling context. However, it does not explicitly state when not to use it or mention alternatives, but for a simple fetch tool, the implicit guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk group by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
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 mentions 'including its full definition' but does not disclose behavioral traits such as authentication requirements, rate limits, or typical response structure. More detail is needed for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. No wasted words; every part is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with one parameter and no output schema, the description is adequately complete. It specifies the input and the output concept ('full definition'), though more detail on the return value would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'id' parameter ('Numeric object ID'). The tool description adds no extra meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single Zendesk group by ID', which is a specific verb and resource. It distinguishes from sibling tools like 'zda_list_groups' that fetch multiple groups, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single group by ID. While it does not explicitly mention when not to use or alternatives, the context from siblings (e.g., 'zda_list_groups') provides implicit differentiation, so it is clear enough but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk macro by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a read operation ('Fetch') with no destructive side effects. No annotations exist, so the description carries the burden; it is truthful but does not disclose any specific authentication or rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words, efficiently conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description covers the core function and hints at the response ('full definition'). It does not document error scenarios or prerequisites, but this is acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is fully described in the schema ('Numeric object ID'), and the description merely repeats 'by ID' without adding new semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fetch a single Zendesk macro by ID' and distinguishes it from siblings like 'zda_list_macros' (which retrieves multiple) and 'zda_update_macro' (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single macro's full definition is needed, contrasting with 'zda_list_macros'. However, it lacks explicit when-not-to-use or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk sla_policy by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention read-only nature, authentication requirements, rate limits, or error conditions. The return format is described as 'full definition' but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words with no redundant information. It is front-loaded and efficiently communicates the core action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is mostly adequate but lacks details about the return structure, especially given the absence of an output schema. It states 'including its full definition' which is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'id', which is described as 'Numeric object ID'. The description adds no further meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('Zendesk sla_policy'), the method ('by ID'), and the scope ('including its full definition'). It differentiates from sibling tools like list or create by specifying retrieval of a single item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (needing a specific SLA policy by ID) but does not explicitly mention when not to use or provide alternatives. Sibling tools like zda_list_sla_policies exist but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk ticket_field by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
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 that it fetches the full definition, but does not disclose behavior for invalid/missing IDs, authorization requirements, or whether it is read-only. This is insufficient for a tool 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and resource. No unnecessary words, and it is front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is incomplete. It does not explain what happens on success or error, nor any limitations (e.g., rate limits, required permissions). For a tool with this complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only parameter 'id' is described with type, exclusivity). The description adds minimal value beyond stating 'by ID', which aligns with the schema. Baseline 3 is appropriate as the schema already documents the parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('a single Zendesk ticket_field'), and the identifier ('by ID'). It also specifies that it returns the full definition, which distinguishes it from sibling list tools like zda_list_ticket_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use or avoid this tool, nor does it mention alternatives. However, for a simple get-by-ID tool, the intended use is implicit: use when you have a specific ID and need details. No misguidance, but no proactive guidance either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk ticket_form by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes a read-only fetch operation, which is non-destructive, but does not explicitly state safety (e.g., 'read-only', 'no side effects'). Lacks details on permissions or rate limits, though not critical for a simple get.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is complete: it specifies what is fetched (single ticket form by ID) and what is returned (full definition). No further context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter ('id') with schema description 'Numeric object ID'. Tool description adds no additional meaning beyond schema. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'fetch', resource 'ticket_form', and scope 'by ID'. Includes additional detail 'including its full definition'. Distinguishes from sibling list tools (e.g., zda_list_ticket_forms) and other get tools (e.g., zda_get_ticket_field) by specifying the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when a specific ticket form is needed by ID, but does not explicitly state when to use or not use this tool versus alternatives (e.g., list or search tools). No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk trigger by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description states it fetches a trigger, implying a read-only operation, but does not confirm idempotency, permissions, or error behavior. Minimal transparency for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is mostly complete. It could hint at return format or common fields, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'id' described as 'Numeric object ID'. The description adds context that the ID identifies a single trigger, but no additional format or source information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'a single Zendesk trigger by ID', distinguishing it from list tools like zda_list_triggers. It adds 'including its full definition', specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when retrieving a specific trigger's full details, but does not explicitly state when to use this vs. list_triggers or other get_* tools. No contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk view by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool fetches data and returns full definition, but fails to mention that it's read-only, what happens on invalid ID, rate limits, or authentication requirements. For a simple fetch, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence that front-loads the action and resource. Every word is informative; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description adequately covers the core purpose. 'Full definition' is somewhat vague, but for a get-by-ID tool, it communicates the value. Could be slightly improved by specifying the response includes the view's conditions, columns, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('Numeric object ID'). The tool description adds 'including its full definition', which hints at response richness but doesn't directly enhance the parameter meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('single Zendesk view'), and the key ('by ID'), explicitly noting the output includes full definition. This distinguishes it from siblings like zda_list_views (list only) and zda_create_view (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The purpose implies usage when a specific view's full details are needed, but lacks comparison with alternatives (e.g., 'use zda_list_views for summaries'). Meets minimum viability but could be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Zendesk webhook by ID, including its full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | String object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it fetches data with no mention of read-only nature, authentication requirements, or side effects. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without waste. It is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is fairly complete. It covers what the tool does and the key parameter. However, with no annotations, a brief mention of read-only nature would have been beneficial, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'id' parameter, which is already described as 'String object ID'. The description adds no further meaning beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single Zendesk webhook by ID, with its full definition. It uses a specific verb ('Fetch') and resource ('Zendesk webhook'), distinguishing it from sibling list/create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. While the purpose implies use when needing details of a specific webhook, no alternatives or exclusions are mentioned, making it adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the custom agent roles defined on this account (Enterprise). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 adds 'Read-only' which is helpful, but lacks details on pagination, rate limits, or error conditions. For a 0-parameter list operation, the behavior is straightforward, but more context could 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that efficiently conveys the purpose and a key behavioral trait. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the essential purpose and side effects (read-only). It does not mention output format, but that is not strictly required. It is adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not add parameter semantics because there are none. Baseline for 0 parameters is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'custom agent roles', and scopes it to 'on this account (Enterprise)'. It also explicitly marks it as 'Read-only'. This effectively distinguishes it from other list 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is a safe read operation but provides no explicit guidance on when to use this tool versus other list tools (e.g., zda_list_groups, zda_list_macros). The resource name itself distinguishes, but no direct alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed Zendesk Marketplace apps (installations) and their settings. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only,' disclosing the tool's non-destructive nature. With no annotations provided, this disclosure adds necessary behavioral context, though it could mention other traits like whether results are paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence covering purpose and behavior. No redundant information, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately covers purpose and read-only behavior. However, it doesn't specify the output structure or any limitations, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description correctly omits parameter details. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List installed Zendesk Marketplace apps (installations) and their settings.' This is a specific verb+resource combination that distinguishes it from sibling list tools which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when/when-not instructions are given, the context is clear: this is the only tool for listing apps among siblings. The read-only nature and zero parameters imply simple usage without prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk automations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation, but no annotations are provided. It does not disclose pagination, response size limits, or whether only active automations are returned. For a simple list tool, some behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and no annotations, the description is minimal. For a list tool, it could mention typical response fields (e.g., ID, name, status) or pagination behavior, but it provides only the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. The baseline score of 4 applies as the description correctly indicates no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'automations'. It is specific about the scope ('all Zendesk automations'), but does not differentiate from sibling list tools for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like zda_get_automation for a specific automation. No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the brands configured on this Zendesk account. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description explicitly states 'Read-only', indicating it does not modify data. This is a valuable behavioral disclosure for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. No wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is complete. It clearly states what it does and its read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'brands', with context 'configured on this Zendesk account'. It distinguishes from siblings which list different entities like groups or automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or alternatives are stated, the tool name and description make it obvious that it is for listing brands, and siblings are for different entities. Implicit guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk groups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states 'List all Zendesk groups' but does not mention pagination, authentication requirements, or return format. For a simple list tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and lack of output schema, the description is minimally complete for a list tool. However, it lacks context on what the list contains (e.g., group names, IDs) or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all Zendesk groups, distinguishing it from sibling tools that list other resources like automations or macros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as zda_get_group for individual groups or zda_create_group for creating groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the locales available/enabled on this account. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must convey behavior. It states 'Read-only' but does not disclose return format, pagination, or any limitations. For a read operation, basic behavioral details are lacking beyond safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus 'Read-only'. Every word serves a purpose. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate but minimal. It lacks details on return format, error handling, or account scope. For a simple list tool, it is passable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds no parameter info, but the baseline for zero parameters is 4. No additional value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List', the resource 'locales', and scope 'available/enabled on this account'. The tool name and description align, and it is distinct from sibling list tools by resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage through 'List' and 'Read-only' but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. Since it has no parameters, usage is straightforward, but context could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk macros.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states 'list all Zendesk macros' without mentioning that it is a read-only operation, auth requirements, rate limits, or any potential side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose. No unnecessary words. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool, the description is sufficient. However, it omits mention of pagination or return format, which could be helpful. Still, context signals (no output schema) reduce burden. Score 4 reflects minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. Baseline score of 4 applies as description adds no parameter info, but none is needed. No contradiction or gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all Zendesk macros, a distinct operation from sibling tools like create, delete, or get specific macro. Verb+resource combination is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. The name and sibling context imply it is for enumerating all macros, but the description does not elaborate on scenarios or compare with similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk sla_policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'List all' without mentioning if the tool is read-only, whether it returns a paginated list, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is appropriately concise for a simple list tool, though it could have added brief guidance on usage or return value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the basic purpose. However, it lacks details about what the response contains (e.g., list of SLA policy objects) and whether any pagination or filtering exists. It is minimally complete but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially covered (100%). The description adds no parameter-specific info, but none is needed. Per guidelines, baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Zendesk sla_policies' clearly states the action (list) and the resource (sla_policies). It distinguishes itself from sibling tools like zda_get_sla_policy (single policy) and other list tools (e.g., zda_list_automations) by specifying the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as zda_get_sla_policy for a single policy or other list tools. There is no mention of when not to use it or any prerequisites, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most-used tags across the account. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only', which is a key behavioral trait. Without annotations, it covers the core transparency needed. However, it does not disclose potential details like sorting or limitations, but the tool is simple with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the primary action. Every word serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and no output schema, the description adequately covers the tool's purpose and behavior. It could hint at output contents, but not essential for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds no parameter information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List' and the resource 'most-used tags across the account'. It clearly distinguishes from sibling tools, as no other tag-listing tool exists among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not provide explicit when-to-use or when-not-to-use guidance or mention alternatives. The uniqueness among siblings partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk ticket_fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It does not mention authentication, pagination, rate limits, or whether 'all' includes archived/hidden fields. The read-only nature is implied but unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the return format, scope of 'all', or potential limitations. It is too minimal for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. Per guidelines, the baseline is 4; the description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Zendesk ticket_fields' uses a specific verb ('List') and resource ('ticket_fields'), clearly distinguishing it from sibling list tools like zda_list_agent_roles or zda_list_automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by the resource name, but no context is provided for when not to use it or what differentiates it from other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk ticket_forms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'List all' which implies a read operation, but lacks details on pagination, response format, rate limits, or any side effects. The transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is perfectly concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is minimally adequate. However, it could be improved by noting that it returns an array of form objects or any default pagination behavior. The lack of such details makes it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage (empty properties). Per guidelines, 0 parameters yields a baseline of 4. The description adds no parameter info, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Zendesk ticket_forms' with a specific verb (List) and resource (ticket_forms). It distinguishes from sibling tools like zda_get_ticket_form (single) and zda_create_ticket_form (create). However, it lacks nuance about scope or default ordering, which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as zda_get_ticket_form for a specific form or other list tools. The description does not mention when to use 'list' vs 'get', nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk triggers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only says 'List all Zendesk triggers' without indicating pagination, rate limits, whether the list is exhaustive, or if it includes disabled triggers. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded and concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description gives the essential purpose. However, it would benefit from noting the return format (e.g., array of trigger objects) to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). The description adds no parameter info, but none is needed. Per guidelines, 0 params baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all Zendesk triggers'. This distinguishes it from sibling tools like zda_list_automations or zda_get_trigger, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., zda_get_trigger for a single trigger, or other list tools). There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk views.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, whether pagination exists, or any side effects. The description only states the action without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence of four words. Front-loaded with the core action. Every word earns its place with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It adequately states the purpose but lacks details about the response format, potential limitations, or any prerequisites. For a list-all tool, it meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, and schema coverage is 100% (vacuous). The description adds no parameter details because none are needed. Per guidelines, 0 parameters baseline is 4, and the description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states exactly what the tool does: 'List all Zendesk views.' The verb 'list' and resource 'Zendesk views' are specific and unambiguous. It clearly distinguishes from sibling tools like zda_list_groups, zda_list_automations, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. However, for a simple list-all tool, the purpose is self-evident. The description could mention that it retrieves all views without filtering, but the minimal context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Zendesk webhooks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent. The description states 'List all', implying a read operation with no destructive side effects, but does not discuss pagination, rate limits, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less list tool, the description is fully adequate. No output schema exists, but the operation is self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds no parameter-specific value, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'Zendesk webhooks', clearly distinguishing it from sibling tools like zda_get_webhook and zda_create_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools for creating, deleting, or updating webhooks exist, but no context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reorder triggers. Trigger order determines evaluation precedence and is a common source of silent routing bugs. GUARDED: call without require_confirm to preview the current order; re-call with require_confirm: true to apply. Provide the COMPLETE ordered list of trigger IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_ids | Yes | Trigger IDs in the desired new order (full list, first to last). | |
| require_confirm | No |
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 guarded behavior (preview-then-apply) and warns about routing bugs. However, it does not mention permissions required or the exact effect of reordering (though it implies non-destructive change). Still, the behavioral context is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences of increasing specificity: purpose, guarded behavior, input requirement. No redundant or unnecessary text. Perfectly sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could specify the return format (e.g., preview returns current order). However, the tool is simple with two parameters, and the description covers usage, input, and behavioral context adequately. Slightly lacking on output specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, but the description adds value for the 'require_confirm' parameter by explaining its role in preview vs apply. The 'trigger_ids' parameter is described as the complete ordered list, which matches the schema. Overall, the description enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reorder triggers.' It explains the importance: trigger order determines evaluation precedence and is a common source of silent routing bugs. This distinguishes it from sibling tools like zda_update_trigger or zda_list_triggers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidelines are provided: 'GUARDED: call without require_confirm to preview the current order; re-call with require_confirm: true to apply.' This tells the agent when to use, how to preview, and how to apply, with clear instructions to provide the complete ordered list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk automation. GUARDED: this object affects live ticket flow. Call without require_confirm to preview the current state; re-call with require_confirm: true to apply. Common fields: title, conditions {all,any}, actions, active. Automations are time-based.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is guarded and affects live ticket flow, and explains the preview-then-apply pattern. With no annotations, the description carries full burden. Could mention side effects or reversibility more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that front-load purpose, followed by guard warning and common fields. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main points but lacks description of the return value, especially for the preview step. Does not explain condition structure (all/any arrays). Without output schema, more detail on response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by listing common fields (title, conditions, actions, active) and clarifying the passthrough wrapper behavior for the data parameter. Schema coverage is 67%, but description compensates with practical parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing Zendesk automation' with a specific verb and resource, distinguishing it from sibling tools like create, delete, and other update tools. The term 'automation' is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call without require_confirm to preview, then with require_confirm to apply. Warns about affecting live ticket flow. Lacks explicit when-not-to-use or comparisons to alternatives like create_automation or get_automation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk group. Common fields: name, description, default, is_public.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the action as 'update' (implying mutation) but does not disclose idempotency, side effects (e.g., overwriting entire group vs. partial update), required permissions, error behavior, or return value. The minimal description lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action, and lists only essential details. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool mutates a Zendesk group and has three parameters (one nested object), the description is too sparse. It omits return format, error handling, how to construct the data object correctly, and whether require_confirm is needed. With no output schema, the agent has insufficient context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% coverage (id and data described). The description adds value by listing common fields for the data parameter (name, description, default, is_public), which is not in the schema. However, it does not explain the require_confirm parameter or specify required vs. optional data fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update an existing Zendesk group,' providing a clear verb and resource. It lists common fields (name, description, default, is_public) which clarifies scope, but does not differentiate from other update tools for different Zendesk resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like zda_create_group or zda_delete_group. Prerequisites (e.g., having the group ID) are implied but not stated, and there is no mention of when an update is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk macro. Common fields: title, actions, active, restriction.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as side effects, permissions required, or impact of updating fields like active (e.g., enabling/disabling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but somewhat fragmented. Single sentence plus a list; could be more structured. Not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no description of return values or confirmation behavior. For an update tool, more context about the response and confirmation requirement (require_confirm parameter) would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description lists common fields (title, actions, active, restriction) but adds little beyond schema descriptions. The data parameter is explained in schema; description does not clarify how to structure actions or conditions. Schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing Zendesk macro and lists common fields. It distinguishes from create_macro and delete_macro siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_macro or other update tools. Lacks context for 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.
Update an existing Zendesk sla_policy. GUARDED: this object affects live ticket flow. Call without require_confirm to preview the current state; re-call with require_confirm: true to apply. Common fields: title, description, filter {all,any}, policy_metrics (priority/metric/target/business_hours).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
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 tool 'affects live ticket flow' (implicit destructive hint) and explains the preview-then-apply pattern. It does not mention permissions or rollback, but the guarded warning and usage instructions are sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and packs essential information into a single paragraph without waste. Every sentence adds value: action, guarded warning, usage flow, and common fields. It is efficiently structured with front-loaded key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values. However, it covers the tool's behavior (preview/apply), parameter details, and guidance. For an update tool with a preview mechanism, the information is sufficient for correct invocation, though output format could be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with some parameters documented. The description adds meaning beyond the schema by listing common fields for the 'data' parameter (title, description, filter, policy_metrics) and clarifying that the field values should not be wrapped in an envelope. This helps the agent construct correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing Zendesk sla_policy'). It distinguishes from siblings by specifying the resource type and the guarded nature. The title and description together make 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Call without require_confirm to preview the current state; re-call with require_confirm: true to apply.' This tells the agent when to use the tool and how to safely apply changes, which is critical for a guarded object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk ticket_field. Common fields: type, title, description, required, active, custom_field_options (for dropdowns).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the full burden. It reveals the need to pass fields directly without an envelope, but does not disclose error behavior, idempotency, or what happens if the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and quickly list common fields. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is adequate for a simple update, it lacks information about return values, error conditions, and how the update behaves with partial data. Given no output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond schema by listing common fields that can be updated (e.g., type, title, description, required, active, custom_field_options). The schema covers 67% of parameters, and the description compensates for the data object's open-endedness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing Zendesk ticket_field' with specific verb and resource. It lists common fields, but does not explicitly differentiate from siblings like zda_create_ticket_field or zda_get_ticket_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, nor prerequisites like requiring an existing ticket field. The context is implied by the name, but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk ticket_form. Common fields: name, display_name, ticket_field_ids (ordered), active, end_user_visible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
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 mentions common fields but does not disclose behavioral traits such as permissions required, whether the update is partial or full, or any side effects. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not explain the return value or error conditions. While it covers the basics, it lacks completeness for a tool with nested objects and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by listing example fields for the 'data' object (name, display_name, ticket_field_ids, active, end_user_visible). With 67% schema coverage, this provides useful context that the schema alone does not give.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing Zendesk ticket_form') and lists common fields. Among siblings, it is distinct from create, delete, get, and list operations, making differentiation easy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when updating a ticket form but provides no explicit guidance on when to use this tool versus alternatives (e.g., create or delete) or any prerequisites. It lacks 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk trigger. GUARDED: this object affects live ticket flow. Call without require_confirm to preview the current state; re-call with require_confirm: true to apply. Common fields: title, conditions {all,any}, actions, active, category_id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully warns that the tool affects live ticket flow and explains the confirmation mechanism. It also lists common updatable fields, though it does not detail authentication or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no redundancy. It front-loads the purpose, then warns, explains workflow, and lists common fields. Every sentence is necessary and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (guarded update, no output schema), the description covers core usage, safety, and parameter guidance. It could mention return values, but the overall completeness is high for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (id and data described). The description adds value by explaining require_confirm usage and listing common data fields (title, conditions, actions, etc.), which helps with the passthrough 'data' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing Zendesk trigger,' using a specific verb and resource. This clearly distinguishes it from sibling tools like create or delete triggers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context: 'GUARDED: this object affects live ticket flow' and a clear workflow pattern ('preview then apply'). It does not explicitly mention when not to use, but the preview mechanism implicitly guides safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk view. Common fields: title, conditions {all,any}, execution (columns/sorting), active, restriction.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Only states it updates, but fails to disclose behavioral traits like idempotency, error behavior, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. Front-loaded with purpose and immediately followed by useful field examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context on prerequisites (view must exist), return value (no output schema), error handling, and behavior of 'require_confirm'. For a mutation tool with many siblings, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value by listing common fields for the 'data' object (title, conditions, execution, active, restriction), compensating for schema's open-ended additionalProperties. Schema coverage is 67%, description enriches meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update an existing Zendesk view' with specific verb and resource. Mentions common fields, distinguishing from create/delete/get tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (update, not create/delete) but no explicit guidelines on when to use vs. alternatives like zda_create_view or zda_get_view. Lacks when-not and alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Zendesk webhook. Common fields: name, endpoint, http_method, request_format, status, subscriptions, authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | String object ID | |
| data | Yes | The resource's fields (passthrough) — e.g. title/name, conditions ({all,any} of {field,operator,value}), actions, etc. Pass the fields directly; do NOT wrap them in a {<resource>: ...} envelope — the server adds that automatically. | |
| require_confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'update', implying mutation, but lacks details on idempotency, failure behavior, or destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no unnecessary words. However, it could be slightly more structured by separating the field list or adding a brief instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an update tool with a nested object parameter and no output schema, the description is insufficient. It omits details about require_confirm, the effect of updates, and required data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions. The description adds specific webhook fields (name, endpoint, etc.) beyond the generic 'passthrough' note, enhancing understanding of the data parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing Zendesk webhook', a specific verb+resource combination. It lists common fields to update, distinguishing it from create, delete, and get webhook siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_webhook or delete_webhook. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action (e.g., list, get, create, update, delete for automations, groups, etc.). The only overlapping pair is audit_logs vs audit_logs_for_object, but their descriptions clearly differentiate scope. Agent can reliably select the correct tool.
Most tools follow a consistent 'zda_verb_noun' pattern (e.g., zda_list_automations, zda_create_trigger). However, a few read-only tools are simply noun phrases (zda_account_settings, zda_audit_logs) without a verb, breaking the pattern. Overall, the naming is predictable with minor deviations.
With 54 tools, this is a large surface area for a single server. While each tool covers a distinct admin operation (CRUD for 9 object types plus read-only tools), the count is on the higher end. It may overwhelm agents but is justifiable for a comprehensive admin interface.
The toolset provides full CRUD coverage for major Zendesk admin objects (automations, triggers, views, etc.) and includes key read-only resources (audit logs, brands, locales). Missing operations like creating agent roles or managing custom role definitions are minor gaps, but the core admin workflow is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
Read tickets, contacts, companies, agents and groups; create, update and reply to tickets.
Manage Chili Piper scheduling links, meetings, routing rules, and teams. Admin only. Experimental.
Manage websites, help documents and customer-support conversations with safe, scoped tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sniebauer/zendesk-admin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
