cloudflare-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Many tools target distinct resources, but the 390-tool surface creates real overlap: API Shield vs API Gateway operations/schemas/config, generic get_ruleset vs scoped account/zone rulesets, and list_workers vs list_worker_services are all easy to confuse. The sheer volume makes misselection likely despite mostly descriptive names.
Naming Consistency4/5
The overwhelming majority of tools follow a consistent list_ or get_ + resource pattern, which is excellent at this scale. Minor deviations like graphql_analytics, verify_token, get_zone_setting vs get_zone_settings, and awkward names like list_account_rules_lists prevent a perfect score.
Tool Count1/5
390 tools is an extreme count for any MCP server, far beyond the 50+ threshold. The scale makes it impractical for an agent to load, compare, and reliably select from the tool set.
Completeness2/5
The set spans many Cloudflare products but is almost entirely read-only, with no create, update, or delete operations for DNS, Workers, R2, rules, or other core resources. Several listed resources also lack paired get_ tools, such as Access apps and origin pools, leaving agents with dead ends.
Average 3.1/5 across 341 of 390 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of explaining behavior. It only says 'Get', with no disclosure of output shape, pagination, ordering, error behavior, or whether the call is read-only. An agent has no behavioral expectations beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than efficiently useful. Every word restates the tool name, so the single sentence does not earn its place by adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves out what the tool returns, how detections are represented, and how account_id and postfix_id identify the message. The two required parameters are documented, but the overall invocation context is inadequately described for a tool with this many close siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have basic descriptions ('The account ID', 'The message postfix ID'). The description adds no parameter-level detail, but the schema already covers the parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get email security message detections' is a bare restatement of the tool name with underscores replaced by spaces; it does not define what 'detections' are or what a 'message detection' represents. It gives no conceptual clarification beyond the name itself and does not distinguish it from similar email security tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, no exclusions, and no alternatives. With siblings such as get_email_security_message and list_email_security_investigate, the agent is given no criteria to choose this tool over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it fails completely. It offers no information about pagination, quota limits, required scoping, or what constitutes a 'command.' The verb 'List' weakly implies a read operation, but this is inference from the name, not disclosure from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but this is under-specification rather than conciseness — the sentence merely repeats the tool name and earns no place. There is no front-loaded information that an agent couldn't already derive from the name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain what the tool returns, but it doesn't. It never defines what a DEX command is, whether the result is paginated, or how the account_id scoping affects results. The sibling get_dex_commands_quota hints at quota-related behavior that is completely unmentioned here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents account_id as 'The account ID.' The description adds nothing about the parameter, but per the baseline rule, a 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List DEX commands' is a pure restatement of the tool name, adding no new information. It uses a verb+resource pattern but is functionally tautological and does nothing to distinguish this from siblings like get_dex_commands_quota or list_dex_rules, which share the DEX domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many DEX-related siblings (get_dex_commands_quota, list_dex_colos, list_dex_tests_overview, etc.). No context, prerequisites, or exclusion conditions are given, leaving the agent to guess which DEX tool fits the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It merely says 'Get', implying a read operation, but does not describe what data is returned, whether any permissions are needed, or whether any related domain data is included or excluded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it is under-specified: it repeats the tool name without providing useful structure or detail. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'domain info' means and how this differs from related brand protection tools. It does neither, leaving the agent without enough context to confidently select and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single account_id parameter. The description adds no parameter-level meaning beyond that, but the baseline of 3 applies because the schema covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get brand protection domain info' is a verbatim restatement of the tool name, adding no new information about what consitutes 'domain info' or how it differs from related tools. It is closer to a tautology than a meaningful definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over sibling tools such as get_brand_protection_url_info or list_brand_protection_tracked_domains. An agent is left to infer the intended scope from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'get', which weakly implies a read operation, but it does not explain whether this consumes quota, whether it requires specific permissions, or what kind of response to expect. The description adds no meaningful behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is not genuinely concise because the one sentence merely repeats the tool name without earning its place by adding information. There is no structure or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should at least clarify what 'requests quota' means, whether quota is account-scoped, and what the result represents. The current description leaves these gaps, so it is not adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single required parameter account_id is already documented in the schema. The description adds no additional semantic detail, which is acceptable under the baseline given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Cloudforce One requests quota' is essentially a verbatim restatement of the tool name. It identifies the resource and operation but adds no clarifying detail, and it does not distinguish itself from similarly named siblings like get_cloudforce_one_request or get_cloudforce_one_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives, what context it applies to, or what 'requests quota' represents. The sibling list includes several Cloudforce One tools, but the description gives the agent no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden, and it only restates the operation. It does not say whether this is account-scoped or zone-scoped despite requiring account_id, nor does it disclose pagination, filtering, or what a colocation record represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is one short sentence with no redundancy, so it earns points for brevity, but it is closer to under-specification than deliberate conciseness; there is no front-loaded context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single ambiguous phrase with no output schema, no annotations, and no behavioral context is inadequate. An agent cannot tell what DEX colocations are, what data comes back, or how this relates to the dozen other DEX tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, account_id, has a straightforward 'The account ID' description. The tool description adds nothing beyond the schema, but because the schema already fully covers the single parameter, the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List DEX colocations' gives a verb and a resource, but 'DEX colocations' is domain-specific and never expanded. Among many sibling list tools, I cannot tell what a colocation is here (Digital Experience monitoring locations? Magic Transit sites?), so it does not distinguish this from list_dex_tests_overview, list_dex_rules, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over the many other DEX-related list endpoints or the equally terse sibling tools. It does not mention account/zone scope, prerequisites, pagination, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. There is no mention of pagination or result limits (typical for list operations), ordering, required permissions, or what the response looks like. Only the 'List' verb implicitly suggests a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six words long, so it is undeniably short, but this is under-specification rather than earned conciseness. Every word merely restates the tool name and contributes zero additional intent or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple — one parameter, fully covered by the schema — but with no output schema and no annotations, the description should compensate by hinting at return structure, pagination, or scope of results. It does none of this, so an agent is left guessing what a successful invocation actually yields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single required account_id parameter is documented as 'The account ID' in the schema itself. The description adds nothing beyond that, so the baseline 3 applies; the schema fully handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List email security blocked senders' is a near-word-for-word restatement of the tool name with the snake_case converted to spaces. It is clear about the general operation, but it adds no information beyond what the identifier itself already conveys, fitting the tautology criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not distinguish itself from sibling tools like get_email_security_block_sender (which fetches a single sender) or the counterpart list_email_security_allow_policies, leaving the agent to infer scope purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior, but 'List email security domains' only restates the operation already implied by the tool name. It does not disclose side effects, authentication needs, pagination, rate limits, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is only four words with no wasted tokens, but it simply repeats the tool name and omits useful context, making it under-specified rather than genuinely concise. An effective description would front-load scope and sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is incomplete for reliable invocation. It does not explain what an email security domain is, whether results are paginated, how account_id affections the query, or how this tool differs from closely related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage by describing account_id as 'The account ID', so the baseline is met. The tool description adds no extra meaning about how account_id scopes the list or what format the ID should take.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List email security domains' is essentially a verbatim restatement of the tool name and adds no new specificity. It identifies a resource and a list operation, but it does not explain what an email security domain is, what scope it covers, or how it differs from the many sibling email security list/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description never states when to choose this tool over alternatives such as get_email_security_domain, list_email_security_trusted_domains, or other list_email_security_* tools, and it does not mention prerequisites beyond the schema's required account_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information, yet it only repeats the operation name. It does not disclose pagination, return shape, filtering semantics, or what constitutes a 'submission,' beyond the fact that it lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified; the four words add no information beyond the tool name. Being short is not the same as being well-structured, and there is no front-loaded distinguishing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what a submission is and what the list contains. It does neither, so an agent cannot predict the result or distinguish it from nearby email-security list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: account_id is documented as 'The account ID.' The description adds no parameter-level detail, so the schema carries the full burden. Per the baseline for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List email security submissions' is essentially a restatement of the tool name. It identifies the verb and resource but provides no detail that distinguishes this tool from sibling email security tools such as list_email_security_investigate or list_email_security_allow_policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling tools. It does not mention filters, prerequisites, or alternative tools for related email-security queries, leaving the agent to guess from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does convey read-only intent via the verb 'Get' and a time grain via 'daily', but it does not reveal return shape, aggregation semantics, limits, or any special requirements beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with zero wasted words. However, it is under-specified rather than efficiently complete; a few substantive details would earn their place and improve the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must explain what the agent will get back and why this tool is the right one. A single vague phrase about daily analytics is insufficient for distinguishing it from the large set of realtime and analytics siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both required parameters are already documented in the schema. The description adds no additional meaning about how account_id and app_id relate to the returned analytics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'Get Realtime Kit daily analytics' is 'get_realtime_analytics_daywise' with 'Kit' inserted. It does not clarify what Realtime Kit is, what metrics are included, or how this differs from the many realtime and analytics sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_zone_analytics, get_analytics_by_colo, graphql_analytics, or the get_realtime_* summary tools. No prerequisites or context scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'Get' implies a read operation, but the description does not state whether this is read-only, what scope the summary covers, whether time filters are applied, or what kind of response to expect. This is minimal disclosure that does not meaningfully characterize behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it essentially restates the tool name and adds no substantive information. It is structurally simple and front-loaded, but the sentence does not earn its place by distinguishing the tool or explaining its behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema or annotations, the description is too sparse. It does not clarify what 'Spectrum analytics summary' returns, how far back the summary goes, or how it differs from the several other analytics tools listed as siblings. A real agent would need more context to select and call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter, zone_id, and documents it as 'The zone ID'. With full schema coverage, the baseline is 3, and the description adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Get Spectrum analytics summary', restates the tool name almost verbatim and adds little independent meaning. It indicates a verb and resource, but does not explain what the summary contains, what time range it covers, or how it differs from sibling analytics tools such as get_zone_analytics, get_analytics_by_colo, and get_dns_analytics_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many analytics-related alternatives in the sibling list. It does not state exclusions, prerequisites, or which tool should be used instead for different analytics needs, leaving the agent to infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. 'Get' implies a read-only operation, but the description does not state what the returned settings look like, account-level scope, authentication expectations, or any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded, but it repeats the tool name without adding information, so it does not fully earn its place. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should clarify what 'connectivity settings' includes and what the caller receives. It provides neither, leaving the agent to guess at semantics and response shape despite the simple single-parameter signature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the only parameter (`account_id`). The description adds no parameter-level nuance, but under the rubric high coverage sets the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Zero Trust connectivity settings' is a whitespace-normalized restatement of the tool name and does not specify which settings are covered or how they differ from related configuration getters. It has a clear verb and resource, but adds no purpose detail beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives such as get_gateway_configuration, get_zerotrust_hostname_route, or other settings getters. There are no preconditions, exclusions, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'List', which implies a read operation, but it does not disclose pagination, response shape, account-scoping behavior, or whether the result is an aggregate overview or one object per test.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and easy to parse, but it carries no information beyond the tool name, making it under-specified rather than efficiently concise. It is front-loaded and free of fluff, but the sentence does not earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the definition should explain what the returned overview contains and describe list behavior such as pagination or ordering. It does none of this, so an agent cannot predict the response or understand how this tool relates to the broader DEX tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is documented in the schema as 'The account ID'. The description adds no further parameter context, but the baseline of 3 applies because the schema already provides the necessary parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a verbatim restatement of the tool name with underscores converted to spaces, so it adds no semantic information beyond the name. It says it lists DEX tests overviews but does not clarify what a DEX test is, what the overview contains, or how this tool differs from related DEX tools like list_dex_rules or list_dex_commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as list_dex_rules, list_dex_commands, or get_dex_rule. No prerequisites, exclusions, or context are provided, so an agent must rely on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it merely restates the tool name. It does not mention response format, data freshness, account scoping behavior, rate limits, or whether this is a read-only operation, providing no behavioral transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than intentionally concise. The single phrase 'Get live DEX fleet status' adds minimal value over the tool name and does not earn its place by conveying useful selection or invocation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, no output schema, and no annotations, the description should clarify what DEX fleet status consists of, what 'live' means practically, and what the response contains. None of this is provided, making the definition incomplete for reliable agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id described as 'The account ID', so the schema already documents the parameter. The description adds no additional meaning about the parameter, meeting the baseline for parameter semantics but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('live DEX fleet status'), making the core action clear. However, it does not distinguish itself from sibling tools like get_dex_fleet_status_over_time or list_dex_fleet_status_devices, leaving what 'fleet status' includes and how 'live' differs from alternatives unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many related DEX tools in the sibling list. There is no mention of prerequisites, intended scenarios, or exclusions, so 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because annotations are absent, the description alone must convey behavior. It only says 'list' results, so an agent cannot know the returned result shape, pagination, ordering, permissions, or whether this is limited to a specific investigation state. The description adds almost no behavioral detail beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Thedescriptions a single,front-loaded sentencewith no fluff. Itis not verbose or repetitive in structure, though its brevity comes at the cost of informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain what this list represents, but the ambiguous phrase 'investigation results' is not enough. Given a large set of sibling email-security tools, this definition is too incomplete for an agent to invoke it confidently or interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single required parameter completely ('account_id' with description 'The account ID'), so the high-coverage baseline applies. The description adds no param-specific meaning, but no compensation is needed for this one well-documented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'List email security investigation results' adds only the word 'results' to the name 'list_email_security_investigate'. It never defines what an email security investigation or its results are, and it does not distinguish this from siblings such as list_email_security_submissions or get_email_security_message_detections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool instead of the many email-security list/get siblings. An agent cannot tell whether this is the right endpoint for listing investigations versus submissions, messages, detections, or reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It only says 'Get brand protection URL info' and does not disclose whether the operation is read-only, what response shape to expect, whether pagination applies, or what happens with invalid or non-protected URLs. The verb implies a read but that is not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than efficiently informative. It repeats the tool name and does not earn its place by adding any operational context beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only a terse description, important context is missing: what the returned 'info' represents, how account_id and url relate, and when this tool should be chosen over the similar brand protection siblings. The large sibling list makes the ambiguity more costly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with url described as 'URL to check' and account_id as 'The account ID'. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a human-readable restatement of the tool name and gives no detail on what 'URL info' actually contains or returns. It identifies a get operation on a brand protection URL resource, but does not meaningfully distinguish it from the sibling get_brand_protection_domain_info beyond the URL/domain wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_brand_protection_domain_info, list_brand_protection_alerts, or list_brand_protection_queries. The description provides no context about prerequisites, intended call scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. 'Get' implies a read-only operation, but the description does not explain what the quota value means, whether the response contains usage and limits, or any authentication/failure behavior. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with no wasted words. However, it carries no information beyond the tool name, so its brevity is closer to under-specification than to a well-crafted summary of constraints or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is responsible for explaining the return concept. It does not define what the DEX commands quota response contains or how to interpret it, leaving the agent with only the minimal input-side information from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter account_id is fully documented in the schema with a clear description, so the baseline is 3. The tool description adds no additional parameter context, but the schema coverage is sufficient for this single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource ('Get DEX commands quota'), so the agent knows it retrieves some quota. However, it is essentially a restatement of the tool name and does not clarify whether the quota is a limit, current usage, or remaining allowance; it also does not position itself against similar quota tools like get_cloudforce_one_requests_quota.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided: there is no when-to-use context, no mention of alternatives, and no exclusions. The intended use is only implied by the tool name and the required account_id, not by any explanatory description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it only barely implies a read operation via the word 'Get'. It does not state what happens when the postfix_id is not found, whether it returns raw message content or metadata, or what scope/authorization is required beyond the two IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single five-word sentence is maximally concise with zero filler, which is good. However, it is under-specified for the sibling context: one clarifying clause about what 'details' encompasses or how this differs from get_email_security_message_detections would earn its place and would not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with no output schema, the parameter side is covered by the schema, but the absence of an output schema means the description should hint at return semantics — 'details' is too undetermined. The real gap is ambiguity against get_email_security_message_detections, which an agent cannot resolve from this description, making it incomplete for safe tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented as 'The account ID' and 'The message postfix ID', so the schema already carries the parameter semantics and the baseline of 3 applies. The description itself adds nothing about parameters, and does not clarify how an agent would obtain a valid postfix_id, but the schema meets the minimum bar.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a resource ('email security message details'), so it is not a tautology and conveys a fetch operation. However, 'details' is vague about what is actually returned, and the very close sibling get_email_security_message_detections is not differentiated, leaving an agent unable to tell these two lookups apart from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus the many email_security siblings, particularly get_email_security_message_detections and list_email_security_investigate. The description offers no when-to-use context, no exclusions, and no mention of alternatives, so the agent must guess which lookup is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only implies a read-only operation via the word 'Get.' It says nothing about authentication scope, behavior for invalid or nonexistent IDs, rate limits, or what 'details' actually includes. This is minimal disclosure for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with the verb front-loaded and no wasted words. However, it is concise to the point of under-specification, adding almost no information beyond the tool name, so it does not earn a top score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is structurally simple — two required string IDs, no nested objects, no output schema — and the schema fully documents its inputs, so an agent can invoke it mechanically. Clear gaps remain: no output shape, no indication that bookmark_id is typically obtained from list_access_bookmarks, and no differentiation from the list variant. This is minimum viable for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both required parameters (account_id, bookmark_id) are already documented in the schema itself, so the baseline of 3 applies. The description adds no parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Get') and a resource ('Access bookmark'), so an agent can tell it performs a retrieval. However, it nearly restates the tool name verbatim — the only added meaning is the word 'details,' which implies the return value. It does not distinguish this from sibling getters like get_access_tag or from list_access_bookmarks, so it is a clear but minimally informative purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus list_access_bookmarks or any other sibling. There is no mention of how to obtain a bookmark_id (e.g., listing bookmarks first) or any context about Access bookmarks. Any usage signal is left entirely to the get-vs-list naming convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get ... details' and does not mention required scope, response format, permissions, or error behavior. It does not contradict any annotations because none exist, but it offers minimal transparency beyond saying it is a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, so it is concise and front-loaded. However, it is so minimal that it reads more like a label than a helpful tool definition; a clarifying phrase about the resource type or response would improve it without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the two required parameters, so the agent knows how to invoke the tool, and the operation is a simple get-by-ID. However, with no output schema and no annotations, the description does not explain what 'request details' means or what the response will contain, and it does not disambiguate the request entity from related entities in the sibling list. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'account_id' and 'request_id' already described as 'The account ID' and 'The request ID'. The description adds no additional parameter semantics, but the high schema coverage means the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Get') and resource ('Cloudforce One request details'), so an agent can tell this is a retrieval operation for a single request. However, it largely restates the tool name and does not clarify what a 'request' is relative to similar sibling tools like get_cloudforce_one_event or get_cloudforce_one_query, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and it names no sibling tools or exclusions. With dozens of similar get_* tools in the sibling list, an agent has no explicit basis for choosing this one over, say, get_cloudforce_one_event or get_cloudforce_one_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'List' implies a read-only operation, but nothing is said about pagination, required permissions, whether the accout must exist, or what happens with no containers. This is thin coverage for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is short and front-loads the action and resource. It contains no wasted words, though 'for an account' is somewhat redundant with the account_id parameter. The minimalism is better than verbose filler but does leave semantic gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling toolset and no output schema or annotations, this description is not complete enough for reliable selection. It fails to define what a container is, which makes the tool ambiguous among many list_* tools. The single parameter is documented, but the overall tool behavior and selection context are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the account_id parameter is documented as 'The account ID'. The description's 'for an account' maps directly to that parameter but adds no extra syntax, format, or semantic detail beyond the schema. Baseline 3 is appropriate because the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('List') and a resource ('containers'), and specifies the account scope. However, 'containers' is underspecified and the description does nothing to distinguish this from the many sibling list_* tools (e.g., list_r2_buckets, list_d1_databases, list_accounts). Without defining what kind of containers are meant, an agent cannot confidently route to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when to use guidance is provided. The description does not mention any alternatives or exclusion criteria, even though the sibling list contains many similar list_* tools that operate on accout-level resources. This leaves the agent to infer suitability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description discloses nothing else — no pagination behavior, no scoping semantics, no account/zone context, no return characteristics. The description adds essentially nothing beyond what the tool name already signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words with zero wasted content and is naturally front-loaded. For a tool with a single parameter, this level of brevity is defensible. It borders on under-specification, but there is no verbose padding or redundancy to penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema), which lowers the bar, but the description still fails to explain what DEX rules are, whether this is account-scoped or zone-scoped, or how it differs from the 400+ sibling tools. An agent cannot confidently distinguish list_dex_rules from similar rule-listing tools based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is documented as 'The account ID' in the schema. The description adds no parameter information, but the baseline of 3 applies because the schema fully covers the sole parameter. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('DEX rules'), so it is not a tautology and conveys the basic operation. However, 'DEX' is an unexplained acronym and there is no indication of what DEX rules are or how they differ from the many other rule-listing tools in the sibling set. This is adequate but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the dozens of similar list tools (list_firewall_rules, list_mnm_rules, list_zone_rulesets, etc.). No conditions, prerequisites, or alternatives are mentioned anywhere in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the list action and does not mention pagination, ordering, response shape, account scoping behavior, or any other operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this reads as under-specification rather than effective conciseness. It is a bare fragment that omits useful context and does not structure any additional guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should provide more context about what a Cloudforce One query is and what the response contains. The minimal text leaves an agent without enough information to fully understand the tool's result or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single required parameter account_id is already documented as 'The account ID.' The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'List Cloudforce One queries.' It is clear enough to distinguish from related 'get_cloudforce_one_query' behavior, but it does not elaborate on scope or what a 'query' represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_cloudforce_one_query, list_cloudforce_one_events, or list_cloudforce_one_request_types. No context, exclusions, or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. The word 'List' implies a read-only operation, but the description does not mention pagination, sorting, required authorization scope, rate limiting, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is so terse that it largely restates the tool name. There is no structural benefit, and important context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no annotations and no output schema, the description should clarify what the result list represents, any pagination behavior, and how it relates to get_connectivity_service. None of that is present, leaving an agent with only the raw name and a one-line phrase.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter, account_id, with a description. The tool description adds no parameter-level context beyond that, so it neither helps nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear list operation on a specific resource, connectivity directory services. The verb + resource combination is unambiguous at a basic level. However, it does not define what a connectivity directory service is or distinguish it from similar list_* sibling tools such as list_addressing_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. The sibling set contains get_connectivity_service, list_addressing_services, and other connectivity-related tools, but no conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get logs', implying a read operation, but does not describe log pagination, retention, output format, account-level vs gateway-level scoping behavior, or any relevant limitations. This is insufficient for a tool that retrieves potentially large or complex log data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence and is not verbose, so it is easy to parse. However, it is under-specified: it omits key contextual details such as time range, pagination, or the nature of the logs, making it efficient in wording but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and only two parameters, but 'logs' is a broad concept that typically requires clarification about filtering, time windows, limits, and response format. The description does not cover these aspects, and the sibling context includes many similar get/list tools, making this definition incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for both parameters ('The account ID' and 'The AI Gateway ID'). Since the schema fully documents the parameters, the baseline is 3, and the description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get logs for an AI Gateway'), making the core operation clear. However, it does not distinguish this from the many related AI Gateway tools in the sibling list, such as get_ai_gateway_route or list_ai_gateways, beyond the mention of logs. It is clear enough for basic selection but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool versus alternatives, whether it is read-only, whether pagination or time-range parameters are supported, or any conditions that would make it the correct choice among the extensive sibling list. An agent would have to infer usage entirely from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get ... details' implies a read operation, but it does not state whether authorization is required, what response format is expected, or what 'details' actually include. No additional behavioral context is provided beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than efficiently informative. It contains no structure, no examples, and no context that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description only says 'Get Cloudforce One dataset details'. It does not explain what a dataset is, what details are returned, how the dataset_id is used, or any relationships to sibling tools. An agent would likely need additional external knowledge to invoke this correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both account_id and dataset_id are documented in the input schema. The description adds no extra meaning beyond what the schema already provides, which meets the baseline but does not enrich understanding of how the parameters relate to the returned dataset details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Get Cloudforce One dataset details'. It distinguishes the tool from related siblings like list_cloudforce_one_datasets by implying a single-dataset retrieval, but 'details' is vague and doesn't enumerate what fields or information are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention that this should be used after listing datasets, nor any comparison to get_cloudforce_one_request, get_cloudforce_one_event, or get_cloudforce_one_query. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read operation via 'Get' and suggests a summarized result via 'aggregate', but it does not explain pagination, time windows, filtering, account scope semantics, or what the returned aggregate actually represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it is under-specified rather than appropriately sized. It front-loads the operation name but does not provide enough substance for a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify the return value and aggregate semantics. It does neither, leaving the agent with only a terse, ambiguous phrase. The single parameter is documented well, but the overall call context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already described as 'The account ID'. The tool description adds no additional parameter meaning or context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get Cloudforce One events aggregate'. It distinguishes itself at a basic level from siblings like get_cloudforce_one_event and list_cloudforce_one_events by referring to the 'aggregate' resource, but it does not explain what 'aggregate' means or what data it contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_cloudforce_one_events or get_cloudforce_one_event. The intended distinction is only implicit in the tool name, not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state the read-only nature explicitly, required permissions, error behavior for unknown query IDs, rate limits, or what fields the 'details' response contains. Only the verb 'Get' hints that this is a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence with no filler and the verb is front-loaded. However, the brevity reflects under-specification rather than efficient trimming; useful context about selection and return values was omitted rather than deliberately excluded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what a Cloudforce One query is, what the returned details contain, and how this tool differs from the many Cloudforce One siblings. The 100%-covered schema handles parameter documentation, but the description leaves return values and tool-selection context undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both query_id and account_id documented in the input schema, so the baseline of 3 applies. The description adds no parameter-level meaning beyond the schema — it does not explain how query_id is obtained (e.g., from list_cloudforce_one_queries) or how the two parameters relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('Cloudforce One query details'), so an agent can understand the core operation. However, it does not explicitly differentiate this from sibling tools like list_cloudforce_one_queries, get_cloudforce_one_request, or get_cloudforce_one_event — the agent must infer from the tool name that this fetches a single query by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_cloudforce_one_queries (to enumerate queries) or get_cloudforce_one_event/request (related but different Cloudforce One resources). No conditions, exclusions, or alternative references are given, leaving the agent to rely purely on naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a read-like fetch ('Get'), but says nothing about whether the scan must be completed first, whether results can be partial, what authentication or account context is needed, or what the response will look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the action, containing no filler words. However, it is under-specified: at four words it provides only the bare retrieval idea and omits differentiating or behavioral context needed for an agent to select it confidently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the parameter definitions are present, but there is no output schema and no annotations to fill in expectations about the result shape or prerequisites. The close sibling get_url_scan_har further increases the need for clarifying context that this description does not provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters: scan_id and account_id both have descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so it stays at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get URL scan result.' It is not a tautology and conveys the basic retrieval purpose, but it does not distinguish this tool from the closely named sibling get_url_scan_har or explain what a 'URL scan result' contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, when not to use it, or what alternatives might be more appropriate. The presence of get_url_scan_har nearby makes some routing guidance valuable, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates that the operation lists alerts, without mentioning pagination, response shape, account scoping behavior, or any other runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with no filler, but it mostly restates the tool name. It is concise to the point of under-specification rather than being an appropriately sized explanatory description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a large sibling family of brand-protection list endpoints, the description is incomplete. It does not clarify what alerts contain, what the response looks like, or how this endpoint relates to nearby tools such as list_brand_protection_matches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id described as 'The account ID', so the schema already documents the only parameter. The description adds no additional parameter-level meaning, but does not need to compensate for a schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and a resource ('brand protection alerts'), so the core operation is understandable. It does not, however, explain what an 'alert' is or distinguish it from sibling operations like list_brand_protection_matches or list_brand_protection_recent_submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many other brand-protection list tools. There are no usage contexts, exclusions, or references to alternative endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only says 'List', implying a read operation, but does not disclose pagination, scoping beyond the required account_id, result ordering, or whether any filtering or side effects exist. This is minimal coverage 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, making it easy to parse. However, it essentially restates the tool name and provides no explanatory value beyond that, so it is more under-specified than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is not entirely inadequate, but with no annotations and no output schema it should explain what a logo match is, how account_id is used, and what the response will contain. The current text leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single account_id parameter, so the baseline is 3. The tool description adds no additional meaning about how account_id relates to logo matches, but the schema already documents the parameter. It is adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and a resource ('brand protection logo matches'), which identifies the operation reasonably well. However, it does little to differentiate this from the sibling list_brand_protection_matches beyond relying on the word 'logo' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like list_brand_protection_matches or list_brand_protection_logos. The intended use is only implied by the operation name, with no mention of prerequisites, filters, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses only that this is a list operation, with no mention of pagination, filtering, required account context, whether the account_id is an owner or scope, or what happens with no logos present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded, but it is so terse that it doesn't add meaningful guidance beyond the tool name. It is not verbose, but it under-uses its opportunity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single terse sentence, the description lacks any detail about filter behavior, pagination, return shape, or relationship to the many similar brand protection list tools. An agent would have to infer nearly everything.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single account_id parameter, and the description adds no additional meaning beyond 'List...'. Since the schema documents the parameter adequately, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: 'List brand protection logos'. It is distinguishable from get_brand_protection_logo (singular) and from sibling list_* tools, though it doesn't explicitly state what a 'logo' represents in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus list_brand_protection_logo_matches, get_brand_protection_logo, or other brand protection list tools. The simple name implies a direct listing, but the description provides no context for selecting it among many similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose read-only behavior, pagination, response shape, or any side effects. 'List' weakly implies a read operation, but the description does not carry the behavioral burden expected when annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is close to under-specification and largely restates the tool name in sentence form. It is concise but does not structure any additional useful context beyond the bare operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, a list endpoint should at least convey that it returns available datasets and whether pagination applies. The one-line description omits this, leaving an agent to guess about response format and account scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single account_id parameter is already documented in the schema. The description adds no additional meaning, such as clarifying that the datasets are scoped to the account, keeping this at the schema-covered baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('Cloudforce One datasets'), so the core operation is clear. It also indirectly distinguishes from the sibling get_cloudforce_one_dataset by indicating enumeration rather than single-item retrieval, though it offers no detail about what a dataset is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_cloudforce_one_dataset or list_cloudforce_one_events. The account-scoped nature of the tool is only implied by the required account_id parameter, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only says 'List', implying a read operation. It does not disclose scoping, pagination, filtering, response shape, authentication/permisions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, but it essentially restates the tool name and provides no structural information beyond the basic operation. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists and no annotations are provided, yet the description does not mention return values or list semantics. For a simple one-parameter list operation it is minimally callable, but an agent lacks context about pagination, response format, and relationship to get_email_security_allow_policy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id is fully covered by the schema description ('The account ID'), so the schema does the heavy lifting and the description adds no additional parameter context. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('email security allow policies'), making the operation unambiguous. It does not explicitly contrast with the sibling get_email_security_allow_policy, but the list-vs-get verb distinction and the specific resource provide adequate purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over alternatives; there are no conditionals, exclusions, or references to siblings. The only usage signal is the verb 'List', which is already present in the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. 'List' implies a read-only operation, but the description does not mention pagination, account scoping, output format, or potential size/performance constraints. An agent gets no meaningful behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is indeed concise and front-loaded, with no wasted words. However, it is under-specified: nearly identical to the tool name and lacking any additional contextual structure that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only one short sentence, an agent cannot tell what an infrastructure target is, what the response looks like, whether results are limited, or how this listing relates to get_infrastructure_target. The information is minimally viable but clearly incomplete for correct invocation in an unkown context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 100%, so the account_id parameter is already documented as 'The account ID' in the schema. The description adds no extra meaning about how account_id is used, what scope it produces, or any relationship to other resources. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('infrastructure targets'), so an agent can tell this is a listing operation. However, it does not differentiate the tool from its sibling get_infrastructure_target beyond the plural/verb form, and the wording essentially restates the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_infrastructure_target. There are no conditions, prerequisites, or exclusions, leaving the agent to infer the intended context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description needs to carry the full behavioral burden. 'List' implies a read-only operation, but the description does not mention pagination, account-scoping, authentication, or what the response contains. It largely restates the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. However, it is under-specified for an agent that needs context about the Realtime Kit domain, so brevity comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description needs to explain more than the resource name. It does not describe what a Realtime Kit app is, how results are returned, or whether pagination is involved, leaving the agent with only the name and one schema field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter, account_id, at 100%, so the schema is the primary source of parameter meaning. The description adds no parameter-specific detail, but because coverage is high the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Realtime Kit apps' uses a specific verb and resource, so an agent can tell it lists Realtime Kit applications. It is clear about the basic operation, but it does not differentiate itself from closely related siblings such as list_calls_apps or list_realtime_livestreams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, and no exclusion or prerequisite information is provided. An agent must infer from the name alone that this is the right listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only collection operation, but nothing is said about pagination, result ordering, limits, or what a hostname route entry looks like. The description adds no behavioral context beyond what the verb 'List' already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only five words and is efficiently front-loaded, but it is minimal to the point of restating the tool name. It earns its place structurally but does no additional work. There is zero waste, yet also zero added informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only a one-sentence description, the definition leaves the agent without context on pagination, result shape, or the distinction between hostname routes and teamnet routes. The single account_id parameter is documented, but the operation's return behavior is entirely unspecified. For a list tool with sibling ambiguity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is documented as 'The account ID' in the schema, so the structural burden is already met. The tool description adds no additional semantic meaning about the parameter, so the baseline of 3 applies. Some value would have been added by explaining the relationship between account_id and the hostname route scope, but that is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Zero Trust hostname routes'), so an agent can tell it is a read/collection operation. It does not explicitly differentiate itself from siblings like get_zerotrust_hostname_route or list_teamnet_routes, but the singular/plural naming convention and distinct resource term provide implicit separation. It is clear but essentially restates the tool name, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as get_zerotrust_hostname_route, list_teamnet_routes, or list_magic_transit_routes. No conditions, prerequisites, or exclusions are mentioned. An agent must infer the use case entirely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only says 'Get', implying a read operation without stating side-effect profile, required permissions, or response behavior. It does not mention what the settings represent or whether the call is scoped solely by account_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, and for a one-parameter tool that is appropriately compact. It loses the top score only because it adds no structure or elaboration to help an agent beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter read-only getter, the description is minimally viable: an agent knows it is fetching Access mTLS certificate settings for an account. But without annotations, an output schema, or sibling differentiation, it is not fully self-sufficient, particularly around return content and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter account_id already has a description ('The account ID'), so the schema does the documentation work. The tool description adds no parameter semantics beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb ('Get') and resource ('Access mTLS certificate settings'), so an agent can tell this is a settings-getter rather than an individual certificate endpoint. However, it simply restates the function name and does not explain what settings are returned or how it differs from siblings like get_access_certificate or get_account_mtls_certificate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives. The sibling list contains several similar names (get_access_certificate, list_access_certificates, get_account_mtls_certificate), and nothing in the description disambiguates them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get details' implies a read-only operation, but it does not describe the returned shape, not-found behavior, required permissions, or any error/side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though the word 'details' is somewhat generic and could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with fully documented parameters, this is marginally sufficient. However, with no output schema and no mention of how to obtain 'custom_page_id' or what 'details' contains, the description leaves some context for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'account_id' and 'custom_page_id' are already documented in the schema. The description adds no additional parameter semantics beyond identifying the target resource, which matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Access custom page'), clearly stating what the tool operates on. It is distinguishable from the sibling 'list_access_custom_pages', though it does not explicitly call out that it retrieves a single page by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'list_access_custom_pages' or other getter tools. The description only states what it does, leaving the agent to infer selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Get' implies a read operation, but the description does not disclose scope requirements, authorization needs, error behavior, or output structure. It adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant content. It is efficiently structured, though it could have used the space to add sibling differentiation or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the description is minimally viable, but it does not state what the response contains, whether the tag must exist, or how it relates to other Access resources. No output schema exists, so the description could have provided more detail without being excessive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both required parameters are documented in the schema. The description adds no additional semantic meaning, but the schema itself already explains tag_name and account_id, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get details of an Access tag', which identifies a specific verb and resource. It is clear enough to distinguish from 'list_access_tags' by name, but it does not explicitly call out how it differs from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus list_access_tags or other Access-related tools. There is no mention of prerequisites, such as needing the tag_name from a prior list call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It implies a read-only operation through the verb 'Get,' but it does not disclose permissions needed, whether settings are account-wide, or what the response contains. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant phrasing. It is easy to parse, though it could have added a bit more qualification without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation context, and the description does not explain what 'DNS settings' includes or what the response looks like. It is minimally sufficient for passing the single required parameter, but an agent would have little detail about the expected result or how to choose this among many similar DNS tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id fully documented as 'The account ID.' The description adds no additional meaning to the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a concrete resource ('DNS settings') scoped to an account. It is clear in isolation, though it does not explicitly distinguish itself from related DNS tools like get_dnssec, list_dns_records, or get_dns_analytics_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list contains many DNS-related getters, but the description does not clarify that this is the account-level settings tool or mention exclusions such as zone-level settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the get operation without disclosing permissions, absence of side effects, pagination, error behavior, or whether the returned details include sensitive certificate material. 'Get details' provides minimal read-only inference but no substantive behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple get operation, though it sacrifices some useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with a fully documented two-parameter schema, so the description is minimally viable for invocation. However, without an output schema or annotations, the vague term 'details' leaves the return shape unknown, and the huge sibling list increases the need for at least one sentence of routing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both account_id and certificate_id described in the input schema. The description adds little beyond confirming the certificate belongs to an account, so the schema carries the parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact verb ('Get details') and resource ('account mTLS certificate'), so an agent can tell this is a single-resource read operation. It does not explicitly contrast with list_account_mtls_certificates, but the resource scope is specific enough to disambiguate from other get_* certificate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus list_account_mtls_certificates or other certificate-related tools, and no mention of prerequisite calls. An agent must infer from the tool name alone that this is for fetching one already-known certificate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' is a restatement of the operation rather than added transparency: it does not describe the return shape, whether the response includes the rules items or only list metadata, error/404 behavior, or permission requirements. With zero annotation coverage this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no wasted words; the content is front-loaded and easy to parse. It loses the 5 only because it is terse to the point of sacrificing substance — the same space could have held a differentiating phrase about the list-vs-items distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should do more to complete the picture, but it adds nothing beyond the tool name. An agent cannot tell what 'details' includes, what the response will look like, or how this differs from list_account_rules_lists and list_account_rules_list_items — a real risk in a sibling list of several hundred tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the two parameters (list_id, account_id) are already documented in the schema. The description adds nothing beyond the schema — it does not explain that the list is scoped by the account or how the two IDs relate — but it is not required to compensate, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('an account rules list'), making the basic operation clear: retrieve the details of a single account-scoped rules list identified by list_id. It does not, however, distinguish itself from the closely related siblings list_account_rules_lists (which returns all lists) or list_account_rules_list_items (which returns the items within a list), so the meaning of 'details' remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list contains both list_account_rules_lists and list_account_rules_list_items, and the description gives no hint about how to choose among them (e.g., 'to get all lists use X, to get items use Y'). Usage context must be inferred entirely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details,' which implies read-only behavior, but it does not disclose what those details are, whether specific permissions are needed, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It is concise, though somewhat thin in substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to explain what 'details' means and what the response contains. It does not, and it also fails to give any context about how account_id and address_map_id relate. An agent could infer the basic call from the schema, but not the full behavior or result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (account_id and address_map_id) with clear descriptions, and schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get details of an IP address map.' This clearly indicates a read operation on a single address map and distinguishes it from sibling list operations like list_address_maps. However, it does not explicitly mention that the map is identified by account_id and address_map_id, though the schema covers that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_address_maps. The description does not explain whether the caller should first list address maps, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Get details' and adds no context about response shape, read-only guarantees, required permissions, or what specifically is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The core purpose is front-loaded, though the phrasing is close to the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with a fully documented schema, the description is adequate but minimal. There is no output schema and no usage guidance, so an agent gets only the basic intent and must infer context from the tool name and sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already described in the input schema. The description adds no additional parameter meaning, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('details of an AI Gateway dataset'). It is not a tautology, but it does not explicitly differentiate itself from nearby siblings such as list_ai_gateway_datasets or get_ai_gateway_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this retrieves a single dataset while list_ai_gateway_datasets enumerates datasets, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Get details' implies a read-only operation but adds no context about the return payload, not-found/error behavior, or permission requirements. The description is nearly a paraphrase of the tool name and discloses nothing beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words and the core operation is front-loaded. It is appropriately terse, though the same space could have carried routing guidance (e.g., naming list_ai_gateway_evaluations) without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter getter, the definition is minimally adequate: the operation and all parameters are clear. However, with no output schema and no annotations, the description does not explain what 'details' are returned or where evaluation_id comes from, leaving an agent to rely on conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id, gateway_id, and evaluation_id each already documented. The description adds no parameter-level meaning beyond what the schema provides, so the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('details of an AI Gateway evaluation'), making the core operation unambiguous. It correctly implies a fetch-by-ID operation as opposed to a list operation, but it does not explicitly name sibling alternatives like list_ai_gateway_evaluations or get_ai_gateway_logs, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not state that it fetches a single evaluation by ID, nor that evaluation_id would typically come from a prior list_ai_gateway_evaluations call. An agent must infer usage entirely from the parameter names and naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. 'Get details' implies a read-only fetch, but it does not mention whether the call can fail, what happens for a missing instance, authentication requirements, or what kind of detail fields are returned. This is thin behavioral disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler or redundant phrasing. It is front-loaded and easy to parse, though it is minimal in substance. It is efficient but stops short of being a fully informative definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should at least convey the return nature or usage context. It does not mention the two required identifiers, the relationship to list_ai_search_instances, or any expected output. The tool is simple, but the description still leaves an agent guessing beyond 'fetch details.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional parameter meaning, and the schema descriptions are minimal but adequate. Baseline 3 is appropriate because the structured parameter info covers the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get details of an AI Search instance.' It clearly indicates a single-instance retrieval operation and is distinguishable from the sibling list_ai_search_instances by the get/list pattern, though it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus list_ai_search_instances or get_ai_search_job. It does not mention that an instance ID would typically be obtained from a list operation, nor does it describe any prerequisites or preferred usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It only restates the get operation and the zone scope; there is no mention of response format, required permissions, or any side effects. For a read-only tool this is low-risk, but the description offers no behavioral detail beyond what the name and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It stays appropriately short for a simple one-parameter tool, though it sacrifices substance rather than elaborating on the configuration being retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operational surface is small: one required parameter, no nested objects, and no output schema. However, with no annotations and several similarly named sibling tools, the description does not tell an agent what the 'API Gateway configuration' actually contains or how it differs from alternatives, leaving a meaningful gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, zone_id, is already fully described in the schema as 'The zone ID', so schema description coverage is 100%. The description adds no extra meaning about the zone_id format or its relationship to the configuration, but the structured schema carries the burden; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('API Gateway configuration') scoped to a zone, so an agent can infer the operation is a read. However, it does not distinguish this from similarly named siblings like get_api_gateway_settings or get_gateway_configuration, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list contains several closely related tools, including get_api_gateway_settings and get_api_gateway_discovery, but the description does not explain what makes this one the right choice or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the read action and resource name. It implies a safe GET operation but gives no information about what the status represents, whether it reflects enabled/disabled state, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler and the main action is front-loaded. It is concise, though it borders on underspecification because it simply rephrases the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and full schema coverage, the tool has no output schema, no annotations, and no usage context. The bare phrase 'Get API Gateway discovery status' does not explain what the status means or what a caller should expect, leaving a meaningful gap for a tool in a large, confusing sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because zone_id is documented as 'The zone ID'. The tool description adds no additional parameter context beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource construction: 'Get API Gateway discovery status'. It names a distinct resource ('discovery status') that is distinguishable from sibling tools like get_api_gateway_config and get_api_gateway_settings. However, it does not explain what 'discovery status' means, so the purpose is clear at a surface level but not fully elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many related API Gateway tools in the sibling list. No mention of prerequisites, relationships to discovery schemas, operations, or configuration, so an agent gets no help choosing between this and similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get details' weakly implies a read-only operation, but it discloses nothing else: no response format, no existence conditions for the operation, no pagination or error behavior, and no mention of how zone_id scopes the lookup. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler or redundancy. The key information (action and target) is front-loaded and every word earns its place. For a simple get-by-ID tool this size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two params and no output schema, the description is minimally adequate: it states what the tool does and the schema covers the required inputs. However, with no output schema and no annotations, the agent is left guessing what 'details' are returned and how the operation_id should be obtained. A mention of expected return contents or the link to list_api_gateway_operations would complete it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description itself adds nothing about parameters. However, the schema descriptions ('The zone ID', 'The operation ID') are essentially tautological restatements of the parameter names, so the agent gains little real semantic meaning. The description neither compensates for this nor adds any relationship between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('an API Gateway operation'), which clearly identifies the action and target. It does not explicitly distinguish itself from sibling get_api_gateway_* tools like get_api_gateway_config or list_api_gateway_operations, though the 'operation' resource scoping helps. It is close to restating the tool name but expands it slightly with 'details'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_api_gateway_operations or other API Gateway siblings. No context is given about prerequisites, such as whether an operation_id must first be obtained from a list call or whether API Shield must be enabled. Usage context is only weakly implied by the 'Get' verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get' and the target resource, without mentioning read-only behavior explicitly, access requirements, rate limits, or return characteristics beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with no wasted words. It is slightly under-specified but not verbose, which makes it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is minimally adequate: an agent can identify the resource and the required zone_id. However, the large sibling list and absence of annotations mean that a bit more context about what 'schema validation settings' includes or how this differs from sibling tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter zone_id already documented in the input schema. The description adds no additional meaning about the parameter, such as expected format or scope, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('API Gateway schema validation settings'), which is more informative than the bare tool name. However, it does not explicitly distinguish itself from closely related siblings like get_schema_validation_settings or get_api_gateway_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_schema_validation_settings or get_api_gateway_config. The description gives no selection criteria, exclusions, or context about the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only retrieval but does not disclose what details are returned, whether the schema is user-created versus system-defined, or any contextual behavior beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the action and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should help explain what 'details' means, but it does not. It also omits any relationship to sibling list/schema tools and provides no context for how the returned details might be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both required parameters, establishing the baseline of 3. However, the description adds no additional meaning about how zone_id and schema_id relate to the API Gateway user schema context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('an API Gateway user schema'), which makes the tool's primary purpose clear. It also distinguishes itself from sibling 'list' tools by indicating a singular detail lookup, though it does not explain what differentiates a 'user schema' from other API Gateway schema tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like list_api_gateway_user_schemas or list_api_gateway_schemas. An agent is left to infer that this is the singular counterpart to a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explainig behavior. It only restates that this gets a report; it does not disclose whether the report is precomputed or generated on demand, any required permissions, the feed's data scope, or what the response contains. This is a minimal read-operation description with no behavioral detail beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant claims. Every word earns its place, and it clearly states the verb, object, and scope in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must supply enough context for an agent to understand what the tool returns and how to invoke it effectively. It fails to describe what a 'botnet feed report' contains, its time interval, how results are structured, or how it relates to the sibling config/report tooling. The agent is left with only a vague 'report' concept and no return-value guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverade is 100%, so both asn_id and account_id already have descriptions in the input schema. The description's 'for an ASN' reinforces that asn_id is the primary subject but adds no additional formatting, units, relationship, or usage semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('botnet feed report') scoped to an ASN. It is clear, but it does not explicitly differntiate itself from sibling tools like get_botnet_feed_asn_config or get_intel_asn, so it falls one point short of the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_botnet_feed_asn_config, get_intel_asn, or list_intel_indicator_feeds. It does not provide context, conditions, or exclusions, leaving the agent to infer appropriate usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies read-only retrieval but does not disclose output format, error behavior, authentication requirements, or how account_id scopes the lookup. This is minimal disclosure beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It front-loads the action, though the brevity is achieved in part by under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is thin. It does not describe what 'details' are returned, how to obtain a valid logo_id, or how this tool relates to list_brand_protection_logos. The fully documented parameters allow a valid call, but contextual guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema; it does not explain how logo_id relates to list_brand_protection_logos or what entity account_id refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get brand protection logo details.' The required logo_id and account_id make it a single-item getter. However, it does not explicitly differentiate itself from siblings like list_brand_protection_logos or list_brand_protection_logo_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as list_brand_protection_logos or list_brand_protection_logo_matches. The only hints are the 'get' verb and the required IDs, so an agent must infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not mention pagination, authentication requirements, rate limits, or whether the result is a list or single object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or redundancy. It could carry more useful context, but what is present is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, this is minimally viable, but there is no output schema and no annotations to compensate for the lack of return-format or behavior details. The description also does not clarify how cache rules relate to similar constructs like cache settings or zone rulesets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents zone_id with 100% coverage, so the baseline is 3. The description adds no extra parameter context beyond the phrase 'for a zone,' which is already captured by the parameter name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a concrete resource ('cache rules'), and a scope ('for a zone'). It is clear, but it does not explicitly differentiate itself from nearby siblings like get_cache_settings or get_rate_limiting_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, and no exclusions or preconditions are mentioned. Given the large sibling list with similarly named zone-scoped retrieval tools, the agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get details,' which implies a read operation but adds little else. It does not disclose response shape, whether the pack is universal/custom/advanced, or any scoping behavior beyond what the schema already shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It could be slightly richer without becoming bloated, but it wastes no words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool this is minimally viable. However, with no output schema and no annotations, the description leaves the return value unspecified and does not connect this tool to its closely related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds negligible meaning beyond the word 'specific' and does not explain how to derive certificate_pack_id or zone_id in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get details') and resource ('a specific SSL certificate pack'), making the tool's core purpose clear. It is distinguishable from list_certificate_packs by the word 'specific', though it does not explicitly contrast itself with related SSL siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_ssl_settings, get_universal_ssl_settings, or list_certificate_packs. It also does not mention that certificate_pack_id would typically come from a prior list_certificate_packs call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden of behavioral disclosure. It does not explain what the returned details contain, whether any special account permissions are needed, or any other operational behavior. The verb 'Get' implies read-only behavior, but no meaningful behavioral context beyond that is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or redundant clauses. It is efficient, but it is also somewhat under-specified because 'details' is vague and no additional useful structure or context is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a single-resource GET with two required parameters, no output schema, and no annotations. The description does not explain what fields or information the returned event details include, nor does it reference sibling tools like list_cloudforce_one_events for obtaining event IDs. An agent cannot fully anticipate the response shape or operational context from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-specific meaning. The schema already documents event_id and account_id, but both descriptions are generic and do not explain formats, sources, or relationships. The description itself adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('Cloudforce One threat event details'), making it apparent this tool retrieves details for a single Cloudforce One threat event. However, it does not explicitly differentiate itself from siblings like list_cloudforce_one_events or get_cloudforce_one_events_aggregate, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives. There is no mention of using list_cloudforce_one_events first to obtain an event_id, nor any distinction from get_cloudforce_one_request. The usage context must be inferred entirely from the tool name and required parameters, which is effectively no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that this is a 'get' operation, implying a read, but it does not describe the returned configuration structure, error behavior, rate limits, or any other runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is front-loaded with the key verb and resource, though the brevity means it carries little beyond the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves significant gaps: it does not explain what a 'scans configuration' contains, what the tool returns, or how it relates to other Cloudforce One tools. An agent can infer the call signature from the schema but cannot predict the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id with a clear description ('The account ID'), so schema description coverage is 100%. The description adds no further parameter-level detail, matching the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('Cloudforce One scans configuration'), which clearly distinguishes it from sibling tools like get_cloudforce_one_request or get_cloudforce_one_event. It doesn't elaborate on what the scans configuration contains, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many Cloudforce One sibling tools. It does not mention prerequisites, alternatives, or any conditions under which this tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it offers almost none. 'Get details' implies a read-only operation, but the description does not disclose what details are returned, what happens on a nonexistent ID, permission requirements, or any side effects. The description essentially restates what the tool name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler and the verb front-loaded. It is appropriately sized for a simple get-by-id tool. It is slightly lean, bordering on under-specification, but structurally it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter get-by-id tool with no output schema and no annotations, the description is minimally adequate but has clear gaps. It does not indicate the shape or scope of the returned details, nor does it connect the tool to sibling list_cni_interconnects for discovering the ID. The schema covers parameters, but the absence of output schema and behavioral context leaves the agent with only a vague sense of what success looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('The account ID' and 'The interconnect ID'). The tool description adds no parameter-level meaning beyond the schema, which matches the baseline of 3. The parameter descriptions are terse but sufficient for simple ID lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get details of a Cloud Network Interconnect.' It clearly identifies the target resource, distinguishing it from sibling tools like get_cni_settings and list_cni_slots by naming the interconnect resource itself. However, it does not explicitly differentiate itself from the closely related list_cni_interconnects, leaving the get-versus-list distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that interconnect_id might be obtained from list_cni_interconnects first, nor does it clarify when get_cni_settings or list_cni_slots would be more appropriate. The agent is left to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get details' implies a read-only operation but does not state what details are returned, whether the resource can be absent, what errors occur, or whether any scoping or permission requirements apply. The description adds minimal behavioral context beyond the obvious meaning of the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is efficiently written, but it is also quite terse and leaves important usage and behavior details unstated. Conciseness is good, but the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and a generic description mean the agent has little context beyond parameter names. Given the large sibling set and the ambiguity of 'connectivity service,' the description should provide more detail about the resource, return shape, or relationship to list_connectivity_services. The definition is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents account_id and service_id as strings. The description adds no new meaning about how these identifiers relate to a connectivity service or how they should be formatted. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get details of a connectivity service.' This clearly indicates a read operation for a single connectivity-service resource, which is distinct from the sibling list_connectivity_services. However, it does not explain what a 'connectivity service' is, so the meaning is somewhat reliant on domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus list_connectivity_services or other get_* tools. There is no mention of prerequisites, typical query patterns, or exclusions. The agent must infer usage solely from the tool name and sibling list, which is inadequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details', which implies a read operation but does not disclose account-context requirements, output behavior, or error conditions. It restates the tool name without adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler and is appropriately sized for a simple get operation. It is somewhat minimal, but it is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description needs to supply more context. It does not explain what 'details' are returned, how to discover the D1 database_id, or that list_d1_databases is the natural entry point. The sparse description leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id and database_id already described in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get') and resource ('D1 database'), clearly indicating a single-resource read operation. It is clear but does not explicitly differentiate itself from the sibling tool list_d1_databases, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus list_d1_databases or other alternatives. The presence of list_d1_databases among siblings creates a real selection ambiguity, and the description does nothing to resolve it or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of explaining behavior, but it only restates the resource and temporal aspect. It does not disclose return format, time range, aggregation, or any required context beyond account_id. It adds little beyond what the tool name already communicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the description is insufficiently complete for a tool with no output schema and no annotations. It omits important context such as what 'status over time' means, what data points are returned, and how the result relates to the many sibling DEX tools. An agent would need external documentation to understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter, account_id, with a description 'The account ID', so schema coverage is 100%. The tool description does not add additional meaning about the parameter, such as how account_id relates to DEX fleet data, but the schema already documents it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it retrieves DEX fleet status over time. 'Over time' implies a historical time-series view, which helps distinguish it from the sibling tool get_dex_fleet_status_live. However, it does not clarify what 'fleet status' contains or how it is aggregated, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_dex_fleet_status_live or list_dex_fleet_status_devices. The phrase 'over time' weakly implies historical usage, but there are no explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It only restates that the tool retrieves details; it does not disclose response shape, permissions, whether results are historical or live, or any notable side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse to be considered complete. It does not indicate what 'details' are returned, how the test is identified beyond IDs, or any behavior the agent should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters, test_id and account_id, are documented in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Get DEX HTTP test details.' This distinguishes it from related siblings like get_dex_traceroute_test and list_dex_tests_overview at a surface level, though it does not explicitly call out the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_dex_tests_overview or get_dex_traceroute_test. The intended selection criteria must be inferred entirely from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get DEX rule details,' which conveys the read-only nature but does not mention account scoping, error behavior, authentication requirements, or what the response contains. This is minimal transparency beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. Every word earns its place, and the core action and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin to be fully contextual. It does not explain what a DEX rule is, what 'details' will be returned, or how this tool relates to the many sibling DEX tools. Given the large sibling list, more context would help an agent select and use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (rule_id and account_id) with 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (DEX rule details), making it easy to understand what the tool does. However, it does not explicitly distinguish itself from sibling tools like list_dex_rules or other get_* tools, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_dex_rules or get_dex_http_test. An agent would have to infer from the name and parameters alone that this is for retrieving a single rule by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not explain how uniqueness is determined, whether pagination applies, what data is returned, or what authorization/scope requirements exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It is front-loaded with the action and resource, though it provides no structure or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has full schema coverage for its one parameter, but there is no output schema and no behavioral details. The description does not explain what 'unique devices' means, what the response represents, or when to invoke this endpoint over nearby device-related tools, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required account_id parameter, so the schema already documents the only input. The tool description adds no additional meaning or format details beyond the schema's 'The account ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get'), a specific resource ('unique devices'), and a scoping qualifier ('for DEX tests'). However, it does not distinguish itself from sibling tools like list_devices or other device-related read endpoints, so an agent must infer the precise difference from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related siblings such as list_devices, list_device_posture_rules, or list_warp_connectors. The description implies a read operation but does not explain the intended use case or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is a read operation ('Get') but discloses nothing about permissions, response structure, rate limits, or failure behavior. It adds little beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It earns its place but is so terse that it provides minimal additional context beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter getter with no output schema and no annotations, so the description must explain what the agent should expect back and how this relates to sibling DEX tools. It does neither, leaving the tool under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both required parameters with names and descriptions (100% coverage), so the baseline is 3. The description adds no deeper meaning about parameter formats, relationships, or how account_id and test_id interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a domain (DEX), and a subtype ('traceroute'), so an agent can distinguish it from siblings like get_dex_http_test. However, 'test details' is generic and doesn't indicate what kind of details or response shape to expect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_dex_tests_overview or get_dex_http_test, and no mention of prerequisites or context. The usage context is only implicit from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation ('Get') but reveals nothing about what period the report covers, whether it is aggregated or time-bounded, output shape, pagination, or any authorization or quota considerations. For a reporting tool, this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven words, one sentence, verb front-loaded, zero filler — it is efficiently structured. It sacrifices useful context for brevity, but as a stylistic matter there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and roughly 500 siblings including several analytics tools, the description is too thin. It does not clarify what the report contains, what time range it spans, or how it differs from get_zone_analytics and get_dns_firewall_analytics, so an agent cannot confidently select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single parameter zone_id is already documented as 'The zone ID'. The description's 'for a zone' reinforces the schema but adds no new semantic detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('DNS analytics report'), and scope ('for a zone'), so an agent understands the core action and target. However, it does not differentiate from several closely related sibling analytics tools (get_zone_analytics, get_dns_firewall_analytics, get_analytics_by_colo, graphql_analytics), leaving ambiguity about what makes this report DNS-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description never mentions get_zone_analytics, graphql_analytics, or get_dns_firewall_analytics, nor any conditions, exclusions, or prerequisites, so an agent must guess which analytics tool fits its task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. 'Get DNS Firewall analytics' conveys that this is a read operation but does not disclose what metrics are returned, whether a time range is needed, how data is aggregated, or any pagination/response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though the brevity comes at the cost of behavioral and contextual detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the analytics response contains. It does not, leaving the agent uncertain about the shape or meaning of the returned data. For a simple two-parameter tool, the input side is covered, but the output and behavioral side is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both account_id and cluster_id have clear descriptions. The description adds no additional parameter nuance beyond the schema, but the baseline of 3 is appropriate since the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('DNS Firewall analytics') scoped to a cluster. It is sufficiently distinct from cluster configuration tools like get_dns_firewall_cluster, though it doesn't explicitly contrast itself with other analytics tools such as get_dns_analytics_report or get_zone_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when DNS Firewall analytics are needed, but it gives no guidance on when to choose this over the many sibling analytics tools, nor does it mention any prerequisites or exclusions. In a sibling list containing get_dns_analytics_report, get_zone_analytics, and get_spectrum_analytics_summary, an agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. 'Get' implies a read-only operation, but the description does not mention whether there are side effects, what 'status' includes, what authentication is needed, or what errors/responses to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the core verb and resource are front-loaded. It is concise, though slightly too thin to be considered a genuinely rich definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, this is a minimally viable description: the agent knows what to call and which parameter to supply. However, with no output schema and no annotations, it leaves return-value semantics and usage context largely unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single required parameter zone_id already has a description, so the description adds little beyond the schema. 'For a zone' loosely echoes the parameter but does not provide additional semantic detail such as how to find the zone ID or any format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('DNSSEC status') and scopes it to 'a zone', so an agent can tell what operation this performs. However, it does not explicitly distinguish itself from related sibling tools such as get_dns_record or get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only usage signal is the implied situation of needing DNSSEC status for a zone, which is not enough to count as real usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only implies a read operation. It does not mention error behavior, authorization requirements, what 'details' are included in the response, or the relationship to the account_id parameter. The brief phrasing adds little beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence has zero waste and is front-loaded, which is good. However, the brevity is also the source of the problem: it is efficient but structurally thin, providing no context beyond the minimal action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with only two required parameters, the description is mechanically sufficient to make the call. However, with no output schema and no annotations, it fails to clarify what a DNS view is, what details are returned, or how the view_id is obtained (the list_dns_views sibling). The missing sibling relationship is the main gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both view_id and account_id have descriptions), so the baseline of 3 applies. The description adds no parameter-level meaning beyond the schema, but the schema already documents both parameters adequately for a simple get-by-ID operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a DNS view' states a specific verb ('Get') and resource ('DNS view'), making the core action unambiguous. It is distinguishable from the many other get_* siblings because the resource name is specific, though it does not explicitly differentiate itself from the natural counterpart list_dns_views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, what prerequisites exist (e.g., obtaining a view_id via list_dns_views), or how it relates to sibling tools. The agent is left to infer the list-then-get workflow entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states 'Get... details' with no mention of read-only nature, required permissions, error behavior when the pattern doesn't exist, or what details are actually returned. This leaves the agent largely uninformed about side effects and expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is easy to parse and front-loads the action and resource. It wastes no words, though the phrasing 'email security blocked sender details' is slightly clunky but not confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too sparse to fully prepare an agent. It does not say what 'details' are included, whether the result is a single object, how pattern_id maps to a blocked sender, or what happens on missing/invalid input. While the simplicity of the tool limits risk, the minimal context leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters, so baseline is 3. The description adds no additional meaning beyond the schema's 'account ID' and 'pattern ID' labels, and the term 'pattern_id' is not explained (e.g., what pattern it refers to). The description does not compensate for the semantics of how these parameters identify the blocked sender.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the resource ('email security blocked sender'), making it clear this returns details for a blocked sender. It is distinguishable from the sibling list_email_security_block_senders by the singular 'blocked sender' and the required pattern_id, though it does not explicitly state that this retrieves one specific entity by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The sibling list_email_security_block_senders strongly implies this is the single-item variant, but the description does not state that relationship, nor does it mention exclusions or prerequisites. Usage must be inferred from the tool name and parameter shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. 'Get' implies a read-only retrieval with no side effects, which is helpful, but the description does not disclose any other behavioral traits such as required permissions, account context, or what 'details' includes. For a simple getter this is minimally adequate, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no wasted words. However, it is essentially a restatement of the tool name and provides no structural detail or context, so it is concise for the wrong reason: under-specification rather than efficient informative writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with only two parameters and no output schema, but the description is still incomplete. It does not clarify what email security domain details are returned, how this differs from trusted domains, or what account/domain are expected. An agent would need to inspect other tools or API docs to call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both account_id and domain_id. The description adds no additional meaning about how these parameters relate to the domain being fetched, but the parameter names are reasonably self-explanatory, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('email security domain details'), so an agent can tell this is a retrieval operation for a single domain. However, it does not distinguish this from sibling tools like list_email_security_domains or list_email_security_trusted_domains, and 'domain' alone is ambiguous without more context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. An agent is not told to prefer this over list_email_security_domains when a single domain is needed, nor is any exclusion or alternative mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers only the read implication of 'Get'. It does not state what a Phishguard report contains, whether results are paginated, time-bounded, or scoped to the account, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted words. It is appropriately brief for a one-parameter tool, though the brevity comes at the cost of semantic richness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is structurally simple (one required parameter, no nested objects), there is no output schema and no annotations, so the description must explain what the agent will receive. It never defines what a Phishguard report is or what shape the results take, leaving a meaningful gap for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single account_id parameter is described in the schema, so the baseline of 3 applies. The description adds no extra meaning about how account_id is used beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a named resource ('email security Phishguard reports'), making the basic operation understandable — retrieving reports for a particular email security sub-product. However, it does not differentiate this from adjacent email-security siblings like list_email_security_submissions or list_email_security_investigate, and 'reports' is never unpacked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus the many related email security tools in the sibling list. No context, exclusions, or alternative tool names are mentioned, leaving the agent to guess which retrieval path is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read operation, but the description does not disclose account-scoped requirements, return shape, or any caveats about the configuration response. It largely restates what the name already signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise and easy to parse, though it sacrifices useful context that could have been added without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET-like tool, this is minimally adequate: the schema covers account_id and the description identifies what is being fetched. However, with no output schema and no annotations, there is no information about what specific configuration fields will be returned or any prerequisites beyond account_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required account_id parameter, so the schema already documents it adequately. The description adds no parameter-level detail, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('Zero Trust Gateway configuration settings'), which goes beyond the tool name by naming the product area. It is distinct from most siblings, though it does not explicitly differentiate itself from closely related getters like list_gateway_rules or get_api_gateway_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling getters, nor any indication of when it should not be used. The intended usage is only implied by the verb and resource in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source for side-effect and return behavior. 'Get details' implies a read-only retrieval, but it does not state that explicitly, does not describe the response, and discloses no edge cases or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and front-loads the action and object. It contains no filler, though it is too terse to earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter getter with complete schema coverage, the description minimally suffices. However, with no output schema it does not describe what 'details' means, and it does not clarify zone scoping or the relationship to the healthcheck list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and the resource 'a healthcheck', making it clear that this is a single-object retrieval rather than a list operation. It does not explicitly contrast with the sibling get_endpoint_healthcheck, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this instead of list_healthchecks or get_endpoint_healthcheck. The agent must infer from the 'get' verb and the healthcheck_id parameter that this is the by-ID detail fetch, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get details', which hints at a read operation but does not describe idempotence, response shape, required permissions, or any side effects. This is minimal behavioral information 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant wording. It is front-loaded with the verb and object. It could earn a 5 if it included more useful context, but as written it is concise without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and no description of return values beyond the vague word 'details'. The schema tells the agent what parameters to send, but the description does not explain what the response contains or how this relates to list_hyperdrive_configs. This leaves the agent under-informed for interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, including types, requirements, and descriptions. The description adds no additional parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Get details of a Hyperdrive configuration'. It conveys that this tool retrieves a single configuration's details, which distinguishes it from the sibling list_hyperdrive_configs. However, it does not explicitly state that it fetches one specific record by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus list_hyperdrive_configs or other getters. The tool's purpose is implied by the name, but the description gives no context about prerequisites, such as needing an existing hyperdrive_id, or when exactly to choose this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a retrieval operation; it does not mention output format, data sources, account scoping behavior, rate limits, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It is front-loaded and easy to parse, though it sacrifices informational content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what intelligence is returned, what account_id is used for, and how this tool differs from similar intel tools. The current description is too thin for an agent to confidently predict the tool's behavior or response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional meaning beyond restating that the tool is about ASN information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get intelligence about an ASN'. It clearly identifies the target object and is distinguishable from sibling tools like get_intel_domain and get_intel_ip by the resource type. However, the term 'intelligence' is vague and does not specify what subset of ASN data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related tools such as get_intel_domain, get_intel_ip, or get_intel_whois. No context, prerequisites, or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation at a high level and does not mention required account_id, whether domain is truly optional despite being the query target, or what type of intelligence the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and is appropriately front-loaded. It is brief to the point of under-specification, but the conciseness itself is handled well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a large sibling list full of similar intel tools, the description is too incomplete. It fails to explain the account_id requirement, the semantics of 'domain,' or the expected result shape, and it gives no way to tell this endpoint apart from get_intel_domain_history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level meaning. The description does not clarify the odd schema situation where account_id is required while domain, the actual query subject, is marked optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'get,' applied to the resource 'domain,' which is clear enough to distinguish it from most of the huge sibling list. However, it does not differentiate it from closely related intel endpoints like get_intel_domain_history, and 'intelligence' is vague about what specific data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many similar intel-related siblings such as get_intel_whois, get_intel_domain_history, or get_intel_ip. The only usage signal is the implied context of querying a domain, with no exclusions, prerequisites, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not disclose what data is returned, whether this is DNS history, WHOIS history, or threat history, or what account permissions are needed. With no output schema, the agent lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core action is front-loaded. It earns its place by stating the basic purpose. The brevity is efficient, though it leaves out useful context that could have been added without making the description bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although this is a simple one-parameter tool, the description is not complete enough because there is no output schema and no annotation. It should at least clarify what 'history intelligence' means and what kind of data the agent can expect. Without that, an agent cannot confidently distinguish this tool from related intel tools or anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, account_id, is documented with 'The account ID'. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies. This is acceptable because the schema already provides the necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a resource ('domain history intelligence'), so an agent can tell this is a read operation for historical domain data. It is concise and slightly more specific than the raw tool name, though it does not define what 'history intelligence' actually includes. It is distinguishable from siblings like get_intel_domain or get_intel_whois mainly by the word 'history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives such as get_intel_domain, get_intel_whois, or get_intel_asn. There are no exclusions, conditions, or examples. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only conveys that this is a read-style 'Get' operation and says nothing about return shape, permissions, rate limits, scoping, or what 'details' actually include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately concise, though the brevity also contributes to missing useful context that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should compensate by explaining what details are returned, how the feed is scoped to an account, or how to discover feed_id. It does none of this, leaving the agent to infer critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional meaning about feed_id or account_id, but it does not need to because the schema handles that responsibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('details of a threat indicator feed'). It is reasonably distinct from sibling list_intel_indicator_feeds because it implies a single feed, though it does not explicitly name or contrast that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_intel_indicator_feeds or the other get_intel_* siblings. The only implied context is the singular 'a threat indicator feed', but the description offers no conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation through the verb 'Get' but does not explain what the returned intelligence looks like, whether account_id scoping affects results, what permissions are needed, or whether both ipv4 and ipv6 can be queried together.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no padding, and the key resource is front-loaded. It is concise, though its brevity comes at the cost of behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully covers the parameters, but the description does not explain the nature of the intelligence, the response format, or the relationship between this tool and the many Intel-related siblings. Without an output schema and with no annotations, the description leaves significant contextual gaps for an agent deciding whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters clearly, including the required account_id. The description adds no parameter-level meaning beyond the phrase 'an IP address,' so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('an IP address'), which distinguishes it from sibling tools like get_intel_asn and get_intel_domain. However, 'intelligence' is broad and does not specify what kind of intelligence is returned (reputation, threat data, geolocation, etc.), so it is clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_intel_domain, get_intel_asn, or get_intel_whois. The context is only implied by the name and sibling list, with no explicit selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Get details' implies a read, but it does not state that the operation has no side effects, what happens for a missing namespace, or what the returned details contain. This is too thin to fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and the key idea is front-loaded. It is appropriately brief for a simple two-parameter getter, though it sacrifices behavioral richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what 'details' actually include or what the response looks like. It only says 'details' without specifying namespace metadata, so an agent cannot predict the return shape or interpret the result confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds no extra meaning about how account_id or namespace_id should be formatted or where they come from, but the schema covers the essential semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('a KV namespace'), so an agent can tell it retrieves a single namespace rather than listing namespaces. It doesn't explicitly name sibling tools like list_kv_namespaces or distinguish itself from list_kv_keys, so it stops short of the strongest scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over list_kv_namespaces or list_kv_keys, and no indication that a namespace must already exist or that account_id/namespace_id should be obtained from a prior call. The description leaves all usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states 'Get details', which indicates a read operation but adds no context about response contents, potential 404 errors, scoping requirements, or how this differs from the details returned by list_legacy_rate_limits. The description essentially restates the tool name without adding meaningful behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded with the action and resource, and every word contributes to the meaning. This is exemplary conciseness for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the primary source of context beyond parameter names. It doesn't explain the response shape, error behavior, or relationship to other rate-limiting tools. For a tool with two required parameters, the description is minimally sufficient but leaves an agent without guidance on how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (zone_id and rate_limit_id) are already documented in the input schema. The description adds no additional meaning about how the parameters relate or how to obtain the rate_limit_id. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as a single legacy rate limit rule, which distinguishes it from list-style siblings like list_legacy_rate_limits and from modern rate limiting tools like get_rate_limiting_rules. However, it doesn't explicitly name or contrast with those siblings, so the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_legacy_rate_limits or get_rate_limiting_rules. It doesn't mention that the rule ID would typically be obtained from a list call first, nor does it note any prerequisites or exclusions. The only implied usage is that a specific rate_limit_id is needed, which is already obvious from the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Get,' which merely implies read-only behavior. It does not disclose response format, authorization needs, rate limits, or any additional operational traits beyond what the name itself already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It is concise, though slightly under-specified in substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET-like tool, the description conveys the basic intent and the required zone_id is documented in the schema. However, with no output schema and no annotations, it does not explain what the returned managed headers configuration contains, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and zone_id is already described as 'The zone ID.' The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('managed request/response headers configuration'), making the tool's purpose clear. However, it does not explicitly distinguish it from similarly named siblings like get_request_header_rules and get_response_header_rules, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer usage entirely from the tool name and the minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates that the tool retrieves a configuration; it does not mention that it is read-only, whether special permissions are required, or what kind of response is returned. For a simple getter this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though it is also very minimal and does not use the available space to add usage or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with one required parameter and no output schema, so a short description is somewhat sufficient. However, without annotations or an output schema, the description could have included at least a brief note about what the configuration contains or that this is an account-level read, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter account_id already described as 'The account ID'. The description adds no additional meaning about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('Magic Network Monitoring configuration'), so an agent can tell this is a read operation for that configuration resource. It does not explicitly differentiate from sibling tools like get_mnm_rule or list_mnm_rules, but the 'config' wording makes the target reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_mnm_rule or list_mnm_rules. No prerequisites, context, or exclusions are provided, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral context itself, but it merely says 'Get details.' It implies a read operation but does not state whether it is side-effect-free, what errors may occur, what permissions are needed, or what kind of details are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is a single, concise sentence with no redundant wording, and the key action is front-loaded. It is appropriately sized, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-identifiers oparation the description is minimally adequate, but there is no output schema and no mention of response shape, not-found behavior, or the relationship to list_pages_projects. It works as a stub but leaves routing and recovery context to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, describing account_id as 'The account ID' and project_name as 'The project name.' The description adds no extra semantic nuance about how these identifiers relate or how the user should supply them, so it stays at the high-coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a clear verb ('Get') and resource ('Pages project'), so an agent can infer it is a singular read operation. It does not explicitly contrast itself with list_pages_projects or list_pages_deployments, but 'get' versus 'list' provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool rather than list_pages_projects or list_pages_deployments. There is no mention of prerequisites, e.g., that the project_name must already exist, or that listing should be done first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get packet capture ownership info' only restates the operation implicitly; it does not explain what ownership info contains, whether it returns data for all PCAPs under the account, or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single six-word sentence with zero filler; the subject and operation are front-loaded. It is efficient, though it borders on under-specification given the complete absence of supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should clarify what 'ownership info' means and how the result is structured. With only one parameter and low structural complexity, the tool is simple, but the description still leaves an agent unable to predict the response or the tool's relationship to get_pcap/list_pcaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the account_id parameter is already fully documented in the schema. The description adds no parameter-level meaning beyond the schema, which is acceptable at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('packet capture ownership info'), making the basic operation clear. However, it does not differentiate from closely related siblings like get_pcap and list_pcaps, so an agent cannot tell what makes 'ownership info' distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_pcap or list_pcaps. Given the large sibling list with several packet-capture-related tools, the absence of any routing or exclusion context leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. 'Get details' implies a read operation, but it does not explain what details are returned, how errors like missing queues are handled, or whether account-level permissions are required. The description adds minimal behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It is appropriately concise for a simple get-by-ID tool, though it could have been slightly more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read operation, the description is minimally viable, but it does not mention the output shape, response contents, or how the queue_id is obtained. Since no output schema exists, some additional context about what 'details' include would improve completeness without much extra length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, with clear descriptions for account_id and queue_id. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('details of a Cloudflare Queue'), making the tool's purpose immediately understandable. It does not explicitly differentiate from the sibling list_queues, but 'details of a Cloudflare Queue' strongly implies fetching a single queue rather than listing all queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites such as obtaining the queue_id from list_queues, and no mention of when not to use it. The sibling list_queues is an obvious alternative, but the description never acknowledges this relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Get Realtime Kit meeting details' and adds no information about read-only guarantees, authorization requirements, error behavior, or what exactly constitutes 'details.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is appropriately short, though slightly underspecified in ways that reduce its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For s simple get-by-id tool, the description is minimally viable: an agent can infer that it retrieves meeting details for the given IDs. However, with no output schema and no annotations, the description could usefully mention what type of meeting details are returned or how this differs from listing meetings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear one-line description. The tool description adds no additional meaning about the parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and specifies the resource ('Realtime Kit meeting details'), so an agent knows what operation this performs. It does not explicitly distinguish itself from nearby siblings like list_realtime_meetings or get_realtime_session, though the noun 'meeting' narrows the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus list_realtime_meetings, get_realtime_session, or get_realtime_recording. The description also does not mention that account_id, app_id, and meeting_id are all required, or how an agent should discover the meeting_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that it gets session details. It does not reveal anything about response content, permissions, side effects, or how 'details' differ from summary or transcript data, though it does at least imply a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant wording. It is appropriately short for a simple get-by-ID operation, though it sacrifices some useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read operation, the description plus fully documented schema provides a minimal viable definition. However, with no output schema and no relation to nearby session tools, the description leaves some ambiguity about what 'session details' actually returns and when to prefer this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The tool description adds no additional meaning about the parameters, which is acceptable given the complete schema coverage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Realtime Kit session details'), making the core intent clear. It is distinguishable from list_realtime_sessions and get_realtime_session_summary, though it does not explicitly call out those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like get_realtime_session_summary, get_realtime_session_transcript, or list_realtime_sessions. The description does not mention alternatives, prerequisites, or contextual use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the 'get' action and 'summary' resource without disclosing read-only nature, return contents, time range, or any other behavioral characteristics. 'Get' weakly implies read-only but this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundant wording. It is front-loaded and efficient, though it is so terse that it omits useful context that is penalized under other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only three simple parameters and no output schema, complexity is low, but the absence of any detail about what a 'summary' returns, and no contrast with nearby realtime session tools, leaves the agent guessing. The description is too minimal to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all three parameters with basic descriptions (100% coverage), so the description does not need to add parameter details. The description adds no extra semantic information, but the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('Realtime Kit session summary'), which distinguishes it from a full session fetch like get_realtime_session. However, it does not explain what the summary contains, leaving some ambiguity about the exact resource shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus closely related siblings such as get_realtime_session or get_realtime_session_transcript. An agent has no basis to decide whether a summary, full session, or transcript is the appropriate call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get...'. It does not explain what the returned transcript contains, whether the session must be completed, how the transcript is formatted, or whether there are any side effects. 'Get' implies a read operation, but key behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler, repetition, or unnecessary detail. It is appropriately sized for the simple retrieval operation and front-loads the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation coverage, so the description needs to explain what a transcript response contains or how this tool behaves. It does not. While the parameters are fully covered by the schema, the missing return-value semantics and lack of sibling differentiation leave the definition incomplete for an agent choosing and invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the three parameters are already documented as account ID, app ID, and session ID. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('Realtime Kit session transcript'), which is distinct enough from sibling tools like get_realtime_session and get_realtime_session_summary. It is not vague or tautological, though it relies mostly on the tool name to make the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related alternatives such as get_realtime_session, get_realtime_session_summary, or list_realtime_sessions. The description only implies the obvious use case of getting a transcript and does not mention prerequisites, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure, yet it discloses nothing beyond what the verb 'Get' implies: a read operation. It does not describe the response shape, not-found behavior, authentication requirements, rate limits, or side-effect profile. The wording is nearly tautological with the tool name, adding only 'Kit' and 'details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five words, one sentence, with zero filler, and the verb-resource pair is front-loaded. It is appropriately compact for a trivial single-resource fetch. It loses a point because the brevity comes at the expense of substance that other dimensions (usage guidance, behavioral context) needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read with three required, fully schema-documented parameters and no nested objects, the description is minimally adequate. However, with no output schema and no annotations, the return shape ('details' content) and error behavior are left completely unspecified, which are real gaps an agent would face when interpreting the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id, app_id, and webhook_id each have meaningful schema descriptions — so the baseline of 3 applies. The description adds no parameter-level semantics (e.g., that the webhook belongs to the app within the account), but it does not need to compensate since the schema already documents every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('Realtime Kit webhook'), which is unambiguous and distinguishes it from sibling getters in the same product family like get_realtime_livestream, get_realtime_meeting, and get_realtime_recording. The noun 'webhook' clearly differentiates it from list_realtime_webhooks by implying a single-item fetch. It stops short of 5 because it never explicitly states the single-item scope and 'details' is vague about what is actually returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not state conditions for choosing this over list_realtime_webhooks, nor any prerequisites or context (e.g., the webhook must belong to the specified app_id). Usage must be inferred entirely from the schema requiring a webhook_id and from the get-vs-list sibling naming convention, which is weak evidence at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get details,' implying a read operation, but does not describe the return format, required permissions, error cases, or any side-effect-related behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words, and it front-loads the core action and resource. It is appropriately short for a simple getter, though it lacks any surrounding context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with no output schema, the description is minimally adequate: it names the resource and the schema covers the required inputs. However, it offers no detail about what 'details' are returned or how to choose this over list_registrar_domains, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a domain in Cloudflare Registrar'), making the tool's purpose immediately understandable. However, it does not explicitly distinguish itself from sibling list_registrar_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The sibling tool list_registrar_domains exists and would be the natural alternative, but the description does not mention it or any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies read-only behavior, but the description doesn't confirm this, doesn't state what 'details' are included in the response, and doesn't mention error behavior for invalid IDs or permission requirements. The behavioral profile is left entirely to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with the verb and resource stated immediately and zero wasted words. It is appropriately sized for a simple get-by-ID tool, though the brevity reflects minimal content rather than rich, distilled information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter get tool with full schema coverage, this is minimally viable. However, with no output schema and no annotations, the agent cannot anticipate the return structure, confirm read-only safety, or understand how this tool relates to list_resource_groups. These gaps leave the definition barely adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both account_id and group_id documented in the schema itself. The description adds no meaning beyond the schema — it doesn't clarify the relationship between the two parameters or that account_id scopes the group lookup, but the baseline of 3 applies since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of an IAM resource group' states a specific verb (get) and resource type (IAM resource group), clearly conveying single-entity retrieval. The 'IAM' qualifier and 'get' vs 'list' verb pattern help distinguish it from the sibling 'list_resource_groups', though the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The sibling 'list_resource_groups' exists for enumeration, and 'get_permission_group' is a similar get-by-ID pattern, but nothing in the description helps an agent choose among them. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates a read operation through the word 'Get' but adds nothing about required zone context, response shape, error behavior, or the relationship between the zone_id and ruleset_id. This is thin for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is appropriately short, though it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. It does not clarify the zone-scoped nature of the ruleset, how to distinguish this from get_account_ruleset, or what will be returned. An agent would need to infer too much, especially given the large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both zone_id and ruleset_id already described in the schema. The description adds no additional meaning for the parameters, so the baseline score of 3 applies—the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Get details of a specific ruleset,' identifies a clear verb ('Get') and resource ('specific ruleset'). However, it does not specify whether this is a zone-level or account-level ruleset, which matters given the sibling tool get_account_ruleset exists, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_zone_rulesets or get_account_ruleset. The description only states the basic action and gives no context about prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only restates the read-only nature already implied by 'Get'. It does not mention required permissions, response format, potential errors, or side effects, offering little beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused phrase with no filler, making it concise and easy to parse. However, it is so thin that it misses an opportunity to use the available space to add context about the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET operation, the description is minimally adequate: an agent can infer it needs a zone_id and will receive configuration data. But with no annotations, no output schema, and no relationship to sibling tools, the description lacks broader context about what the configuration contains or when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, zone_id, is already documented as 'The zone ID'. The description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('secondary DNS incoming zone transfer configuration'), so the action and target are unambiguous. The 'incoming' qualifier distinguishes it from sibling tools like get_secondary_dns_outgoing and get_secondary_dns_primary, though it does not explicitly call out those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus related secondary DNS tools, such as get_secondary_dns_outgoing or list_secondary_dns_peers. No context, prerequisites, or exclusions are provided, leaving the agent to infer the appropriate situation from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get details' conveys a read-only single-item fetch, but nothing else: it doesn't state whether secret values are returned or just metadata, what happens for invalid IDs, or whether sensitive material is involved. The description does not contradict annotations (there are none), so no contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. It is appropriately sized for a simple get-by-id operation, though the space saved could have been used to add a sibling distinction or return-format note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not clarify what 'details' means, and the presence of list_secrets_store_secrets in the sibling list makes the metadata-versus-values distinction potentially important. Two required parameters are documented, but the operational semantics are thin for a tool touching secrets infrastructure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (store_id and account_id) already have descriptions in the schema. The tool description adds no meaning beyond the schema, such as clarifying which parameter is the primary key or how the two relate. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('secrets store'), and a specific scope ('details'). This distinguishes it from siblings like list_secrets_stores (which enumerates stores) and list_secrets_store_secrets (which enumerates secrets within a store), though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool versus list_secrets_stores or list_secrets_store_secrets, nor any prerequisite such as needing the store_id from a prior list call. An agent must infer the usage context entirely from the tool name and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It only implies a read operation via 'Get' and says nothing about response format, pagination, time window, metric definitions, or authorization requirements. This is minimal transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler, and the key action and resource are front-loaded. It could be slightly more informative, but it is appropriately concise for a simple two-parameter read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and no output schema, the description is mostly serviceable. However, it leaves ambiguity about what 'speed trends' contains, what time range is used, and what the returned data looks like, so an agent would need additional context to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage: url and zone_id each have descriptions. The tool description adds no further parameter-specific meaning beyond the notion of 'a page' corresponding to the URL parameter, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and target: 'Get speed trends for a page over time.' It indicates the resource (page speed trends) and the temporal nature of the data, which broadly distinguishes it from single-test tools like get_speed_test. However, 'speed trends' is not fully defined regarding which metrics or time period are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related siblings such as get_speed_test, list_speed_tests, or get_speed_schedule. The phrase 'over time' implies historical trend data, but no explicit alternatives, exclusions, or selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details of a specific speed test' adds little beyond the tool name; it does not state the response format, whether the operation is read-only, or any prerequisites like having an existing test_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is short, front-loaded, and free of filler words, which is appropriate for a simple getter. While it could be expanded with usage context, as a concise statement it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is the only source of operational context. It does not explain where test_id comes from, how this tool relates to list_speed_tests, or what 'details' will be returned, leaving an agent without enough context to confidently invoke it among many similar getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (url, test_id, zone_id) with descriptions, giving 100% schema coverage. The description adds no additional parameter relationships or contextual meaning, matching the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource as 'a specific speed test', which distinguishes it from the sibling list_speed_tests. However, it does not clarify what 'details' encompasses relative to other speed-test siblings, so differentiation is present but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to call this tool versus list_speed_tests, get_speed_schedule, get_speed_page_trend, or other related endpoints. The intended workflow, such as needing a test_id from list_speed_tests first, is only implicit and never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' simply restates the get operation implied by the tool name and does not disclose response shape, error behavior, permissions, or what 'details' specifically include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words and the core operation is front-loaded. It is concise, though slightly too skeletal to fully communicate the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not clarify what 'details' means or what the response will contain. It also does not help an agent distinguish this from list_stream_videos, so the overall context is incomplete for a tool that relies entirely on its description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters already have basic descriptions ('The video ID', 'The account ID'). The tool description adds no additional meaning to the parameters, so it stays at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('a Stream video'), so an agent can tell this is a retrieval operation for a single Stream video. It does not explicitly contrast itself with sibling tools like list_stream_videos, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives. The description does not mention when a caller should have a video_id, nor does it distinguish this from list_stream_videos or other video-related retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation via 'Get', but does not disclose prerequisites, whether the feature must be enabled, response contents, or any notable behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the verb and resource front-loaded. It wastes no words, though it misses an opportunity to add useful differentiating context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with no output schema, the description is mostly sufficient to invoke the tool. However, with no annotations and no statement of what the returned settings represent or when to use this over related TLS tools, some contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes zone_id, and the description reinforces that the settings are zone-scoped. It adds no additional semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('Total TLS settings'), and a scope ('for a zone'), with the Advanced Certificate Manager context. This makes it clearly distinct from a generic settings getter, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_ssl_settings, get_universal_ssl_settings, or get_zone_settings. The only usage signal is the resource name, leaving the agent to infer which endpoint is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds nothing beyond what the tool's name already implies: no mention of read-only semantics, what kinds of details are returned, whether tunnel configuration or connection state is included, or any prerequisite (e.g., tunnel must exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. It is efficiently written, though arguably so terse that it barely adds value beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two fully documented required parameters, the definition is minimally adequate. However, without an output schema, the term 'details' is ambiguous — it could mean tunnel status, configuration, or connection info — and the description does not resolve that ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both tunnel_id and account_id have descriptive text in the schema. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('Cloudflare Tunnel'), making the core action clear. However, it does not differentiate from sibling tools like get_tunnel_configuration or list_tunnel_connections, so an agent may not know which tunnel-related tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes list_tunnels, get_tunnel_configuration, and list_tunnel_connections, but the description gives no hint about which scenario calls for 'details' vs. those other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It implies a read-only operation via 'Get' and hints at the response contents ('ingress rules'), but it does not state whether permissions are required, how the response is shaped, or any other behavioral traits. It avoids contradiction, but leaves most behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The parenthetical '(ingress rules, etc.)' is slightly vague but adds useful scope information without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with two well-documented parameters, the description is minimally viable. However, with no output schema and no annotations, it leaves unstated what the full configuration includes and how this tool differs from get_tunnel, so an agent may still need to inspect the sibling or the API response to be confident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both tunnel_id and account_id clearly described, so the schema already carries the parameter semantics. The description adds no parameter-specific detail, which is acceptable and earns the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), resource ('configuration for a Cloudflare Tunnel'), and content area ('ingress rules, etc.'). This makes the tool's function clear, but it does not explicitly distinguish it from the sibling get_tunnel, which could also be interpreted as retrieving tunnel details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives such as get_tunnel, list_tunnels, or list_tunnel_connections, and no exclusion criteria. Usage context is only implied by the tool name and the generic 'Get configuration' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get details', which is essentially restating the operation already implied by the tool name, and it adds no context about response contents, side effects, permissions, or error behavior. It is not misleading, but it 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and front-loads the main action. It is readable and to the point, though its brevity sacrifices useful context that would improve other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the schema covers the required inputs, and the description clarifies the resource type. However, with no output schema and no mention of what 'details' means or when to choose this over list_turnstile_widgets, the description leaves notable gaps. An agent can still call it correctly, but not with full confidence about the result or context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions, giving 100% schema coverage, so the baseline of 3 applies. The description adds no extra meaning about how account_id or widget_id should be obtained or formatted. It neither helps nor hurts beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('details of a specific Turnstile widget'). The word 'specific' helps distinguish it from the sibling list_turnstile_widgets, so an agent can tell this is a single-item getter rather than a list operation. It does not enumerate what details are returned, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_turnstile_widgets. There are no prerequisites, no selection criteria, and no exclusion conditions mentioned. The word 'specific' weakly implies a prior lookup but does not constitute clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but it doesn't state whether the response is a list or single object, whether pagination applies, or what 'rewrite/transform rules' encompasses. This is minimal behavioral context for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words or filler. It front-loads the core action and resource, but the overall thinness means it sacrifices useful detail rather than intentionally omitting redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one fully documented parameter, there is no output schema and no behavioral or usage context. An agent would not know what the returned rules look like, whether the result is paginated, or how this tool relates to the many sibling rule-related getters, so the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents zone_id. The description adds only 'for a zone', which is a restatement of the parameter's purpose and doesn't provide additional semantic detail beyond what the schema supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('URL rewrite/transform rules'), and a scope ('for a zone'), so an agent can tell what the tool operates on. It doesn't explicitly call out differences from sibling rule getters like get_origin_rules or get_request_header_rules, but the resource name is reasonably distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_url_normalization, get_request_header_rules, or list_page_rules. No prerequisites, exclusions, or context signals are provided, leaving the agent to infer the appropriate selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get details' and does not mention authentication requirements, response contents, error behavior, or whether any state is changed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant content. It could be more informative, but it is appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description does not explain what 'details' are returned, how to obtain a connector_id, or how this tool relates to nearby sibling tools. The description is minimally viable but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds no additional meaning about what account_id or connector_id represent or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('WARP connector'), so an agent can tell it is a fetch operation for a single connector. However, it does not distinguish itself from similar sibling tools like get_magic_transit_connector or list_warp_connectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention that list_warp_connectors could be used to discover the connector_id, nor does it explain how this differs from related connector getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden, but 'Get details of a Worker build' only communicates a generic read operation. It does not explain what kind of build information is returned, how builds relate to Worker scripts or deployments, or any relevant statefulness, such as whether builds expire or require special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is concise and easy to parse, though it is terse enough that some behavioral and contextual information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter get operation, the description is minimally viable, but it omits important context such as what 'details' includes, how to discover valid build IDs, and how this tool differs from get_worker_script or list_worker_builds. The absence of an output schema further increases the need for richer description, so this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters with 100% coverage ('The build ID', 'The account ID'), so the schema already carries the semantic weight. The description adds no additional parameter context, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Worker build'), and the singular 'details' makes clear this is a fetch-by-ID operation rather than a list operation. It does not explicitly distinguish itself from sibling tools like list_worker_builds or get_worker_script, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as list_worker_builds or get_worker_script. The description only states the action and resource, leaving the agent to infer the appropriate selection criteria from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, but it only states 'Get metadata,' which weakly implies a read operation. It provides no detail on what kind of metadata is returned, permission requirements, rate limits, or error behavior, so the agent has little to go on beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clean sentence with zero wasted words, front-loading the verb and resource. It is appropriately sized for a two-parameter get tool, though it is on the terse side and could add a few words of differentiation value without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple get-by-script tool whose parameters are fully documented by the schema. However, with no output schema and no annotations, the description leaves the nature of the returned metadata, usage context versus list_workers, and any error or permission behavior unexplained — gaps that matter less for a read tool but are still present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both account_id and script_name are already documented in the input schema. The description adds no parameter-level detail, but none is strictly required at this coverage level, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get'), a resource ('metadata for a specific Worker script'), and a single-item scope via 'specific', which distinguishes it from the sibling list_workers. However, 'metadata' is somewhat vague about what exactly is returned, and it doesn't explicitly distinguish from get_worker_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The word 'specific' weakly implies it should be used when a particular script_name is known rather than listing all workers, but no alternatives or exclusions are named, leaving the agent to infer the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only repeats the core idea of fetching details and adds no information about response shape, errors, permissions, or whether the operation is read-only. There is no value beyond the tool's name and obvious purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is tightly written, front-loaded, and contains no filler. It uses only a few words to communicate the resource type and action, which is appropriate for a simple two-parameter retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is thin. It tells the agent the action and resource, but does not indicate what 'details' will be returned, how to discover a workflow name, or what makes this endpoint distinct from related workflow and instance tools. The simple parameters help, but the surrounding context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (account_id and workflow_name) with 100% coverage, so the description does not need to add much. It adds no extra context about naming conventions, id formats, or relationships between the parameters, but the schema already covers the essential semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and a specific resource ('Workers Workflow'), which clearly distinguishes it from list operations like list_workflows and from get_workflow_instance. It is concise and identifiable, though it does not explicitly contrast with the workflow-instance variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of list_workflows, get_workflow_instance, or list_workflow_instances. No preconditions, exclusions, or alternatives are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It does not state read-only semantics explicitly, auth requirements, error behavior, or what the returned configuration contains. The verb 'Get' only implies non-mutation; no behavioral detail is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One seven-word sentence with zero filler and verb-first structure. It is appropriately sized for a single-parameter getter, though the brevity comes at the cost of behavioral and contextual detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a very simple one-param read, but with no annotations, no output schema, and no indication of what a Zaraz config contains, an agent cannot anticipate the response shape or any special access needs. For a niche resource some orientation would materially help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—the sole parameter zone_id already has type, length, and a description in the schema. The description's 'for a zone' merely echoes that parameter and adds no format, scope, or constraint detail. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a named resource ('Zaraz configuration') scoped to a zone, which is clear on its face. It distinguishes from sibling config getters like get_mnm_config or get_api_shield_config by naming the unique Zaraz resource. However, it never explains what Zaraz is or what the configuration contains, so an agent unfamiliar with the feature gets no orientation beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus other configuration getters in the sibling list, no prerequisites, and no mention of exclusions or alternatives. Usage context is left entirely to inference from the name 'Zaraz'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get ... details' implies a read-only operation, but it does not disclose response behavior, error conditions, authentication expectations, or any side effects. The description adds almost no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It is easy to parse and front-loads the operation. It is slightly sparse, but for a simple getter it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with fully documented parameters, this is minimally viable, but there is no output schema and no description of the response shape or content. The description also does not mention how the agent should obtain a valid hostname_route_id, such as by listting routes first. It is complete enough for the basic call but leaves the agent without context about the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both account_id and hostname_route_id have clear descriptions in the schema. The description adds no additional parameter semantics, but per the baseline rule, the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('Zero Trust hostname route details'). It clearly indicates a read operation for a single hostname route, which distinguishes it from the sibling list_zerotrust_hostname_routes. It does not explicitly state that the route is identified by ID, but the schema and name make this reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_zerotrust_hostname_routes or get_zerotrust_connectivity_settings. There is no mention of prerequisites, such as retrieving a hostname_route_id from a list operation first. Usage context is only implied by the tool name and verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It only says 'Get analytics dashboard data' and does not explain whether this is read-only, what time-range defaults apply, what the response contains, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds meaning: 'Get' names the action, 'analytics dashboard data' names the result, and 'for a zone' names the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is incomplete. It does not clarify what kind of analytics are returned, how the time window behaves, or how it differs from sibling analytics tools, leaving an agent to guess whether this is the right endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents zone_id, since, and until with meaningful descriptions. The tool description adds no parameter-level details beyond implying zone scope, which is expected and acceptable at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('analytics dashboard data for a zone'), so an agent understands the basic operation. However, it does not differentiate this from sibling analytics tools like get_analytics_by_colo or graphql_analytics, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many analytics-related siblings. There is no mention of alternatives, exclusions, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only mentions that the tool runs GraphQL queries and supports certain scopes; it does not explain execution semantics, authentication needs, response format, error behavior, or potential hazards of arbitrary queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the most important information front-loaded. It avoids redundancy, though 'various datasets' is imprecise and could be replaced with more useful specifics without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a flexible, raw GraphQL tool with no output schema and no annotations, so the description must carry substantial context. It lacks concrete dataset examples, query syntax guidance, scoping requirements, and any indication of response shape or error modes, leaving an agent under-equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters ('query' as the GraphQL query string and 'variables' as a JSON string), so the schema already covers the parameter mechanics. The description adds the GraphQL context but no additional detail about query structure, variable formatting, or dataset names, so it neither significantly compensates nor falls short of the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Query'), a clear resource ('Cloudflare Analytics'), and the access method ('using GraphQL'). It also hints at scope ('zones, accounts, and various datasets'), which helps distinguish it from sibling endpoint-specific analytics tools, though 'various datasets' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling analytics endpoints such as get_zone_analytics or get_dns_analytics_report. The description does not state trade-offs, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not mention pagination, result limits, read-only semantics, permissions, or response characteristics. 'List' weakly implies a read operation, but the description adds almost no behavioral transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately short for a simple list operation, though it omits context that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list endpoint, the description provides the essential resource and scope, and the schema covers the parameter completely. However, with no annotations, no output schema, and no mention of pagination or filtering, an agent still lacks expectations about the response or operational limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, account_id, is already described as 'The account ID'. The description's phrase 'for an account' aligns with the parameter but adds no new meaning or formatting details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('Cloudflare Access applications') with an account scope. It is distinguishable from siblings like list_access_policies and list_access_groups because of the word 'applications', but it never explicitly calls out that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives such as list_access_policies, list_access_groups, or other Access-related list tools. It only restates the basic operation without any context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read-only 'List' operation and gives no additional detail about pagination, result ordering, permissions, or any quirks of the resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is appropriately short for a simple list operation, though the brevity sacrifices usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no annotations or output schema, the description is minimally viable: it identifies the operation and account scope. However, it omits caveats such as pagination, access permissions, or how to decide between this and the singular get_access_bookmark tool, leaving some ambiguity in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so account_id is already documented in the input schema. The description adds no parameter-level meaning beyond the schema, but the schema itself provides the basic meaning, which is sufficient for this simple one-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('Access bookmarks'), and the scope ('for an account'). This is clear and distinguishes the operation from siblings like get_access_bookmark, though it does not explicitly contrast with other list_access_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_access_bookmark or other Access-related list tools. The description simply names the operation and leaves the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read-only operation, but it does not mention pagination, time range constraints, log retention, ordering, or response size. For an unannotated tool, this is a significant behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states resource and scope with no filler. It is appropriately concise and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple one-parameter schema and the absence of an output schema, the description omits operational context such as what fields log entries contain, default time windows, pagination behavior, or filtering capabilities. An agent can guess the basic call but cannot reliably interpret or paginate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: account_id is already described as 'The account ID', so the schema fully documents the only parameter. The description adds no additional meaning about parameter format, constraints, or how account_id affects the resulting logs. Baseline 3 is appropriate when the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear action (list), a specific resource (Access request logs), and a scope (an account). It is distinguishable from sibling tools like get_audit_logs or list_access_apps by naming 'Access request logs', though it does not explicitly differentiate itself from those alternatives. Some ambiguity remains about whether 'Access' refers to Cloudflare Access product logs or access records in general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related tools such as get_audit_logs or list_logpush_jobs_account. It does not mention prerequisites, typical use cases, exclusions, or alternatives. The only contextual clue is 'for an account', which is a scope constraint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only list operation scoped to an account, but says nothing about pagination behavior, permission requirements (e.g., needing account admin role), the shape of member entries (roles, status), or how this differs from Access users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the core action and scope are front-loaded. It is appropriately sized for a one-parameter list tool, though it borders on restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the definition is minimally viable: the parameter is fully schema-documented and the purpose is clear. However, it lacks any mention of return value shape, pagination, or how to distinguish this from semantically overlapping siblings like list_memberships, which matters given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the account_id parameter is documented in the input schema as 'The account ID', which is self-explanatory. The description adds no parameter-level detail, but the high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('members of a Cloudflare account'), making the tool's function immediately clear. However, it does not differentiate it from closely related siblings like list_memberships or list_account_roles, which operate on overlapping concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_memberships (which covers memberships across accounts) or list_access_users (which covers Access users). No context, prerequisites, or exclusions are provided, leaving the agent to infer selection criteria from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information, and it provides only the verb 'List', which implies a read operation. It does not mention pagination, whether all items are returned at once, or any relationship/authorization expectations between account_id and list_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words or filler. It front-loads the verb and resource immediately, though it sacrifices some useful contextual detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation, the description plus schema provide enough to know how to invoke the tool: pass an account_id and a list_id. However, the lack of an output schema and any behavioral context about pagination or response shape leaves a meaningful gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains the two parameters. The description adds only the context that the list is an 'account rules list' and that 'items' are being listed, but does not elaborate on parameter values or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('items in an account rules list'), making the tool's basic purpose easy to identify. The word 'items' helps distinguish this from siblings like list_account_rules_lists and get_account_rules_list, even though those alternatives are not explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related tools such as list_account_rules_lists or get_account_rules_list. An agent must infer from the name that this targets items inside an existing rules list rather than the lists themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys only that this is a list operation, omitting pagination, response contents, authorization needs, or any side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no redundant words. It is appropriately front-loaded, though it could earn a higher score with more useful detail rather than remaining so minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is minimally sufficient: an agent knows to call it with an account_id to list addressing services. However, it does not clarify what an addressing service is, what the response looks like, or how this differs from related list tools, leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter account_id as 'The account ID', so the description adds no additional parameter semantics. The baseline of 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List addressing services') and scopes it to an account. It doesn't explicitly differentiate from related siblings like list_address_maps, but the resource name is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The account_id requirement is implied by the schema, not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys only a read-style 'List' operation and says nothing about return format, pagination, ordering, authentication requirements, or side effects. Even a brief statement about what a successful response contains would meaningfully improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with zero filler and the verb front-loaded. It is efficient and every word earns its place. However, the brevity borders on under-specification rather than deliberate conciseness, since essential behavioral and usage details are absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters and no nested objects, the schema covers the parameter side completely. However, with no output schema and no annotations, the description leaves the response shape and behavioral characteristics undisclosed, and nothing in the sibling set offers disambiguation hints. A single sentence about the returned evaluations would make this adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both account_id ('The account ID') and gateway_id ('The AI Gateway ID') already carry one-line definitions in the schema. The tool description adds no parameter-level meaning, such as how gateway_id relates to account_id or how to discover valid IDs. With full schema coverage, a neutral baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('evaluations') scoped to 'an AI Gateway,' which lets an agent distinguish it from sibling tools like list_ai_gateway_datasets, list_ai_gateway_routes, and the singular get_ai_gateway_evaluation. The resource noun 'evaluations' is unique within the AI Gateway sibling set, so selection is unambiguous. It is terse and adds no detail about scope or filtering, but it is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the nearby get_ai_gateway_evaluation (single item) or other list_ai_gateway_* sibling tools. The description neither names an alternative nor states a condition for choosing between list and get variants. The only usage signal is the verb 'List,' leaving the decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full behavioral disclosure burden but only repeats the action 'List'. It does not mention result format, pagination, read-only semantics, or any other behavior an agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five words with no filler; the action, resource, and scope are front-loaded. For a trivial one-parameter list operation this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is too terse to be fully complete: it offers no return-value expectations and, more importantly, does not disambiguish from several sibling schema-listing tools. An agent selecting among list_api_schemas, list_api_shield_schemas, and list_api_gateway_schemas would need more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the only parameter zone_id. The description adds no extra meaning beyond the schema, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (list) and resource (API schemas) scoped to a zone, so an agent can generally understand the operation. However, it does not distinguish this tool from siblings like list_api_shield_schemas and list_api_gateway_schemas, which also involve listing schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over adjacent schema-listing tools, nor any exclusions or context. The only hint is 'for a zone', which is a scoping detail rather than a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It only says 'List jobs'; it doesn't mention pagination, result shape, ordering, permissions, or whether this is a light metadata operation. 'List' implies read-only, but nothing beyond that is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; it is short and direct. It does not repeat the parameter descriptions or add redundant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the invocation context is thin: an agent knows it needs account_id and rag_id, but doesn't know what 'jobs' means, what fields are returned, or whether results are paginated. For a list tool with zero behavioral annotations, this is borderline sufficient but leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully (account_id and rag_id), so the bar is a baseline 3. The description reinforces that rag_id identifies the AutoRAG instance but provides no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('jobs for an AutoRAG instance'), so an agent can infer this is a collection operation scoped to a specific rag_id. It does not explicitly contrast with get_autorag_job or list_autorag_files, but the resource and verb are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this instead of get_autorag_job (single job) or list_autorag_files (files for the same instance). The only signal is the generic list-vs-get naming convention, which is not stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List' and describes the item type; it does not mention pagination, filtering, date ranges, account scoping, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the parenthetical 'potential infringements' adds useful meaning. It is concise, though it sacrifices helpful usage and behavior context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too thin to be fully actionable. It does not clarify how this endpoint differs from list_brand_protection_logo_matches or describe pagination/filtering behavior, leaving gaps for an agent operating in a large sibling-rich API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required parameter account_id with the description 'The account ID', and schema description coverage is 100%. The tool description adds no additional meaning beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the operation ('List') and resource ('brand protection matches') and adds the clarifying parenthetical 'potential infringements,' so the return type is clear. However, it does not explicitly distinguish this from the similar sibling list_brand_protection_logo_matches, so differentiation is only partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many brand-protection list siblings such as list_brand_protection_alerts, list_brand_protection_queries, and list_brand_protection_logo_matches, an agent has no basis to select this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'List' implies a read operation, but the description does not disclose pagination behavior, account scoping, authentication requirements, or whether the result set is limited in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or repetition. It is front-loaded and easy to parse, though it is so brief that it sacrifices useful context that other dimensions would benefit from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter and no output schema, the description plus schema provides a minimally viable picture. However, it lacks any mention of pagination, response shape, or the nature of a 'brand protection query', and with no annotations the description alone is somewhat thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id already documented as 'The account ID', so the baseline is 3. The description adds no additional semantic context about how account_id relates to brand protection queries or whether it is required beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('brand protection queries'), making the basic purpose immediately understandable. It does not explicitly differentiate itself from the many sibling brand protection list tools, but the resource name is specific enough to avoid tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus other list tools, such as list_brand_protection_alerts, list_brand_protection_matches, or list_cloudforce_one_queries. The description provides no context, exclusions, or alternative routing, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. 'List' implies a read operation, but 'recent' is undefined — no time window, item count, pagination, ordering, or result shape is disclosed. An agent cannot predict what set of items it will receive or when the tool is appropritate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five words, front-loaded with the verb, and contains zero filler. Every word earns its place, but it is under-sized relative to the informational job — it essentially renders the tool name with underscores replaced by spaces, leaving little structural substance beyond brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is structurally simple (1 param, no output schema), which lowers the burden, but with no annotations and no output schema the description must define what a brand protection submission is, what 'recent' bounds, and what the caller receives — none of that is present. An agent can supply account_id but has no idea what the response represents, how fresh it will be, or how large.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: account_id is already described as 'The account ID' in the input schema, so the schema does the full documentation job. The description adds nothing parameter-level, which is acceptable at the 3 baseline for high coverage. No enums or nested objects create additional documentation needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('recent brand protection submissions'), clearly identifying the operation without restating the tool name verbatim. It is distinguishable from the brand-protection sibling set by resource type — no other sibling is named 'submissions' — though it stops short of explicitly differentiating itself from neighbors like list_brand_protection_alerts or list_brand_protection_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus alternatives. The sibling set contains close neighbors — list_brand_protection_alerts, list_brand_protection_matches, list_email_security_submissions — with no mention of the scenario that should select this one. Nothing is misleading, but there is a plain absence of routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List...' which implies a read-only operation, but it does not mention pagination, filtering, ordering, required permissions, or what the response contains. The description adds little behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant clauses. It is front-loaded and easy to parse, though it is too terse to add much value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with one fully documented required parameter, this is minimally adequate. However, there is no output schema and no mention of return shape, pagination, or relationship to sibling brand protection tools, so the agent must infer important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, account_id, is already documented in the schema as 'The account ID.' The description adds no additional meaning to the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List brand protection tracked domains.' This is enough to identify the operation and distinguish it from sibling tools like list_brand_protection_alerts or list_brand_protection_matches, though it mostly restates the tool name without adding scope or detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus related brand protection tools such as list_brand_protection_brands, list_brand_protection_matches, or get_brand_protection_domain_info. The description does not mention intended use cases, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, but it only restates the list operation and the mTLS domain. It does not disclose pagination, response format, required permissions, or the zone-vs-account scope of the listing, which is material for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no wasted words, and the 'for mTLS' qualifier earns its place by narrowing the resource type. It could have used the available space to clarify scope, but it is not padded or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the core call shape (list certificates for a zone, scoped by zone_id) is recoverable from the description plus schema. However, the zone-vs-account ambiguity versus list_account_mtls_certificates and the absent return-format info leave the definition adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single required zone_id is already documented, so the baseline of 3 applies. The description adds no parameter-specific meaning; its only contribution is domain context for what kind of certificates the zone_id refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('List client certificates') and adds the mTLS domain, which meaningfully narrows the resource type. However, it does not distinguish this from the similarly named sibling list_account_mtls_certificates, so an agent must infer zone-scope from the schema rather than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no alternative tool is named. With roughly 230 siblings including multiple certificate-listing tools (list_custom_certificates, list_origin_ca_certificates, list_account_mtls_certificates), the lack of any routing cue leaves an agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It states the read-style 'List' action and zone scope, but discloses nothing about pagination, ordering, filtering, response shape, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, grammatically complete sentence with no filler or restatement beyond the core information. It is efficient, though not as front-laded with additional context as a richer description could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is underspecified. It doesn't explain what cloud connector rules are, how the list is returned, or how this list endpoint differs from related rule-listing endpoints; an agent would need external knowledge to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%: zone_id is described as 'The zone ID', and the tool description echoing 'for a zone' adds no new format or constraint details. Baseline 3 applies because the schema already documents the only parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('List'), resource ('cloud connector rules'), and scope ('for a zone') in a complete, unambiguous statement. It doesn't explicitly differentiate from sibling rule-list tools like list_zone_rulesets or list_firewall_rules, though the resource name is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling list_*_rules tools. The description only restates the basic purpose; it provides no scenarios, prerequisites beyond zone_id, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'list' implies a read operation, but the description does not state whether the operation is read-only, what the response contains, whether pagination or ordering applies, or any side effects. For a tool with no annotation support, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It says exactly what the tool does and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, no annotations, and dozens of similar Cloudforce One sibling tools, the description does not provide enough context to select it confidently. It lacks any statement about return shape, naming of alternatives, or guidance on when this is the correct tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id at 100% coverage with 'The account ID', so the baseline is 3. The description adds no additional meaning about the account_id's format, required scope, or how it influences the category list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('Cloudforce One event categories'), so an agent can tell what the tool does. It does not explicitly differentiate from sibling tools like list_cloudforce_one_request_types or list_cloudforce_one_tags, but the resource phrasing is specific enough for basic purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar Cloudforce One listing tools, nor any mention of prerequisites, filters, or contexts. The usage is only implied by the name and description rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it lists countries; there is no mention of pagination, response format, normalization, relationship to events, or any other behavioral traits. The word 'List' implies a read-only operation, but beyond that the behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no redundancy or filler. It is appropriately front-loaded and easy to parse, though the brevity sacrifices useful contextual detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of behavioral and return-value information, and it only names the resource. An agent can infer the basic call, but it cannot predict the response shape, pagination behavior, or how the countries are represented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required account_id parameter with a clear description, so the schema already carries the parameter semantics. The description adds no additional meaning about how account_id relates to the listed countries, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Cloudforce One event countries'), clearly distinguishing this from the many other list_cloudforce_one_* sibling tools such as categories, datasets, and tags. It could be slightly clearer about what 'event countries' means in relation to Cloudforce One events, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the numerous sibling list tools for Cloudforce One data, nor any mention of alternatives or exclusions. The tool's name suggests its niche, but the description itself provides no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'List' and gives no information about pagination, filtering, account scoping, side effects, or response behavior. It is not misleading, but it adds little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately short for a simple list operation, though its terseness leaves behavioral and usage details unsaid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description plus schema offers a minimum viable call: list events for an account. However, there is no output schema, no annotation, and no guidance on pagination or how this differs from get_cloudforce_one_event and list_cloudforce_one_events_aggregate, so it is not fully omplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is documented as 'The account ID' in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Cloudforce One threat events'), clearly identifying the operation. It distinguishes at a basic level from get_cloudforce_one_event (singular) and list_cloudforce_one_events_aggregate (aggregate) by focusing on listing raw events, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over related siblings such as get_cloudforce_one_event or list_cloudforce_one_events_aggregate. The only context is implied by the word 'List'; no exclusions or alternative selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List', implying a read operation, but it does not disclose pagination behavior, response format, whether threat indicators are returned in bulk, or any account-level implications. The agent must assume behavior from the verb alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately small for a simple one-parameter list tool, though it omits useful behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list endpoint, the description is minimally serviceable: it names the resource and the schema covers the only parameter. However, with no output schema and no annotations, the agent is not told what a 'threat indicator' looks like in the response or whether pagination or filters are involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single required parameter account_id, so the schema already explains the parameter. The description adds no further meaning about the account_id or how it relates to the indicator listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List Cloudforce One threat indicators'. It is distinguishable from sibling tools like list_cloudforce_one_indicator_types and list_cloudforce_one_events because the resource term 'indicators' is specific, though it does not explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_cloudforce_one_indicator_types or list_cloudforce_one_queries. No context, prerequisites, or exclusions are provided, so an agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only conveys that something is listed; it does not disclose whether the operation is safely read-only, whether results are paginated, what the entries look like, or whether the output is scoped to the account_id parameter. 'List' weakly implies a read, but no meaningful behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single declarative sentence with zero wasted words and the action verb front-loaded. It is efficiently sized for a simple list tool, though the terseness is partly what leaves the sibling ambiguity unresolved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one required param, no output schema), but the sibling set is large and confusing: list_cloudforce_one_indicators, list_cloudforce_one_request_types, list_cloudforce_one_datasets, list_cloudforce_one_queries, and list_cloudforce_one_events are all plausible lookalikes. With no output schema and no annotations, the description alone does not let an agent reliably distinguish this tool or predict its return shape, so it is not complete enough for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single required parameter account_id is documented as 'The account ID' in the schema itself. Per baseline, the description need not add parameter detail when the schema already covers it. The description contributes nothing about why account_id is needed, but the schema adequately handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Cloudforce One indicator types'), making the basic action clear. However, it does not differentiate from the sibling list_cloudforce_one_indicators — an agent cannot tell from the description alone whether 'indicator types' means a taxonomy/catalog of type categories or type-tagged indicators. Clear verb+resource but no sibling differentiation, so a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not state when to choose this over list_cloudforce_one_indicators, list_cloudforce_one_request_types, or list_cloudforce_one_datasets, nor does it mention any prerequisites or context. The agent must infer usage purely from naming pattern, which is risky given the large set of near-identical Cloudforce One list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and a bare 'List Cloudforce One tags' provides almost none. It does not state whether results are paginated, whether tags are account-scoped, what auth is required, or what the response looks like; read-only intent is only implied by the verb in the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with zero wasted words and the resource named immediately. It is structurally clean and front-loaded, though so terse that it borders on under-specification — a gap penalized in other dimensions rather than here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should carry more context, but it explains none of the return shape, pagination, scoping semantics, or what a 'tag' is in this domain. An agent could make a plausible call with account_id alone, but the definition is missing useful context that a one-line list tool should provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is documented as 'The account ID' — so the schema carries the parameter documentation and the baseline is 3. The description adds no additional meaning about the parameter, such as clarifying that tags belong to the specified account, but it does not need to compensate for a coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('Cloudforce One tags'), so an agent can tell what operation this performs. It is distinguishable from the many cloudforce_one sibling list tools (list_cloudforce_one_categories, list_cloudforce_one_queries, etc.) by the named resource, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus the 16+ other Cloudforce One tools in the sibling list. No context, no exclusions, no mention of prerequisites or typical use cases — the agent must infer everything from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not mention pagination, account scoping, authentication needs, or what a 'target industry' actually contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple list operation, though it adds little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not clarify what the returned data looks like, whether results are paginated, or how 'target industries' is defined. The single sentence is too minimal to fully support tool selection among many similar Cloudforce One list endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single account_id parameter is already documented. The tool description adds no connection between account_id and the returned target industries, but the baseline of 3 applies because the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List Cloudforce One target industries.' It identifies exactly what the tool does and is not a tautology. However, it does not differentiate this from the many sibling list_cloudforce_one_* tools, such as list_cloudforce_one_countries or list_cloudforce_one_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus any alternative. The description does not provide context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'List' implies a read-only operation, but the description doesn't mention pagination, response format, permissions, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler words. It earns its place but is minimal overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain more about what the agent can expect from the result. It doesn't describe return structure, pagination, or account-level scoping, leaving the tool under-specified for an agent facing many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes account_id with 100% coverage, so the baseline is 3. The description adds no additional parameter meaning, but it doesn't need to because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('device policies for Zero Trust'), making the core operation clear. However, it doesn't explicitly distinguish itself from sibling tools like list_device_posture_rules, which could be confused with device policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. Sibling tools include many Zero Trust list operations, but the description provides no exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'List... by device'. It does not mention pagination, filtering, ordering, whether the response is aggregated per device or raw status entries, or any operational characteristics. The read-only nature is implied by 'List', but key behavioral details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler words. It is appropriately front-loaded with the action and resource. It is concise, though slightly vague, and could have included a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and multiple closely related DEX fleet tools in the sibling list, the description is too thin to fully inform an agent. It doesn't explain what 'by device' means precisely, what the return shape is, or how this differs from live/over-time variants, leaving important selection and invocation context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, account_id, with a description ('The account ID'). The tool description adds no extra meaning about how account_id is used or any constraints, so it meets the baseline but does not enrich the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and a resource ('DEX fleet status') with a qualifier ('by device'). This gives a basic understanding of the tool's purpose, but it doesn't explicitly differentiate it from closely related siblings like get_dex_fleet_status_live or get_dex_fleet_status_over_time, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus its alternatives. There are several DEX fleet-related siblings in the tool list, and the description offers no conditions, exclusions, or hints on how this tool differs from them, leaving the agent to guess or inspect the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The 'List' verb implies a read operation, but the description does not disclose pagination behavior, response contents, or permission requirements. For a tool with no output schema, this leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no wasted words, and the core scope ('for an account') is front-loaded. It earns its place but is minimal to the point of bordering on under-specification, which is penalized in other dimensions rather than here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description adequately conveys the primary operation and account scoping, and the schema fully covers the parameter. However, with no output schema and no annotations, the missing return-value and pagination context leaves the definition merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% — the single account_id parameter is documented with 'The account ID' in the schema itself. Per the baseline rule, when coverage exceeds 80% the description need not add parameter detail. The description's 'for an account' phrasing does reinforce the parameter's role but adds no new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a specific resource (DLP datasets), and a scope (for an account). It is clear and unambiguous about what the tool does. However, it does not explicitly name or distinguish itself from the sibling get_dlp_dataset, leaving the agent to infer the list-vs-get distinction from the verb alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that get_dlp_dataset should be used for a single dataset, nor does it name any sibling or exclusion condition. An agent must infer usage entirely from the tool name and the verb 'List.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but nothing is said about pagination, account scoping of results, response shape, or whether only 'available' patterns are returned and what 'available' means. This is minimal disclosure that adds little beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loaded with the action verb and resource. It is efficient and easy to parse. The terseness borders on under-specification, but as pure conciseness it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is minimally viable: the required account_id is documented and the action is clear. However, with no output schema and no annotations, the agent receives no information about the return format, default ordering, or what constitutes a 'predefined DLP pattern,' leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — account_id is already documented as 'The account ID.' The description adds no parameter-specific meaning or usage detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('predefined DLP patterns'), making the basic operation clear. It distinguishes itself from DLP siblings like list_dlp_profiles and list_dlp_datasets by naming a different resource type. However, it never explains what a 'pattern' is versus a 'profile' or 'dataset', so an agent selecting among DLP tools may still be uncertain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't reference any sibling tools, mention that patterns differ from profiles/datasets, or state any context in which a caller would prefer one over another. The agent is left to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination, response shape, ordering, or any side effects or read-only guarantees. The description is accurate but provides no behavioral context beyond the basic listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is front-loaded with the action and resource. However, it is so minimal that it could have used a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description is minimally adequate. It correctly identifies the resource and scoping argument, but it leaves out useful contextual details such as what the response contains or whether results are paginated. Given the absence of an output schema and annotations, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because account_id is fully described as 'The account ID'. The description adds minimal context by indicating the clusters are scoped to an account, but it does not meaningfully enhance the parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('DNS Firewall clusters'), scoped to an account. It does not explicitly differentiate from the sibling get_dns_firewall_cluster, but the list-versus-get distinction is readily apparent from the resource name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like get_dns_firewall_cluster or get_dns_firewall_analytics. The description only states what it does, not when it should be chosen over other cluster-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, but it only states the basic action. It discloses nothing about pagination behavior, default per_page limits, filter matching semantics (exact vs. prefix), sorting, or what fields appear in each record — all material for a list operation with a pagination parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six words, zero waste, and the core action is front-loaded. It loses a point because it is concise at the expense of any added value — no mention of pagination or record filters that could have been folded in without bloating the sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description bears responsibility for indicating what is returned; it says nothing about the response shape or pagination. With no annotations and no return-value disclosure, an agent cannot predict how to handle multi-page results or what record fields to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all four parameters (zone_id, name, type, per_page) are documented in the schema itself. Per the rubric baseline, the description need not repeat parameter meaning; it adds nothing beyond the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('DNS records') with a clear scope ('for a zone'). However, it does not explicitly differentiate itself from the natural sibling get_dns_record (single record vs. all records for a zone), so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Among 400+ siblings including get_dns_record, get_dnssec, and list_dns_views, the description offers no exclusions, prerequisites, or routing hints — an agent must infer entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely restates the action implied by the tool name and provides no information about authentication requirements, pagination, response shape, filters, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words or filler. It is front-loaded with the operation and resource, though it is somewhat minimal for a tool with no annotations or output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation without an output schema or annotations, the description leaves important context uncovered, such as whether results are paginated, what fields are returned, and how this tool differs from related DNS view tools. It is not sufficiently complete for an agent to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for 'account_id', and the description does not add meaningful detail beyond that. Since the schema already documents the only parameter, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List'), the resource ('DNS views'), and the scope ('for an account'). This explicitly distinguishes it from the sibling tool 'get_dns_view' which retrieves a single view, so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_dns_view' or how it relates to 'list_dns_records'. There is no mention of prerequisites, exclusions, or typical use cases, so an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it discloses almost nothing: no pagination behavior, no mention that results are account-scoped, no detail on what fields are returned for each address, and no clarification of what 'verified' means in this context. The word 'verified' adds a small behavioral trait, but the description fails to convey the operational behavior of a list endpoint beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word phrase with zero waste and the essential information (List + what is listed) front-loaded. It is efficient, though terse to the point of minimalism — slightly more behavioral context would be warranted for this size without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity single-parameter list operation, the description covers the core purpose adequately. However, with no annotations and no output schema, an agent is left without information about what the response contains (e.g., address and verification status fields), pagination, or why 'verified' is significant. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — account_id is documented in the schema as 'The account ID', so the baseline is 3. The description adds no parameter-level meaning beyond the schema, but for a single trivially-named parameter this is an acceptable baseline; there is no gap the description needs to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('verified destination email addresses'), making the operation unambiguous. The 'verified' qualifier adds useful scoping and helps distinguish this from the related email routing siblings (get_email_routing_settings, list_email_routing_rules). It doesn't explicitly name a sibling for differentiation, but the resource is precise enough that an agent can infer the right selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention that this is for Cloudflare Email Routing destination addresses, no context distinguishing it from list_email_routing_rules or get_email_routing_settings, and no exclusions or prerequisites stated. The agent must rely entirely on the tool name for selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. The word 'List' implies a read-only operation, but the description gives no information about pagination, ordering, account scoping, response entries, or any side effects. This is minimally informative for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler or redundant phrases, and the verb is front-loaded. It is appropriately terse for a simple list operation, though it is also close to a bare restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should compensate by explaining what the impersonation registry is and what a response contains. It does neither, so an agent has little context to interpret the result or distinguish this resource from other email-security lists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter, account_id, with 100% coverage, so the description does not need to repeat parameter details. At the same time, the description adds nothing about how account_id is used or scopes the registry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('email security impersonation registry'), and no sibling tool shares exactly this resource, so the basic purpose is identifiable. However, it does not explain what the impersonation registry contains or what an entry looks like, so it stops short of being fully self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus related email-security list tools such as list_email_security_trusted_domains or list_email_security_allo_policies. No exclusions, condition, or alternative-selection hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral transparency. Saying 'List' implies a read-only operation, but the description does not disclose pagination, return shape, permissions, or whether only enabled/trusted entries are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct verb phrase with no filler and is front-loaded with the action. It is concise, though slightly too skeletal to convey broader context, so it does not reach 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no output schema, and no annotations, the description still does not explain what a trusted domain is, what the response looks like, or how this differs from list_email_security_domains. An agent would have to guess about selection criteria and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents account_id as 'The account ID' with 100% coverage, so the schema already carries the parameter meaning. The description adds no parameter-specific detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List,' and a specific resource, 'email security trusted domains,' so an agent can tell this returns trusted-domain records. It does not contrast with the similarly named sibling list_email_security_domains, which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_email_security_domains or list_email_security_allow_policies. There is no mention of context, exclusions, or conditions that would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It indicates a read-only listing operation, but does not mention pagination, scope, response format, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It is appropriately concise, though the 'for diagnostics' clause is somewhat vague and could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is minimally acceptable but leaves gaps: it does not clarify what an endpoint healthcheck is, how results are paginated, or how this differs from 'list_healthchecks'. No output schema exists to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter, account_id, is already described as 'The account ID'. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('endpoint healthchecks') and adds a purpose ('for diagnostics'). However, it does not differentiate from the similar sibling 'list_healthchecks' or clarify the relationship to 'get_endpoint_healthcheck'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'list_healthchecks' or 'get_endpoint_healthcheck'. The phrase 'for diagnostics' hints at context but does not establish selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does not state whether this returns paginated results, whether it includes disabled rules, whether it reflects a specific rule ordering, or whether the concept of 'firewall rules' here is legacy vs. modern rulesets. For a read/list tool, the absence of pagination or scoping caveats leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the essential action and target in five words. There is no filler, and the key scope constraint is present. It is concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no output schema and no annotations, the description is minimal. It doesn't mention pagination, default limits, or whether the 'firewall rules' returned include legacy firewall rules versus rulesets. Given the massive sibling list with closely related tools (list_zone_rulesets, get_waf_custom_rules, list_filters), the description lacks the context needed to reliably distinguish and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, zone_id, already has a description ('The zone ID'). The tool description adds the contextual relationship between the parameter and the resource ('for a zone'), but that is otherwise clear from the tool name and schema. Baseline 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List firewall rules for a zone' has a clear verb ('List') and resource ('firewall rules for a zone'), and the singular required parameter zone_id reinforces the scope. It doesn't differentiate from similar zone-scoped list tools like list_zone_rulesets or get_waf_custom_rules, but those are distinct enough by name that the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_zone_rulesets, get_waf_custom_rules, or list_filters. There are no context cues, prerequisite notes, or exclusions, so an agent choosing among many firewall-related list tools gets no assistance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only repeats the list operation and does not mention pagination, response shape, authentication requirements, or whether any account-level constraints apply beyond the schema. The read-only nature is implied by the verb but never made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant phrasing. It is concise enough for a simple list operation, though it sacrifices some useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description is minimally adequate: it names the operation and the resource, and the schema documents the required account_id. However, with no output schema and no behavioral notes, an agent cannot anticipate the response format or whether the endpoint list is paginated or account-scoped beyond the parameter name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the only parameter, account_id, already has a description and maxLength constraint in the schema. The tool description adds no additional meaning about the parameter, but the schema alone is sufficient for this single required field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a distinct resource ('Gateway proxy endpoints'), making the operation clear. It differentiates from nearby siblings like list_gateway_rules and list_gateway_locations by naming a different resource type, though it adds no detail about what a proxy endpoint is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_gateway_rules or get_gateway_configuration. The description only states the action and provides no context, prerequisites, or exclusions to help an agent choose among the many list_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that images are listed, without mentioning pagination, response format, ordering, or whether the list is limited to a single account. The read-only nature is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately compact for a simple list operation, though it is slightly too sparse to fully cover behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity—one required parameter and a clear list action—the description is minimally viable. However, the absence of any annotation or output schema means the description should ideally mention pagination, response shape, or account scoping to fully prepare an agent. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single account_id parameter already described as 'The account ID'. The tool description adds no extra meaning about the parameter, so it neither helps nor hurts. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and a specific resource ('images in Cloudflare Images'), which distinguishes it from sibling tools like list_stream_videos or list_d1_databases. It could be improved by clarifying that this is account-scoped via account_id, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_images_stats or list_stream_videos. There are no conditions, exclusions, or references to sibling tools that might be more appropriate for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List threat indicator feeds' implies a read-only enumeration but reveals nothing about pagination, account scoping, authorization requirements, or response characteristics. This is minimal rather than misleading, but it is far from transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, it mostly restates the tool name and provides no scoping or differentiating detail, so the brevity reflects under-specification rather than efficient elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description is minimally viable: the agent knows the action, the resource, and the required account_id from the schema. However, with no annotations and no output schema, the absence of account-scope wording, return-shape information, and pagination behavior leaves the definition thinner than ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only required parameter, account_id, is described simply as 'The account ID.' The description does not add parameter-level context, but because the schema already documents the single parameter, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'List' and a specific resource 'threat indicator feeds,' so an agent can tell this is an enumeration operation. It does not explicitly contrast with the singular get_intel_indicator_feed, but the list-versus-get distinction is reasonably clear from the resource naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, such as get_intel_indicator_feed for a single feed or related Intel list tools. The description only implies enumeration via the word 'List' and leaves all routing decisions to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List.' It does not mention whether results are paginated, whether the account_id is required, what kind of IP list entities are returned, or any filtering/sorting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key action and resource. It avoids unnecessary detail, though 'for threat intelligence' mostly restates the intent already implied by the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is thin. It does not explain what an 'IP list' is, whether the endpoint returns metadata or membership data, how account_id scopes the results, or how this differs from related intel tools. An agent would likely need to open the schema or probe the API to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single account_id parameter, so the schema already documents the parameter. The description adds no additional meaning about how account_id affects the result, but the high schema coverage keeps this at the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('IP lists') and adds the purpose context 'for threat intelligence.' It is more than a tautology and names a specific resource, though it does not explicitly differentiate from sibling intel list tools like list_intel_indicator_feeds or list_intel_sinkholes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of account scoping, pagination, or relationship to other threat-intelligence list endpoints, so an agent gets little help deciding between this and nearby sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states a list action and gives no details about pagination, response shape, required permissions, or whether results are account-scoped. The verb implies read-only behavior but adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. It is concise, though it sacrifices useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no output schema and no annotations, this sparse description leaves too much unspecified: what a sinkhole is, what the returned data contains, and whether results are paginated. The account_id parameter is documented, but the tool's purpose lacks enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: account_id is described as 'The account ID'. The tool description adds no extra parameter meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Cloudflare sinkholes'), so an agent can tell this is a list operation. However, it does not differentiate the resource from similar siblings like list_intel_indicator_feeds or list_intel_ip_lists, and 'sinkholes' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, or what kind of account/context requires it. With many sibling list tools in the intel domain, the description leaves the selection decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the word 'List', but gives no information about pagination, result shape, empty-result behavior, or any side effects. It adds no behavioral context beyond what the tool name already communicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no filler and a clear, direct structure. It is appropriately front-loaded, though its brevity means it sacrifices behavioral and contextual detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two required parameters and full schema coverage, this is minimally viable: an agent can infer what to call and which IDs are needed. However, with no annotations or output schema, the description leaves gaps around what a delegation is, how results are returned, and how this operation fits with the broader IP prefix workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 100% of parameters with clear descriptions for 'prefix_id' and 'account_id', so the high-coverage baseline applies. The tool description adds no parameter-level meaning, such as value formats or the relationship between the two IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('List'), resource ('delegations'), and scope ('for an IP prefix'), which matches the tool name and distinguishes it from related prefixes tools like list_ip_prefixes or get_ip_prefix. However, it adds little beyond the tool name and does not explicitly contrast with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other prefix-related tools. The description only restates the action and does not mention prerequisites, exclusions, or how this differs from get_ip_prefix_bgp_status or list_addressing_services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only the bare action of listing keys — nothing about pagination behavior, key ordering, how limit and prefix interact, or response format. This is close to a restatement of the tool name rather than an addition of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six words with zero fluff and the core action front-loaded. Efficient and scannable, though the brevity borders on under-specification rather than demonstrating deliberate compression of rich content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple filtered-list tool: all parameters are documented in the schema and the verb 'list' implies a read operation. However, with no annotations and no output schema, the limit/pagination behavior and the distinction from sibling KV list tools are left unstated, so an agent must rely on the schema alone for operational confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with meaningful descriptions for all four parameters (limit, prefix, account_id, namespace_id). The description adds nothing about parameters beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List keys in a KV namespace'. The noun 'keys' inherently separates it from sibling list_kv_namespaces (which lists namespaces) and get_kv_namespace (which fetches a single namespace), though the description never explicitly names those alternatives. Clear and unambiguous about what the tool operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus list_kv_namespaces or get_kv_namespace, no exclusion criteria, and no context about namespace scoping. All routing decisions are left entirely to the agent's inference from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool lists detections; it does not mention return format, pagination, ordering, authentication needs, or whether any filtering is applied. For a list operation this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is appropriately brief for a tool with one parameter, though it could have used the available space to mention pagination or response content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one required parameter, and no output schema, the description is minimally adequate for an agent to select and invoke the tool. However, without annotations or mention of return values or pagination, it is not fully complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because zone_id is documented as 'The zone ID'. The description adds little beyond restating the zone scope, so it stays at the baseline 3 rather than adding new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List leaked credential detections for a zone' clearly identifies the verb (list), the resource (leaked credential detections), and the scope (zone). It is specific enough to distinguish from the many sibling 'get_*' tools, though it does not explicitly contrast with related tools like list_security_insights or get_leaked_credential_check_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states the zone scope and gives no guidance on when to use this tool versus alternatives. It does not mention filters, pagination, or exclusions, and it does not direct the agent to related tools such as get_leaked_credential_check_settings for configuration details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. The verb 'List' implies a read-only operation, but the description says nothing about pagination, response shape, scope, or other behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is minimal, but it is genuinely concise rather than verbose, and every word in it contributes to stating the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, this one-line description leaves the agent to infer return shape, usage context, and how to choose this over the many related Page Shield and listing tools. It is not complete enough for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and zone_id is already documented as 'The zone ID'. The description adds no additional parameter meaning, but the schema fully covers the single parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it lists Page Shield policies. It distinguishes at the noun level from sibling tools like list_page_shield_scripts and list_page_shield_connections, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of related Page Shield tools such as get_page_shield_settings, list_page_shield_scripts, or list_page_shield_connections. There is also no mention of prerequisites or zone-scoping context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden; it only restates the action and resource. It does not disclose pagination, output structure, authentication requirements, or side effects. 'List' weakly implies read-only behavior, but little else is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and the action is front-loaded. It is efficient, though it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no description of return format, pagination, or what 'resources' actually represents. For an agent, this is minimally sufficient at best, but it leaves too much ambiguity for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both required parameters (share_id and account_id) with descriptions, giving 100% schema description coverage. The tool description adds no additional parameter semantics, which is acceptable when the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and names the resource ('resources in an R2 share'), so an agent can tell it is a read/list operation. However, it does not differentiate this tool from closely related siblings like get_r2_share or list_r2_share_recipients, and it does not clarify what 'resources' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as list_r2_buckets or get_r2_share. There are no prerequisites, exclusions, or context cues beyond the tool name, so the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the operation ('List') and provides no information about pagination, response shape, read-only guarantees, account/app scoping behavior, or any limits. The verb implies non-mutation, but the description adds no transparency beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It communicates the action and object efficiently, though it is slightly under-specified in behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with fully documented required parameters, the description is minimally viable. However, the lack of annotations, output schema, and usage guidance means the agent must infer pagination and return-format expectations from the verb alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both required parameters (account_id and app_id). The description adds no extra parameter semantics, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and names a specific resource ('Realtime Kit livestreams'), which differentiates it from the singular get_realtime_livestream and from related realtime listing tools. It does not fully explain scope or what qualifies as a livestream, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_realtime_livestream, list_realtime_apps, or list_realtime_sessions. With a large sibling list that includes several realtime list/get tools, the agent receives no decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'List', which implies a read operation, but it does not describe response shape, pagination, ordering, scoping by account/app, authentication expectations, or any rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. It is efficient, though it is so minimal that it adds little beyond what the tool name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with two documented required parameters, the schema covers the basic invocation needs. However, the absence of an output schema and any detail about pagination, filtering, or the meaning of a 'Realtime Kit meeting' leaves noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both required parameters, account_id and app_id, so the schema already documents their meaning. The description adds no additional information about how these parameters affect the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Realtime Kit meetings'), so an agent can tell it returns a collection of meetings. It is clear but does not explicitly differentiate itself from closely related siblings such as get_realtime_meeting or list_realtime_meeting_participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over alternatives like get_realtime_meeting, list_realtime_recordings, list_realtime_sessions, or other Realtime Kit list tools. The only implicit signal is the tool name and the word 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only suggests a read-only action via the verb 'List' but provides no details about scoping, pagination, response shape, or dependencies (e.g., requiring an existing app). The input schema hints at app scope, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no unnecessary words, and the verb is front-loaded. It loses a point because the brevity borders on under-specification, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required params, no annotations, and no output schema, so the description needs to compensate by explaining what presets are, their relationship to Realtime apps, and any relevant constraints. The single phrase 'List Realtime Kit presets' is insufficient for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both app_id and account_id, so the schema already documents the parameters. The description adds no parameter-level details, but the baseline of 3 is appropriate when the schema handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Realtime Kit presets'), which clearly identifies the tool's purpose. However, it does not explicitly differentiate this from sibling tools like list_realtime_apps or get_realtime_preset, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no mention of prerequisites, and no explanation of what Realtime Kit presets are. The agent must infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure. It conveys read-only intent via 'List', but says nothing about output shape, pagination, filtering, or scope semantics. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words, front-loaded with the action and resource, and contains zero filler. It is concise at the expense of useful context, but the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description alone must suffice. It does not explain what a recording list contains, whether results are paginated, or how this relates to get_realtime_recording and list_realtime_apps. Functional but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings already document themselves. The description adds no extra parameter context, which the baseline of 3 covers since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and a specific resource ('Realtime Kit recordings'), which distinguishes it from a retrieval of a single recording (get_realtime_recording). It is short but unambiguous about the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the many sibling real-time list tools, nor any mention of account/app scoping. An agent must infer usage from the name and params.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only repeats the verb 'List,' implying a read-only collection operation. It does not mention pagination, ordering, filtering, scoping by account/app, or response shape. No meaningful behavioral traits beyond the operation name are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with no filler or redundant phrasing. It is not bloated, but it is terse enough that it provides only the operation and resource, leaving other useful context unstated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with fully described schema parameters, this is minimally viable. However, the description does not explain that sessions are scoped to the account_id/app_id pair, and with no output schema it gives no indication of the response shape or pagination behavior. These gaps make it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both account_id and app_id having descriptions in the input schema. The tool description itself adds no parameter semantics, but because the schema already documents the parameters fully, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and a specific resource ('Realtime Kit sessions'), so an agent knows what operation is being performed. It does not explicitly contrast itself with closely related siblings such as list_realtime_recordings or get_realtime_session, but the resource name is specific enough to distinguish it from other Realtime resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention get_realtime_session for retrieving a single session, nor does it clarify what distinguishes listing sessions from listing meetings, recordings, or other Realtime resources. The only usage cue is the verb 'List' itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the operation. It doesn't disclose whether results are paginated, whether any filtering is possible, what fields are returned, or whether the account must have Registrar configured. The verb 'List' weakly implies read-only behavior, but nothing else about the tool's runtime behavior is revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with the verb front-loaded and zero filler. Every word earns its place, and the brevity is appropriate for a simple one-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity (1 parameter, no nested objects, no output schema), the description leaves notable gaps: no pagination behavior, no mention of the get_registrar_domain sibling for singular retrieval, and no indication of what distinguishes a Registrar domain from the broader set of account zones. The absence of annotations and an output schema raises the burden on the description, which it does not fully meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id documented as 'The account ID', so the schema already handles parameter meaning. The tool description adds no parameter-level detail beyond this, which is acceptable at the baseline 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('List') with a specific resource ('domains registered with Cloudflare Registrar'), making the operation and scope clear. It distinguishes itself from sibling tools like list_zones and list_dns_records by naming the Registrar product context, though it doesn't explicitly differentiate itself from the singular get_registrar_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention that get_registrar_domain exists for single-domain lookups, no contrast with list_zones (which lists all zones in an account), and no indication of prerequisites such as having the Registrar product enabled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, but it only conveys that this is a list (read-style) operation scoped to Zero Trust risk scoring. It does not disclose pagination behavior, what a 'behavior' represents, permission requirements, or any account-scoping semantics beyond the parameter name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient phrase with the verb front-loaded and zero filler. It is appropriately sized for a simple tool, though the terseness borders on under-specification rather than deliberate density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one required, fully documented parameter, so an agent can likely invoke it correctly. However, with no output schema and no description of the return shape or behavior categories, there are gaps in what the agent can expect back from the call, and no routing context against sibling tools is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the sole parameter account_id is already fully documented ('The account ID'), meeting the baseline. The description adds no parameter-level meaning, such as whether the account_id must be a Cloudflare account identifier or how it scopes the returned behaviors, but the schema does not require compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('Zero Trust risk scoring behaviors'), making the core action clear. It is distinguishable from the closely related sibling list_risk_scoring_integrations by resource type, though it does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings such as list_risk_scoring_integrations and get_risk_scoring_integration occupy the same domain, but the description gives no selection criteria, prerequisites, or exclusions to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, but it only restates the operation. It does not disclose pagination, response shape, ordering, or any other trait an agent would need to know beyond the basic list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, and the parenthetical adds useful terminology clarification. It is appropriately short for a simple single-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers the parameter, and the description gives the basic operation, so a basic call can be made correctly. However, with no output schema, no behavioral notes, and no alternative routing, the overall context is thin for an agent that needs to know what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter, account_id, with 100% coverage. The description adds no additional meaning about how account_id is used or what scope it imposes on the listed jobs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'migration (slurper) jobs', and the parenthetical usefully explains the opaque 'slurper' term. It distinguishes itself from the get_slurper_job and get_slurper_job_progress siblings through the list/get contrast, though it does not explicitly describe the list's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus get_slurper_job or get_slurper_job_progress. There is no use-case context, prerequisite mention, or scenario where the alternative should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only says 'List speed tests' and provides no information about pagination, ordering, result shape, rate limits, or what kind of zones/URLs are valid. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the action verb front-loaded and no unnecessary words. It lacks structured detail, but for a simple two-parameter list operation, this level of brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with two well-documented required parameters, so the bare description is minimally viable. However, with no output schema and no annotation context, the lack of any indication about result format, pagination, or related concepts like scheduled tests leaves the description somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds only the 'zone URL' framing, which is marginal and does not enrich the parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and resource ('speed tests') scoped to a zone URL. It is understandable on its own, but it does not explicitly distinguish itself from nearby get_speed_test or list_speed_available_regions tools beyond the plural verb, and 'zone URL' is slightly imprecise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to choose this tool over get_speed_test, get_speed_schedule, or list_speed_available_regions, nor does it mention any context such as scheduling or available regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the basic list operation but gives no details about return structure, pagination, ordering, or account-scoping behavior. It is not misleading, but it is too thin to fully inform an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately front-loaded, though it is concise partly because it omits potentially useful operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter, the description is minimally adequate. However, with no output schema or annotations, it does not mention expected return format, pagination, or any account-level context beyond the parameter name, leaving minor but relevant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single account_id parameter is already described as 'The account ID.' The tool description adds no additional meaning to the parameter, so the schema carries the semantic weight; the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('videos in Cloudflare Stream'), making the core purpose understandable. It does not explicitly differentiate from the sibling get_stream_video, but the contrast between listing and getting a specific video is reasonably inferable from the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_stream_video, nor any mention of pagination, filtering, or other conditions. The agent must infer usage solely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the listing action and does not mention read-only safety, pagination, output shape, rate limits, or other behavioral traits. 'List' implies a read operation, but nothing is explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise and efficiently states the core purpose, though the brevity leaves out useful behavioral and contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and the schema fully documents that parameter. However, there is no output schema and no annotations, so the description would need to explain return values, pagination, or route object contents to be fully complete; it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter account_id is already described in the schema. The description adds no meaningful parameter semantics beyond rephrasing 'for an account', so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a resource ('team network routes'), and an account scope, making the basic action clear. It does not explicitly distinguish this from sibling tools like list_teamnet_virtual_networks or list_magic_transit_routes, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_teamnet_virtual_networks or get_teamnet_virtual_network. 'For an account' implies the account_id parameter but gives no context about exclusions, prerequisites, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carres the full burden of behavioral disclosure. It conveys only that this is a listing operation, with no mention of pagination, response contents, whether all tunnel states are included, or account-scoping semantics — all relevant behaviors for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short front-loaded sentence with zero filler; every word earns its place and the verb leads. It loses a point only because the brevity leaves usage and behavioral context unstated, though those gaps are penalized in their own dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate to invoke correctly: one required, fully documented parameter and a single clear operation. However, with no annotations and no output schema, the description omits pagination and return-shape details that an agent enumerating a large tunnel inventory would reasonably need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; account_id is already documented as 'The account ID'. The phrase 'in an account' loosely corroborates the parameter's role but adds no format, default, or scope detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Cloudflare Tunnels') with account scoping, making the tool's function unmistakable. It differntiates inherently from get_tunnel (singular fetch) and get_tunnel_configuration (config read), though it never explicitly disambiguates from list_magic_transit_ipsec_tunels/ list_magic_transit_gre_tunels, which are a different tunnel product family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over get_tunnel, list_tunnel_connections, get_tunnel_configuration, or the Magic Transit tunnel listings. The text only says what the tool does; when-to-use and when-not-to-use are left entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only says 'List Worker builds for an account' and does not mention return format, pagination, ordering, or that the operation is read-only, all of which would matter to an agent calling this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant clauses. It leads with the action verb and states the resource and scope directly, which is appropriately sized for a simple one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description leaves important context unexplained: what a Worker build is, what the response contains, and how this differs from list_worker_deployments or get_worker_build. An agent could call it, but not with full confidence about the result or the reason to prefer it over similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single account_id parameter is already documented in the schema. The phrase 'for an account' lightly reinforces the parameter's role, but the description adds no details about ID format, required scope, or how to obtain the account ID. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Worker builds') scoped to an account, so an agent can tell it apart from most siblings like list_zones or list_dns_records. However, it does not explicitly distinguish 'builds' from related Worker siblings like list_worker_deployments or get_worker_build, leaving some potential ambiguity about what a build is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative Worker-related tools such as list_worker_services, list_worker_deployments, or get_worker_build. The description implies the obvious case (need a list of builds) but provides no exclusions, conditions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. 'List' weakly implies a read-only operation, but the description does not mention pagination, result limits, ordering, filtering, or what happens when no instances exist. This is insufficient for a list endpoint with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is terse, but given the small parameter surface, it does not waste the agent's attention. It simply lacks benefit beyond being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should help the agent understand what the response contains or how the listing behaves. It does neither, and it omits pagination and filtering behavior that matter for a list operation. The low parameter count helps, but important contextual information is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with account_id and workflow_name both having clear descriptions. The tool description itself adds no parameter-level meaning beyond the schema, but the schema already documents the two required parameters adequately, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('instances of a Workers Workflow'), so the core action is clear. It does not explicitly distinguish itself from sibling tools like list_workflows or get_workflow_instance, but the resource phrasing is specific enough to infer the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_workflow_instance or list_workflows. There is no mention of prerequisites, exclusions, or context that would help an agent decide between this and similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'List,' implying a read-only operation, but does not state whether results are paginated, scoped to the account, filterable, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no filler. It is appropriately short for a simple list action, though it skips the behavioral and usage details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple required parameter and no output schema, the tool is low-complexity and the schema covers the parameter. However, the description lacks any account-scope, pagination, or selection context, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: account_id is the only parameter and is documented as 'The account ID.' The description adds no parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact operation ('List') and resource ('Zero Trust subnets'), making the tool's function immediately clear. It is distinguishable from sibling list tools because no other sibling targets Zero Trust subnets, though it does not add qualifiers or explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool rather than related list tools such as list_zerotrust_hostname_routes, list_teamnet_routes, or list_ip_prefixes. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It only restates the validating purpose without detailing what `valid` means, what response the caller should expect, whether it is a read-only operation, or how the token is supplied. There is no contradiction, but also no meaningful behavioral context beyond the name and a brief verb phrase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words and is easy to parse. It loses a point only because brevity comes at the expense of needed context about the token type or account relationship.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the definition is minimally viable: an agent can infer it should call with an `account_id` and expect a validity result. But because the tool name references `account` and the description does not explain the token/account relationship nor the expected return shape, the context is incomplete enough to be only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% and `account_id` is already described as 'The account ID'. The description does not add any additional meaning about how `account_id` relates to the token being verified, so it neither meaningfully improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Verify') and a specific resource ('an API token'), making the core purpose understandable. However, it does not differentiate this tool from the sibling `verify_token`, and the account scope present in the name is not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives such as `verify_token`, `get_account_token`, or `list_account_tokens`. The description only states what it does, not the conditions under which it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Get details' merely restates the operation and adds no information about return shape, error behavior, authentication needs, or whether the report content is scoped to the account. It does not contradict anything, but it does not meaningfully illuminate behavior beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which makes it easy to parse. It is slightly under-specified, but there is no waste; it could have added useful context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the returned 'details' contain and any notable behaviors. It does neither. The two required parameters are documented in the schema, but an agent cannot predict the response shape or know whether the operation has restrictions, making the description inadequate for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 even without parameter information in the description. The schema already documents account_id and report_id with basic descriptions, and the tool description adds no additional meaning about how these identifiers relate or what constraints apply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('abuse report'), and the singular phrasing indicates this returns one report's details rather than a list. It is implicitly distinguished from the sibling list_abuse_reports, but it does not explicitly mention that report_id is the identifier or clarify what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need details about a specific abuse report, and list_abuse_reports would be used to enumerate reports. However, it provides no explicit guidance on when to prefer this tool over the sibling listing tool, nor any preconditions such as needing an already-known report_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It states the resource and implies a read operation via 'Get', but does not mention authentication requirements, whether the response contains sensitive key material, or any other side effects. This is a meaningful gap for a security-related configuration endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, and the key qualification 'signing keys for tokens' is included alongside the resource name. It is easy to scan and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-style endpoint this is minimally adequate, but the lack of annotations or output schema means the agent has no information about return shape or when not to use it. The description covers only the resource name and leaves usage and behavioral details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter account_id already documented as 'The account ID'. The description adds no further meaning about how account_id is used or what the returned configuration looks like, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific operation ('Get') and resource ('Access keys configuration'), and the parenthetical clarifies these are signing keys for tokens, which separates it from Access app/policy/service-token tools. It doesn't explicitly contrast with sibling tools, but the parenthetical does enough to identify the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool versus the many sibling Access tools such as list_access_service_tokens, get_access_certificate, or get_access_organization. The only implied context is the resource name itself, so the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only fetch, but the description does not state what happens if the ruleset is not found, whether account-level permissions are required, or what the response contains. For a tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single six-word sentence with zero wasted words; the verb and resource scope are front-loaded. It is efficiently sized for the content it delivers, and the thinness of information is a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter get-by-ID tool, the core operation is conveyed adequately. However, with no output schema, the description does not indicate what the response contains, and it omits any routing between account-level and zone-level ruleset tools. Adequate for the simplest case, but clear gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters are documented ('The account ID' and 'The ruleset ID'). The description adds only the context that the ruleset is account-scoped, which lightly reinforces the role of account_id but provides no syntax, format, or relationship details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a precise resource ('account-level ruleset'), and the granularity ('specific', i.e., one item vs. a list). The 'account-level' qualifier distinguishes it from sibling get_ruleset, which appears to be zone-scoped given the surrounding zone-level rule tools. It is close to a restatement of the name but does pin down the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no named alternatives, and no exclusion criteria. An agent must infer from sibling names that list_account_rulesets is the listing counterpart and that get_ruleset handles zone-level rulesets; the description itself offers only the implicit 'account-level' hint. There is no statement of when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral transparency burden. It only says 'Get details'—essentially restating the read operation implied by the name—and provides no information about response contents, error behavior, permission requirements, or how the token is scoped to the account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It delivers the core action and resource immediately and is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with 100% schema coverage and two required parameters, the description is minimally sufficient to invoke the tool. However, with no output schema, no annotations, and no mention of what 'details' includes or how this differs from verify_account_token, it is not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have full schema description coverage, so the schema already explains token_id and account_id. The description adds no parameter-level meaning beyond identifying the resource as an API token, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (get) and resource (API token), and 'details' implies a single-token lookup, which separates it from list_account_tokens. It does not explicitly contrast itself with verify_account_token or other token-related siblings, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention list_account_tokens for enumeration, verify_account_token for validation, or any prerequisite checks, leaving the agent to infer the appropriate context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states that the tool returns recent activity and enumerates the kinds of activities included, which is useful. However, it does not clarify pagination behavior, default time ranges, data volume expectations, or the lack of side effects beyond what the 'get' name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It communicates the resource scope and return contents efficiently, though it repeats the tool's name somewhat and could have used the space to add constraints or distinctions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no output schema, and no annotations, so the description needs to provide more context. It explains what kind of activity is returned but not the response structure, pagination semantics, default behavior when date filters are omitted, or operational caveats. An agent would still need to infer several important calling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, such as how 'since' and 'before' interact, default pagination values, or ordering of results, but the schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as retrieving audit logs for a Cloudflare account and specifies the content categories: user actions, API calls, and configuration changes. It is distinguishable from nearby siblings like get_access_logs, but it does not explicitly name or contrast itself with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when account-level audit logs are needed, but it provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no context about limitations such as retention windows or when filters should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation but does not mention output shape, job status information, permissions, or any other behavioral details. It is not misleading, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the action and resource. It is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that all three parameters are fully documented in the schema, this is minimally sufficient for an agent to make the call. However, with no output schema or annotations, the description leaves the return value ('details') underspecified and does not clarify how this tool relates to sibling tools like list_autorag_jobs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Get details of an AutoRAG job.' It is distinguishable from list-style siblings like list_autorag_jobs, but it does not explicitly differentiate itself or clarify what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_autorag_jobs or get_ai_search_job. The description gives no context about prerequisites, typical workflows, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, but it largely restates the getter nature and adds only 'payment status, etc.' It does not disclose whether the data is sensitive, whether it represents current or outstanding billing, or what the response contains. The read-only behavior is implied by the verb but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler: verb, resource, and scope appear immediately, and the parenthetical adds a small content cue. Nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description gives a high-level sense of the return value ('payment status, etc.'), but the vagueness of 'etc.' and the absence of any note on permissions, response shape, or error conditions leave meaningful gaps. It is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; account_id is already described as 'The account ID' in the schema. The description's 'for an account' aligns with that parameter but adds no format, constraint, or usage nuance beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get billing profile') with account scoping and a hint at contents ('payment status'). It is clear what the tool does, though the parenthetical 'etc.' is vague and it does not explicitly distinguish itself from sibling account or subscription getters like get_account or get_zone_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus sibling tools such as get_account, get_zone_subscription, or get_membership. The description only states what the tool does, leaving selection conditions and exclusions unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not disclose what settings are included, what the response contains, whether special permissions are needed, or how missing settings are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, repetition, or irrelevant details. The action and scope are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, this is minimally sufficient, but there is no output schema and no behavioral detail. The agent gets no information about the response shape or the exact meaning of 'bot management settings' beyond the phrase itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents zone_id fully with 100% coverage. The description adds only the 'for a zone' scope and does not provide additional meaning about the parameter's format, source, or behavior, so the schema-based baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a specific resource ('bot management settings'), and a clear scope ('for a zone'), so an agent can tell what the tool targets. It does not explicitly differentiate itself from related security/settings getters among the siblings, though 'bot management' is fairly distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus other get_* settings tools, no mention of alternatives, and no stated exclusions. The agent must infer usage almost entirely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation via 'Get' but does not state what the configuration contains, the response format, account-scoping requirements, or whether any special permissions are needed. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five words, single clause, verb front-loaded with the resource immediately after. Every token earns its place; nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is minimally adequate, but 'configuration' is vague — it does not explain what the ASN configuration contains or what the response looks like, and no output schema exists to fill that gap. The ambiguity with get_botnet_feed_asn_report is left unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is already documented as 'The account ID'. The description adds no parameter-level detail, but the schema fully covers the single required parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('botnet feed ASN configuration'), which clearly states what the tool does. It does not explicitly differentiate from the near-named sibling get_botnet_feed_asn_report, though the resource terms differ (configuration vs report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With siblings like get_botnet_feed_asn_report and get_intel_asn, an agent has no basis to decide which to call; the description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states that the tool 'gets' settings, implying a read operation, but provides no details about response contents, required permissions, error behavior, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It states the action and the target resource efficiently and is appropriately sized for a simple one-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET operation with one fully documented parameter, the description is minimally viable. However, with no output schema and no annotations, it would benefit from briefly indicating what kind of settings are returned or how this differs from cache rules and general zone settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter zone_id is already described as 'The zone ID'. The description adds no new parameter semantics, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Get cache settings for a zone." It clearly indicates the operation and scope, but it does not distinguish itself from closely related siblings such as get_zone_settings or get_cache_rules, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or relationships to sibling tools like get_cache_rules or get_zone_settings, leaving the selection decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get details' implies a read operation but does not disclose what happens if the custom hostname is not found, whether the response is paginated, what fields are returned, or whether special permissions are required. This is minimal transparency for a GET-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the operation and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool, the description is adequate but not complete. It does not explain how this tool relates to list_custom_hostnames, what constitutes 'details', or what the response shape looks like, and there is no output schema to compensate. The parameter validation is entirely delegated to the schema, which is acceptable but leaves usage context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (zone_id and custom_hostname_id), so schema coverage is 100%. The description adds no parameter-specific meaning beyond what the schema states, which meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get details') and resource ('custom hostname'), and the word 'specific' signals that this is a single-resource retrieval rather than a list operation. It implicitly distinguishes itself from the sibling tool list_custom_hostnames, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_custom_hostnames. There is no mention of prerequisites like obtaining the custom_hostname_id first, nor any exclusion criteria. This leaves the agent to infer context from the parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of specifying behavior, but it only says 'Get,' which implies a read. It does not mention response format, pagination, required permissions, or whether the rules are zone-level pre-configured rules managed elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation, the description is minimally adequate and the zone_id is the only input needed. However, the lack of an output schema and annotations means a bit more context about what is returned and any special behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single required parameter zone_id is documented as 'The zone ID.' The description adds only 'for a zone,' which does not enhance the schema meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Get'), resource ('Layer 7 DDoS protection rules'), and scope ('for a zone'). It distinguishes itself from closely named siblings like get_ddos_l4_rules by specifying Layer 7, though it does not explicitly call out the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool over alternatives such as get_ddos_l4_rules, get_rate_limiting_rules, or list_zone_rulesets. The only implied signal is the layer-7 qualifier, which is not enough to help an agent choose confidently among the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' implies a read operation, but it does not state whether permissions are required, what response shape to expect, whether data is scoped by account_id, or any error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core operation and resource immediately and earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool, the description combined with the complete schema is minimally sufficient to invoke the tool. However, with no annotations and no output schema, it leaves the return format, required permissions, and edge cases implicit, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters (account_id and profile_id). The description adds no additional parameter-level meaning or constraints beyond what the schema provides, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('details of a specific DLP profile'). It is not a tautology and the word 'specific' implies single-resource retrieval, which distinguishes it from sibling list_dlp_profiles. However, it does not explicitly contrast itself with related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus list_dlp_profiles or other DLP tools. The word 'specific' implies it is for a single known profile, but there is no explicit context, prerequisite, or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only restates the read intent implied by the tool name and does not disclose response shape, permissions, rate-limit implications, or any side-effect-free guarantee beyond the word 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and resource, with zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple two-parameter read operation where the schema fully documents the inputs. However, with no output schema and no annotations, the agent is not told what fields the returned DNS record details include or how to obtain dns_record_id via a list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented with clear descriptions ('The zone ID', 'The DNS record ID'). The tool description adds no extra parameter meaning, but none is needed for these straightforward identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pairing ('Get details of a specific DNS record') and the word 'specific' signals singular lookup rather than listing. It does not explicitly name sibling tools like list_dns_records, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives such as list_dns_records or get_dnssec. There is no mention of prerequisites such as obtaining the dns_record_id first, nor any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get', which is essentially restating the tool's name, and does not describe what the settings include, what response to expect, required permissions, or any edge conditions such as whether the zone must have email routing configured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and no unnecessary repetition of schema fields. It is well-structured and front-loaded for a simple one-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema and no annotations, this is minimally viable but leaves gaps: it does not clarify what the returned settings contain, how it relates to list_email_routing_rules/list_email_routing_addresses, or what conditions apply. An agent could probably call it correctly, but would lack expected context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents zone_id as 'The zone ID'. The description adds only 'for a zone', which mirrors the existing parameter rather than providing new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear operation ('Get') on a specific resource ('email routing settings') scoped to a zone. It is not confused with unrelated tools, but it does not explicitly differentiate from siblings such as list_email_routing_rules or list_email_routing_addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over related alternatives, nor any prerequisites such as whether email routing must be enabled. The only contextual hint is the phrase 'for a zone', which is already implied by the required zone_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. The verb 'Get' implies a read-only operation, which is a meaningful safety signal, but nothing else is disclosed: no return format, error behavior, or access requirements. For a single-fetch tool this is acceptable but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence has zero fluff and is front-loaded, but it earns little of its place: it essentially restates the tool name without adding situational value. It is under-specified rather than artfully concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 2-parameter get-by-id tool, the description is nearly sufficient, but it leaves the ambiguity with `get_healthcheck` unresolved and gives no indication of where account_id or healthcheck_id come from. These gaps are minor for a simple fetch but real.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema. Per baseline, the description need not explain parameters, and it doesn't. It adds no contextual hints about how to obtain the IDs, but the schema covers the structural meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('details of an endpoint healthcheck'), which is clear and not a tautology. However, it fails to differentiate from the similarly named `get_healthcheck` sibling, leaving a potential confusion point unresolved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `list_endpoint_healthchecks` or `get_healthcheck`. There is no mention that a healthcheck_id must first be obtained from a list call, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. The verb 'Get' implies a read-only operation, but nothing is said about the nature of the statistics, authentication needs, or response behavior. This is a bare one-liner that adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource, so it earns a high score on conciseness despite being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter, no nested objects, and no output schema. Given that simplicity, the description is minimally viable, but it does not explain what statistics are returned or what period/metrics they cover, leaving some ambiguity for an agent selecting and consuming the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the account_id parameter is already fully documented in the input schema. The description adds no extra semantic detail about the parameter, but because the schema fully covers it, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a specific resource ('Cloudflare Images usage statistics'), making the tool's purpose unambiguous. It does not explicitly contrast with siblings like list_images, but the phrase 'usage statistics' makes the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over list_images, get_zone_analytics, or other analytics endpoints. The intended use case is only implied by the name and description, with no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It only says 'Get details,' which implies a read operation, but it does not explicitly state that it is read-only/idempotent, whether special permissions are required, or what kind of detail object will be returned. For a tool with zero annotation support, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no wasted words. It is appropriately concise for a simple getter, though the brevity leaves out useful disambiguation. This is genuine conciseness, not under-specification to the point of tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description still needs to convey enough context for an agent to know what it will receive and how it fits into the workflow. The phrase 'details of an infrastructure target' is vague, and the relationship to list_infrastructure_targets is never stated. The self-describing parameters help, but overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both target_id and account_id already have descriptions. The tool description adds no extra meaning about how the parameters relate, which one identifies the target, or why both are required. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a resource ('details of an infrastructure target'). It distinguishes from list_infrastructure_targets by implying a single, detailed lookup rather than a collection. However, it does not explicitly say the lookup is keyed by target_id and account_id, and 'infrastructure target' is left jargony.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: retrieve details for one target after identifying it. But the description provides no explicit when-to-use guidance, no mention of the sibling list_infrastructure_targets, and no prerequisite context such as needing the account_id and target_id from a prior list call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosure. It only says 'Get' and names the resource, implying a read operation, but it does not describe required permissions, error conditions, or any behavioral nuances beyond what the name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. The resource and scope are front-loaded, and every word in the sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with a fully documented schema, the description is minimally adequate for invoking the tool. However, it omits any usage context, output expectations, or differentiation from related settings tools, and there is no annotation or output schema to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, zone_id, is already described as 'The zone ID.' The description adds no additional parameter meaning, but the schema alone is sufficient, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the resource ('leaked credential check settings') plus the scope ('for a zone'). It is clear enough to distinguish from the related sibling 'list_leaked_credential_detections', though it doesn't explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling settings or detection tools. It neither names alternatives nor states conditions or exclusions; usage is implied only by the tool name and the generic 'for a zone' scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Get details' merely restates the tool's function and adds nothing about response contents, permissions, error behavior, or operational constraints. It is safe to assume read-only, but the description does not explicitly confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. The core action and resource are front-loaded, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET operation, the description plus schema is minimally sufficient to attempt a call. However, with no output schema, the description does not explain what 'details' will be returned, nor does it distinguish this from the sibling list/get Magic Transit tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description does not add meaningful parameter-level detail beyond the schema, which meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'Magic Transit connector' and the modifier 'specific' to indicate this is a singular fetch rather than a list operation. It is clear enough to identify the tool, though it does not explicitly name a sibling to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus list_magic_transit_connectors or how it differs from related get_* Magic Transit tools. The need for an account_id and connector_id is implied by the schema, but no usage context or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. 'Get details' signals a read operation, but the description discloses nothing beyond that: no response shape, error behavior, permissions, or entity relationship. This is minimal and adds little beyond restating the tool's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter get-by-ID tool, the description is minimally adequate. However, there is no output schema and no annotations, so the description should clarify what 'account membership' refers to and what details are returned. The potential confusion with sibling tools like list_account_members is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter membership_id is documented as 'The membership ID.' The description does not add extra meaning to the parameter, but because the schema already fully explains it, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get details of a specific account membership.' It is easy to understand what the tool does, and the required membership_id confirms a get-by-id operation. However, it does not explicitly differentiate itself from siblings such as list_memberships or get_account, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance about when to use this tool versus alternatives like list_memberships or list_account_members. The word 'specific' weakly implies a get-by-ID use case, but there are no stated conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read operation, but does not disclose return structure, requiring permissions, error behavior, or any other operational traits. The description is minimal and adds little beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the verb and resource with no superfluous words. It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with full schema coverage, the description is mostly sufficient. However, with no output schema and no annotation context, the agent is left without any detail about the response shape or how to obtain a valid rule_id, and no mention of list_mnm_rules as the discovery path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both account_id and rule_id have simple descriptions in the schema. The tool description adds no additional parameter context, but the schema already documents the necessary parameters adequately, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a Magic Network Monitoring rule'), so an agent can identify what the tool operates on. It does not explicitly distinguish itself from the sibling list_mnm_rules, though the singular 'a rule' implies retrieving one specific rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_mnm_rules or get_mnm_config. The description simply states the operation without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. 'Get details of a packet capture' only conveys a basic fetch operation and adds nothing about account-scoping requirements, response shape, permissions, or how the capture details are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and everything is front-loaded: the action, the resource, and the unit of work. It is proportionate to the simple scope of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET tool, this description plus the complete schema is enough to invoke the tool. However, with no output schema and no annotations, the actual content of the 'details' is undefined, so the description leaves a meaningful gap about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds no extra meaning about how pcap_id and account_id relate or where an agent would obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and a specific resource ('a packet capture'), so an agent can tell this is a single-item retrieval tool. It is distinguishable from siblings like list_pcaps or get_pcap_ownership by its singular focus, though it does not explicitly emphasize that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use get_pcap instead of related tools such as list_pcaps or get_pcap_ownership. It provides no prerequisites, no selection criteria, and no exclusion notes, leaving usage to be inferred from the name and required pcap_id parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get details', implying a read operation, but says nothing about required permissions, response shape, error behavior, or whether the call has side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise and easy to parse, though it would benefit from more substance in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with fully documented parameters, this is adequate, but the absence of an output schema and the vague 'details' wording leave the agent without information about what the response contains or any account-scoping caveats. It covers the basics but not the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have straightforward descriptions ('The share ID' and 'The account ID'). The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and names a specific resource ('R2 share'), which helps distinguish it from collection-oriented siblings like list_r2_share_recipients and list_r2_share_resources. It is slightly generic because 'details' does not enumerate what fields are returned, but it is not tautological or misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives. It neither states that it is for a single share lookup by ID nor mentions that list_r2_share_* tools should be used for enumerating shares, recipients, or resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-type 'get' operation, but does not state what details are returned, whether the call requires special permission, or how it behaves on invalid IDs. No side-effect or output context is provided beyond the bare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the operation and object in minimal space. There is no fluff or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with all parameters documented, this is minimally adequate: an agent knows which IDs are required and that details are returned. However, there is no output schema and the description does not clarify what 'details' include, nor does it add context about the livestream entity's relationship to related realtime tools. Slightly more output or usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all three parameters are simple ID strings with clear descriptions. The tool description adds no further parameter meaning, but it doesn't need to because the schema already documents each parameter adequately. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the specific resource ('Realtime Kit livestream details'), so an agent knows it fetches livestream details. It does not explicitly contrast with sibling list_realtime_livestreams, but the singular resource and 'get' framing make the purpose reasonably distinct. Slightly generic 'details' keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives such as list_realtime_livestreams or get_realtime_session. No prerequisites, context, or exclusions are mentioned. Usage must be inferred entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'Get details' and does not describe response behavior, permission requirements, or any side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no fluff or repetition. It is appropriately sized for a simple retrieval operation and front-loads the core intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-schema-documented parameters and no nested objects, so a minimal description can be viable. However, the lack of any return-format description and alternatives guidance leaves material gaps for an agent selecting or invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds no further meaning about the relationship between account_id and site_id or how they should be resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: it gets details of a RUM site. The name and singular phrasing distinguish it from list_rum_sites, but the description does not explicitly contrast it with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus list_rum_sites or any other alternative. There is no mention of prerequisites, filtering, or scenarios where a different tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that this is a read operation returning 'details', but it does not elaborate on what those details are, how the result is scoped to the account, what the response format looks like, or any error/auth considerations. The description barely adds anything beyond what the tool name already communicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence with no filler. It is front-loaded with the verb and resource. Every word earns its place, and nothing is repeated from the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required string parameters, no nested objects, no enums), so the minimal description is close to sufficient. However, there is no output schema and the description does not clarify what 'details' are returned for an ACL, leaving the agent to guess at the response shape. Adequate for a simple get-by-ID tool, but a clear gap exists around return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both account_id and acl_id have descriptions ('The account ID', 'The ACL ID'), so the schema fully documents the parameters. The description adds no parameter-level information, but per the rubric the baseline of 3 applies when the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('secondary DNS ACL'), and the word 'specific' signals this is a fetch-by-ID operation rather than a list operation, distinguishing it from sibling list_secondary_dns_acls. However, it does not explicitly differentiate it from the many other get_* siblings in the same domain (e.g., get_secondary_dns_peer, get_secondary_dns_tsig), so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The word 'specific' weakly implies the caller already has an ACL ID, and the required acl_id parameter reinforces that, but no explicit when/when-not conditions or alternative tools (like list_secondary_dns_acls for enumeration) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Get details' implies a read-only operation, but it does not describe what details are returned, whether the job must exist, error behavior, or any account-scoping requirements. For a simple GET-style tool this is minimal but still somewhat thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and resource, making it easy to scan. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward two-parameter read operation, the description is adequate but sparse. There is no output schema, so the description should ideally say more about the returned details. Given the very large sibling list, a brief note clarifying that this retrieves a specific Slurper migration job would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both job_id and account_id. The description adds no additional parameter semantics beyond what the schema supplies. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get details of a migration job.' It is distinct from its most relevant sibling, list_slurper_jobs, by signaling a singular detail retrieval. The term 'migration job' could be slightly ambiguous, but combined with the tool name it is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention list_slurper_jobs or clarify that you should list jobs first and then call get_slurper_job with a specific job_id. The usage context must be inferred entirely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral context beyond the verb 'Get'. It does not disclose whether the operation is read-only, what permissions are required, what the response looks like, or how the vnet is scoped to the account. The description adds no value beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It front-loads the operation and the resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool, the description is minimally viable: an agent can infer that it needs account_id and vnet_id and that it will get details. However, with no output schema and no explanation of the returned details or account-scoping behavior, the description leaves some contextually important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for both parameters, with descriptions for vnet_id and account_id. The tool description does not add any additional meaning about how the parameters relate to each other or the expected format, so the schema is left to carry the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Get', and a specific resource, 'team virtual network', clearly indicating a single-resource retrieval operation. The get/list distinction from sibling list_teamnet_virtual_networks is implicit, though the description does not define what 'details' means or which fields are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_teamnet_virtual_networks or get_magic_transit_route. The description only states what the tool does and does not mention any prerequisites or exclusions, so an agent must rely on the tool name to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates that the tool 'gets' settings, which implies a read operation, but it does not describe the response shape, potential errors, or any other behavioral traits beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler: action, resource, and scope are all present. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter, this is minimally adequate, but there is no output schema and no differentiation from the sibling get_ssl_settings tool. An agent may struggle to anticipate the response format or know when to select this tool over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter zone_id is documented as 'The zone ID.' The description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the specific resource ('Universal SSL settings'), and the scope ('for a zone'). It identifies the correct product area, but it does not explicitly differentiate itself from the similarly named sibling get_ssl_settings, leaving the relationship implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool over get_ssl_settings, get_total_tls_settings, or other settings-related tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the operation as 'Get details', revealing little about response content, error cases, or what is actually returned for a Vectorize index.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to stating the tool's basic operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET tool, the schema plus description is minimally callable. However, there is no output schema and the description does not explain what 'details' means, nor does it distinguish this from list_vectorize_indexes, leaving some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions for account_id and index_name. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource, 'Vectorize index', so the core action and target are clear. It does not explicitly differentiate from the sibling list_vectorize_indexes or say that it targets one specific index by name, but the singular 'a Vectorize index' provides enough basic clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_vectorize_indexes. The fact that an index_name is required is only visible in the schema, not called out in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral transparency burden. The verb 'Get' implies a read-only operation, but the description does not disclose whether the response is paginated, what fields are returned, whether there are permission requirements, or any other behavioral details. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It conveys the essential action, resource, and scope in the fewest words possible, which is ideal for this low-complexity tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation, the description is minimally adequate: the agent knows what to call and which parameter to provide. However, there is no output schema and no description of the return shape or pagination behavior, so the tool is not fully self-contained for an agent that needs to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter zone_id is already documented as 'The zone ID.' The description's phrase 'for a zone' adds minimal semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get custom WAF rules for a zone.' It clearly identifies the operation and scope, and the word 'custom' helps distinguish it from the sibling get_waf_managed_rules. However, it does not explicitly call out that distinction or name alternatives, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_waf_managed_rules, get_rate_limiting_rules, or list_firewall_rules. The zone scope is implicit in the description and schema, but no exclusions, prerequisites, or comparison to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it adds nothing beyond the basic read semantics implied by 'Get'. It does not indicate what the configuration output contains, how it is structured, or any zone-scoping details beyond the schema. It is not misleading, but it is behaviorally thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence with no filler. The key information ('Get managed WAF rules') is front-loaded, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter, the core invocation is adequately clear. However, with no output schema and no annotations, the description gives no hint of the return shape or what 'configuration' comprises, and it does not differentiate from the closely related get_waf_custom_rules. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single zone_id parameter already described as 'The zone ID', so the baseline is 3. The description's phrase 'for a zone' loosely maps to zone_id but adds no additional meaning, format details, or constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a specific resource ('managed WAF rules configuration') scoped to a zone. The word 'managed' implicitly contrasts with the sibling get_waf_custom_rules, providing some differentiation. However, 'configuration' is slightly ambiguous about whether the tool returns the attached managed rulesets, overrides, or both, which prevents a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives such as get_waf_custom_rules, list_zone_rulesets, or get_ruleset. It does not state exclusions, prerequisites, or the conditions under which this tool should be preferred. An agent choosing among the many WAF-related siblings gets no comparative help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavioral traits. It only restates the read action 'Get details' and offers no information about side effects, required permissions, response contents, or error behavior. The 'get' verb implies read-only, but no additional behavioral context is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler or repetition. It front-loads the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with fully documented parameters, the core invocation path is clear. However, the tool lacks output schema, usage guidance, and relationship to sibling tools, leaving some gaps for an agent deciding whether this is the right call and what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with simple descriptions, so schema coverage is 100%. The description adds no parameter-level meaning beyond what the schema already provides, which meets the baseline for adequate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Get details of a workflow instance'. It clearly identifies the resource and what is returned, and is distinct from list_workflow_instances by implying a single-instance lookup. However, it does not explicitly contrast itself with the sibling get_workflow, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_workflow or list_workflow_instances, nor any mention of prerequisites or typical use cases. The agent must infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation via "Get," but does not state what the response contains, whether errors like 404 occur, or what permissions are required. This is a minimal but incomplete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler or repeated information. It front-loads the essential purpose and is appropriately sized for a simple one-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no nested objects, the description is adequate but thin. It identifies the resource and parameter, but with no output schema and no annotations, the agent does not know what "details" will be returned and has no disambiguation from other zone-related getters. Some gaps remain, but the simple shape keeps it at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents zone_id as "The zone ID" with a maxLength constraint. The description adds no additional semantic detail about the parameter, such as format or how to obtain it. The baseline score of 3 applies because the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and object: "Get details for a specific zone." The single required parameter zone_id reinforces that this is a singular lookup. However, it does not explicitly distinguish itself from sibling tools like get_zone_settings, get_zone_analytics, or get_zone_setting, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus list_zones or the many get_zone_* sibling tools. There is no mention of prerequisites such as ownership of the zone or how to obtain zone_id. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get zone hold status,' which implies a read operation, but it does not disclose response behavior, possible status values, authorization needs, or any side effects. This is minimal coverage at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that front-loads the core action and resource. There is no redundant wording or filler, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter getter, so the description is minimally sufficient to identify the call. However, there is no output schema and the description does not explain what 'status' will look like or what values may be returned, leaving an important gap for an agent consuming the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter zone_id is already described as 'The zone ID' in the schema. The description adds no additional meaning about the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it gets the zone hold status for a zone. It is clear about what the tool does, though it does not explain what 'zone hold' means or explicitly differentiate it from sibling getters like get_zone or get_zone_settings. The target resource is still unambiguous enough for an agent to select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no explicit exclusions, and no context about prerequisites. The intended use is only implied by the verb 'Get' and the resource name, so the description provides no real direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not mention permissions, response format, side effects, or any operational constraints, leaving the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It front-loads the action and resource clearly, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description is minimally adequate. However, with no output schema and no usage guidance, the description does not explain what the returned retention settings look like or when this tool should be preferred over related settings getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, zone_id, is already described as 'The zone ID'. The description adds no additional meaning beyond the schema, but because the schema fully documents the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: getting zone logs retention settings. It is not a tautology because it expands the name into a complete phrase, though it does not explicitly distinguish itself from sibling settings getters like get_zone_settings or get_zone_setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as get_zone_settings or list_logpush_jobs_zone. The description leaves the agent to infer the appropriate context from the name alone, with no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that the operation is a list, with no mention of whether results are paginated, whether any read-only guarantees exist, what data is returned, or any account-level access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to identifying the operation and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one fully documented parameter, the description is minimally adequate. However, it omits any mention of pagination, related single-page retrieval via get_access_custom_page, or what kind of data is returned, leaving some context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and account_id already has a clear description. The tool description's phrase 'for an account' aligns with the schema but adds no new semantic detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('Access custom pages'), and a scope ('for an account'), so the tool's purpose is clear. It does not explicitly differentiate itself from the sibling get_access_custom_page, but the list-vs-get distinction is reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of related siblings like get_access_custom_page, nor any mention of prerequisites, pagination, or filtering. The intended use is only implied by the resource name, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It states the action but does not mention that this is a read-only operation, what the response looks like, whether pagination applies, or any account-level authorization requirements. For a tool with no output schema, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant or filler content. It front-loads the action and resource clearly, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, no annotations, and no output schema, the description provides the minimum viable context: what is listed and at what scope. However, it omits response shape, pagination behavior, and any guidance on when to choose this over related access list tools, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, account_id, with the description 'The account ID', so schema coverage is 100%. The tool description's phrase 'for an account' adds minimal reinforcement but no new format, source, or usage detail beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: 'List Access identity providers for an account' names the verb ('List'), the resource ('Access identity providers'), and the scope ('for an account'). It is easily distinguishable from siblings like get_access_identity_provider or list_access_apps, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_access_identity_provider or other list_access_* tools. The intended context is only implied by the word 'List'; there are no exclusions, prerequisites, or selection criteria stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists Access tags, with no mention of pagination behavior, response shape, or what an Access tag actually is. The read-only nature is only implied by 'List', and the absence of an output schema leaves the return format completely unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is tightly worded and front-loaded with the action and scope. There is zero fluff, and every word earns its place for a tool this simple.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one fully documented parameter, so the schema covers the invocation side well. However, with no annotations and no output schema, the description leaves pagination and response format unstated — material gaps for a list operation — though the low complexity keeps the shortfall moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id already documented as 'The account ID' in the schema itself. The description's 'for an account' reinforces the parameter mapping but adds no new semantic meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), resource (Access tags), and scope (for an account), which clearly matches the tool name and its account_id parameter. However, it does not differentiate this from sibling tools like list_access_apps, list_access_policies, or list_access_groups, so an agent must infer distinctions from the resource name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over alternatives. Among the many siblings are list_access_apps, list_access_policies, list_access_groups, get_access_tag, and list_access_service_tokens, but no conditions, exclusions, or alternative names are mentioned to aid selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the tool name in sentence form. It does not explain what defines an 'active' session, whether pagination applies, what happens if the user has no sessions, or what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant detail. It is appropriately sized for a simple list operation and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity with two well-documented parameters, but the absence of an output schema and annotations means the agent is left to infer the session object shape and any list-level behavior. The description covers the core purpose but not enough surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both user_id and account_id. The description adds no extra semantic meaning beyond the resource scope, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pair: 'List active sessions for an Access user.' This is specific enough to distinguish the action from nearby siblings like list_access_users or list_access_user_failed_logins, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, such as list_access_user_failed_logins or list_access_logs. There is no mention of context, prerequisites, or contrasting use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not disclose pagination, result format, authorization needs, or how far back failed logins are reported. It provides minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that immediately states the action and the resource. There is no filler or redundant information, making it appropriately concise for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation, the description is minimally adequate: an agent can identify the required parameters and knows the result is a list of failed logins. However, with no output schema and no annotations, it would benefit from a note about result granularity, pagination, or how this list is scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage. The description adds the context that the user is an Access user, but it does not clarify how account_id and user_id relate or whether additional filters are expected. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: list failed logins for an Access user. It is distinguishable from sibling tools like list_access_users and list_access_user_active_sessions by the 'failed logins' scoping, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of related tools such as list_access_logs or list_access_user_active_sessions. There is also no mention of any time-range, account-context, or prerequisite needed to call it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' implies read-only behavior, but the description does not disclose pagination, result limits, ordering, permission requirements, or what a 'user' entry contains. There is no contradiction, just missing behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler. The verb, resource, and scope are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list endpoint this is minimally viable: the agent knows what to call and with which required input. However, without annotations or an output schema, the description omits pagination/return behavior and offers no sibling differentiation, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and account_id is already documented as 'The account ID'. The description adds no extra parameter meaning, but the schema fully covers the single parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action (List) and resource (Access users) scoped to an account, which is unambiguous at a basic level. It does not, however, distinguish itself from nearby sibling tools such as list_account_members or list_access_user_active_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives, no exclusions, and no mention of prerequisites beyond the schema's required account_id. Given the large sibling set of list_access_* and list_*_members tools, the agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'List account-level rules lists' and gives examples; it does not mention pagination, ordering, response format, permissions, or whether the account_id is the only required scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. The core operation and scope are front-loaded, and the parenthetical examples add useful context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one well-documented parameter, the description is minimally viable. However, it lacks detail about return value shape, pagination, and how it differs from the closely related singular and item-list tools, which an agent may need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter, account_id, as 'The account ID' (100% coverage). The description reinforces that this is an account-level operation, but it adds no extra detail about the parameter's format, constraints, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('account-level rules lists') with concrete examples ('IP lists, hostname lists, etc.'). It is clearly readable and distinguishes from zone-level list tools via the 'account-level' qualifier, though it does not explicitly name related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related siblings such as list_account_rules_list, list_account_rules_list_items, or list_zone_rulesets. The context is implied by the name and description, but there are no explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for exposing behavioral traits. It implies a read-only listing operation, but discloses no auth requirements, pagination behavior, ordering, filtering, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb and resource, zero filler. The description is appropriately sized for a simple one-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Basic calling intent is clear and the one parameter is documented, but with no output schema and no annotations, the description omits usage context such as pagination or how these API tokens differ from access service tokens. It is minimally viable but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, account_id, already has its own description. The tool description adds no additional meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('List') and resource ('API tokens') with account scope, so an agent can grasp what the tool does. It distinguishes from the singular sibling get_account_token, but it does not explicitly differentiate from list_access_service_tokens, which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of related siblings such as list_access_service_tokens or get_account_token. There are no exclusions, prerequisites, or alternative-selection hints; the description simply states the operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'List'. It does not mention pagination, ordering, filtering, permissions, or response shape, leaving the agent without useful behavioral context beyond the obvious read-only action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the action and resource directly and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, this is minimally viable, but it omits any return-value or pagination details and lacks guidance on choosing this over related tools. The description is adequate for calling the tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, account_id, with a description, so coverage is 100%. The description adds no parameter-level meaning beyond what the schema provides, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('IP address maps'), scoped to an account, making the core action clear. It does not differentiate from sibling tools such as get_address_map or list_ip_prefixes, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like get_address_map or other list tools. Usage is only implied by the verb 'List' and the account scope, with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List' and does not describe pagination, return shape, ordering, or whether the response includes only summaries or full instance metadata. It is not misleading, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the verb and resource, making the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, this is adequate, but it does not explain return values or pagination, and the absence of an output schema means the agent gets no further structural signal. With no usage guidance or sibling differentiation, the description leaves some decisions to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, so the schema already documents account_id. The description's phrase 'for an account' adds no new format or semantic detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('AI Search instances') scoped to an account, so an agent can tell what it does. It does not explicitly contrast itself with close siblings like get_ai_search_instance, though the plural resource name makes the listing intent fairly unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, such as get_ai_search_instance for a single instance or list_ai_search_items for item-level details. There is no mention of prerequisites, typical workflow, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that items are listed. It fails to disclose pagination behavior, what an 'item' is, the return format, or whether any filtering is possible — all relevant for an agent predicting the call'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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loaded with the verb — the description is appropriately sized for a simple listing tool with two parameters. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two required string params, fully documented schema), so the one-liner is minimally viable. However, with no output schema and no annotations, the description leaves gaps: what 'items' means in an AI Search context, whether results are paginated, and how this differs from listing instances or jobs. Adequate for basic invocation but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so account_id and instance_id are already documented in the schema. The description adds no parameter-level meaning beyond echoing the 'AI Search instance' scope, which is the baseline expected when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('items in an AI Search instance'), making the core operation clear. However, it does not explicitly differentiate itself from closely related siblings such as list_ai_search_instances or list_ai_search_jobs, so an agent must rely on the name for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With siblings like list_ai_search_instances, list_ai_search_jobs, and get_ai_search_instance present, an agent receives no help choosing among them — e.g., no indication that instance_id must be obtained first or that 'items' means content within an instance rather than instances themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the burden of explaining behavior. It only says 'List' which implies a read operation, but it does not disclose pagination, response shape, filtering absence, or what an 'operation' contains. This is insufficient for a tool with zero structured behavior metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys verb, resource, and scope without any filler. Every word contributes to the meaning, and the critical zone scoping is stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list call, the description plus schema is minimally viable: the agent knows the action and the required argument. However, the absence of output schema, pagination/behavior details, and any sibling differentiation leaves clear gaps, making this only an adequate definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, zone_id, is 100% covered by the schema description 'The zone ID', and the tool description reinforces it with 'for a zone'. The description adds no deeper semantic information beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List), resource (API Gateway operations), and scope (for a zone). However, it does not distinguish this from the sibling tool list_api_shield_operations or clarify what 'API Gateway operations' precisely are, so it stops short of full disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to prefer this tool over related siblings like list_api_shield_operations, list_api_gateway_schemas, or get_api_gateway_operation, and no indication of context or prerequisites. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the listing action and zone scope, with no mention of return format, pagination, permissions, or any side effects. While 'List' implies read-only behavior, the description adds little beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately short for a simple list operation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers the resource and scope, and the schema covers the parameter. However, with no output schema, no annotation, and no differentiation from sibling tools, the description leaves the agent without enough context to confidently select it in ambiguous situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter documentation, including a clear description for zone_id, so the baseline is 3. The description's phrase 'for a zone' loosely echoes the zone_id parameter but does not add any new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), resourse ('API Gateway schemas'), and scope ('for a zone'), which is clear and actionable. However, it does not distinguish itself from similarly named siblings like list_api_schemas, list_api_shield_schemas, or list_api_gateway_user_schemas, leaving some potential for confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of equivalent tools or conditions that would select one over another, so the agent is left to infer selection based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole behavioral signal; it only restates the read/list operation and adds no details on pagination, return shape, or schema representation. It does not contradict anything, but it also does not disclose behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, no filler, and the action+object are front-loaded. Every word earns its place, though other dimensions pay for the missing elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list call the description is mostly adequate, but with no output schema and no usage/exclusion guidance it leaves the agent to guess how the result differs from list_api_gateway_schemas. It would benefit from clarifying whether 'user-uploaded' means the opposite of 'discovered' and whether results are paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single zone_id parameter is already fully documented in the schema (100% coverage), so the description need not repeat it. It adds no extra semantics but the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete operation ('List') and resource ('API Gateway user-uploaded schemas'), and the 'user-uploaded' qualifier hints at a niche distinct from list_api_gateway_schemas. It is clear but does not explicitly contrast with the near-sibling list_api_gateway_schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence tells an agent when to choose this tool over the similar sibling list tools (list_api_gateway_schemas, list_api_shield_schemas) or what 'user-uploaded' excludes. Context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'List files' implies a read-only operation, but the description does not disclose response shape, authentication requirements, rate limits, or whether the result is a bare file list or includes metadata. The minimal wording is not misleading but is under-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the essential operation and resource immediately, which is appropriate for a low-complexity list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-param tool with no output schema, the description is adequate for selection and invocation, but it does not clarify what information is returned (e.g., file names, sizes, timestamps) or any instance-specific context. The absence of an output schema places more burden on the description than is currently met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters already have meaningful descriptions. The tool description adds no further parameter semantics beyond the implicit context that account_id and rag_id identify the AutoRAG instance; this meets the baseline for a fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('files in an AutoRAG instance'), making the core purpose clear. It is not a tautology because it adds the instance-level scoping, but it does not explicitly differentiate from sibling tools like list_autorag_jobs, leaving that to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives, conditions for use, or exclusions, so an agent must infer from the tool name and siblings rather than from explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'List' and names the resource. It does not mention pagination, output shape, scope, or any other behavioral traits beyond the implied read-only nature of listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It immediately names the action and resource, making it both concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter endpoint, this is nearly sufficient: account_id is documented in the schema and 'List' implies a read operation. However, with no output schema or annotations, the description does not clarify the response shape, pagination behavior, or what a 'request type' actually represents, leaving the agent with some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is already fully described in the schema as 'The account ID', and the description adds no additional parameter context. Since schema description coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'List Cloudforce One request types', which is clear and distinguishes it from sibling endpoints like list_cloudforce_one_events or get_cloudforce_one_request. It does not define what a request type is, but the action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to call this endpoint, what problem it solves, or how it differs from related Cloudforce One tools such as list_cloudforce_one_queries or list_cloudforce_one_indicators. The agent must infer selection purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List' without explaining pagination, return shape, permissions, or whether all interconnects are returned. The read-only nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. The resource and scope are presented clearly and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the minimum context is present: resource, scope, and account_id. However, with no output schema or behavioral details, the agent must infer the return format and any pagination or filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the account_id parameter is fully documented in the schema. The description's 'for an account' adds little beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('Cloud Network Interconnects') and scopes it to an account. It is distinguishable from siblings like get_cni_interconnect because of the plural resource, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus related siblings such as get_cni_interconnect, list_cni_slots, or get_cni_settings. The intended use case is only implied by the word 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the operation is a list, implying read-only, but provides no detail on pagination, return format, required permissions, or account-level scoping behavior beyond the bare phrase 'for an account'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the action and scope, which is appropriate for a simple one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, one documented parameter, and no output schema, the description is minimally adequate for basic invocation. However, without annotations or an output schema it leaves the agent to infer return structure, pagination, and what a CNI slot actually is, so it is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter account_id is 100% covered by the schema description, so the schema already explains it. The description's 'for an account' modestly reinforces the meaning but adds lit le beyond the structured field definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and resource ('CNI slots') and scopes it to an account, so an agent can tell it performs a read-only listing operation. However it does not distinguish this from sibling tools like list_cni_interconnects or get_cni_settings, so it misses the differentiation tht would merit a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description only states what it does, not when it is the right choice, what prerequisites exist, or how it relates to the CNI-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a non-mutating read/list operation but discloses nothing about pagination, limits, sort order, authentication needs, or response shape. For a list operation, pagination behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 8-word sentence with the verb front-loaded. Every word earns its place; there is zero tautology or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description states the essential what and where. However, with no output schema present, the agent has no indication of what a database entry looks like or whether results are paginated, leaving a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single required parameter account_id is already documented in the schema as 'The account ID'. The description adds no parameter-level detail beyond what the schema provides, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a precise resource (D1 SQL databases), and a scope (in an account). The plural 'databases' distinguishes it from the sibling get_d1_database, which targets a single database, though it doesn't name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention how it relates to get_d1_database, nor any exclusions, prerequisites, or conditions that would route an agent to a different sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists posture rules and adds a definition, but does not mention authentication needs, account scope, read-only nature, pagination behavior, or any response characteristics. 'List' implies read-only, but beyond that the behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. The core action and object are front-loaded, and the parenthetical adds useful clarification without padding. It is a model of efficient writing, even if other dimensions lack depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one documented parameter, but there is no output schema and no annotation context. The description explains what the resource is but does not mention what the returned data looks like, how many rules may be returned, or any account-level caveats. It is minimally viable but leaves an agent without important operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter, account_id, already described as 'The account ID'. The description adds no additional meaning about how account_id should be used, so the baseline of 3 is appropriate because the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('device posture rules') and adds a clarifying parenthetical ('compliance requirements') that explains what the resource means. It is clear and distinguishes itself from nearby tools like list_device_policies through the specific 'posture rules' terminology, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_device_policies or list_devices. There is no mention of prerequisites, scope, or context in which device posture rules are relevant, so an agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read operation, but the description does not mention pagination, ordering, filtering, authorization needs, or what data the returned rules contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to identifying the operation and its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description conveys the essential purpose and scope. However, the lack of sibling differentiation and any detail about output behavior leaves moderate gaps, especially since there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the zone_id parameter already clearly described as 'The zone ID'. The description adds no additional parameter semantics, but none are needed because the schema fully documents the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('email routing rules'), and the scope ('for a zone'). It is specific enough to identify the operation, though it does not explicitly differentiate itself from siblings like list_email_routing_addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related alternatives such as list_email_routing_addresses or get_email_routing_settings. The only contextual hint is 'for a zone', but there are no exclusions, conditions, or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'List healthchecks', which implies a read-only operation, but it does not disclose pagination behavior, result limits, ordering, or any other list-specific traits. The description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with the verb and resource. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with a fully described schema, this is minimally viable: an agent knows what to call and with which parameter. However, there is no output schema, no annotations, and no mention of pagination or return shape, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents zone_id as 'The zone ID'. The description's 'for a zone' adds no new meaning beyond the schema, so it does not improve parameter understanding. Baseline 3 applies because the schema carries the full parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('healthchecks') plus the scope ('for a zone'), which clearly states the core operation. However, it does not distinguish itself from sibling tools like get_healthcheck or list_endpoint_healthchecks, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_healthcheck for a single healthcheck or list_endpoint_healthchecks. The intended context is implied by the name and description, but no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state non-mutating behavior, pagination, or any other runtime implications. The parenthetical adds domain context, not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates the action, resource, and a useful clarification with zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, this is minimally viable: it names the action and resource. However, with no annotations and no output schema, the description omits explicit read-only framing and any usage differentiation, leaving some important context for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id already documented, so the baseline of 3 applies. The description adds no parameter-specific meaning, but it does not need to because the schema handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, 'List', and a clear resource, 'Hyperdrive configurations', with a helpful parenthetical clarifying what Hyperdrive is. It is clear but does not explicitly differentiate from the sibling get_hyperdrive_config tool, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like get_hyperdrive_config. The description simply states what it does and leaves the decision entirely to inference, which is especially risky given the large sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies a read operation, but the description does not mention pagination, account vs. zone scoping, permissions, or response characteristics. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and a clear list operation, so the description is minimally adequate. However, it omits any mention of response format, pagination, or relationship to similar sibling tools, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the only parameter, account_id. The description adds no parameter-specific detail beyond what the schema provides, which fits the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List health monitors for load balancers' states a clear verb and resource, and uses 'health monitors' to add specificity. It is distinguishable from siblings like list_load_balancers, though it does not explicitly disambiguate from list_healthchecks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as list_healthchecks or list_load_balancers. The description simply restates the operation without providing context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'List', which implies a read operation, but it does not disclose pagination behavior, response contents, whether the result set is limited/ordered, or any rate-limit considerations. For a list tool this leaves meaningful behavioral traits to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single six-word sentence contains the entire description with zero filler. The verb and core scope are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no output schema and no annotations, the description is minimally adequate: it identifies the operation and the required account scope. However, it omits what the response contains, how pagination works, and how this tool relates to the sibling notification tools, leaving an agent to guess at call expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since account_id is already documented as 'The account ID'. The description adds no parameter-level detail beyond the schema, so the baseline 3 for high coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('notification/alerting policies'), and a scope ('for an account'). It is clear and distinguishable from same-domain siblings like list_notification_history, list_available_alerts, and list_notification_webhooks because the resource term 'policies' is precise. However, it does not explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_notification_history, list_notification_webhooks, or list_available_alerts. The description provides no context for tool selection, no exclusions, and no mention of prerequisites or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description adds nothing beyond what the tool name already conveys. It does not disclose pagination behavior, response shape, permission requirements, or whether results are limited in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clean sentence with zero wasted words. The core subject, action, and scope are all front-loaded. For a simple one-parameter list operation, this is an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required parameter, no nested objects, no output schema), and the description is mostly adequate for that simplicity. However, it does not mention pagination or response composition, and it relies entirely on sibling naming to disambiguate from get_pages_project. With no annotations, a bit more behavioral context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: account_id is fully documented with type, maxLength, and description 'The account ID'. The description's 'in an account' loosely maps to this parameter but adds no format, syntax, or semantic detail beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Cloudflare Pages projects in an account' states a specific verb, resource, and scope. It clearly identifies what the tool does and is not a tautology. However, it does not explicitly differentiate itself from close siblings like get_pages_project or list_pages_deployments, relying instead on naming conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_pages_project would be used for a single project, nor does it offer any exclusions or selection criteria. The phrase 'in an account' implies account-scoped usage but that is minimal context, not real routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not disclose pagination, filtering, response shape, or any account-level access requirements. This is minimal but not entirely empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the operation, resource, and scope efficiently, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no nested objects, the description is minimally adequate. However, with no output schema, no annotations, and no mention of pagination or return format, it leaves some completeness gaps that an agent might need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'account_id' is fully documented as 'The account ID'. The description's phrase 'for an account' adds slight semantic overlap with the parameter but does not provide deeper meaning such as value format or required scope. Baseline 3 is appropriate because the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('packet captures') plus an account scope, making it clear that this is an account-level list operation. It differentiates from the sibling 'get_pcap' by indicating plural listing rather than retrieving a single capture, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as 'get_pcap' or 'get_pcap_ownership'. It does not mention preconditions, pagination needs, or any distinctions in behavior that would help an agent choose among the many list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It communicates a read/list intent, but nothing about pagination, ordering, returned participant fields, auth expectations, or whether the meeting must be currently active. For an unannotated tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and object directly, and every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and its parameters are fully documented, but there is no output schema and no context about what participant information is returned or how results are delivered. An agent can fill in the required IDs, but would need extra inference about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters already have meaningful descriptions in the input schema. The tool description adds no parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List participants in a Realtime Kit meeting.' It is clear enough to distinguish from siblings like list_realtime_meetings or get_realtime_meeting, though it does not explicitly contrast itself with those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related Realtime tools such as list_realtime_sessions or get_realtime_meeting. The only usage signal is the verb 'List', which is implied rather than explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only repeats the verb 'List' and does not mention pagination, ordering, account/app scoping, or what the response contains. While 'List' implies a read-only enumeration, the agent is left without meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and names the resource with no filler or redundant information. It is appropriately sized for a straightforward list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and both required parameters are documented in the schema, so the core invocation is clear. However, with no annotations and no output schema, the description could have added value by stating pagination behavior or the scope of the listed webhooks; it currently offers only the minimum viable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters completely (account_id and app_id), so the schema covers the semantics. The description does not add any additional meaning about how the parameters relate to the list operation, which is acceptable given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb (List) and resource (Realtime Kit webhooks), so an agent understands the operation. It does not explicitly distinguish itself from the sibling get_realtime_webhook, but the plural 'webhooks' and verb 'List' make the basic purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus the many sibling list/get tools, such as get_realtime_webhook or list_realtime_sessions. There are no stated exclusions, prerequisites, or conditions that select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of explaining behavior. It only says 'List Real User Monitoring sites' and does not mention return format, pagination, scope constraints, or any permissions. 'List' implies a read operation, but this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, waste-free sentence with the operative verb and object front-loaded. It is appropriately terse for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description communicates the core action but leaves the response shape and exact account scope unstated. It is minimally adequate but does not enrich the agent's understanding beyond the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id as 'The account ID' with 100% coverage, so the baseline is met. The description adds no additional meaning about how account_id influences the result set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and a specific resource ('Real User Monitoring sites'), expanding the RUM acronym into a meaningful object. It implicitly distinguishes from the sibling get_rum_site by the list-vs-get contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of get_rum_site or when account-scoped listing is appropriate. The agent must infer usage entirely from the tool name and the single account_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only enumeration, but nothing else is disclosed: no pagination behavior, no response format, and no mention that secondary DNS must be configured for the account. For a tool with zero annotation coverage, this is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence with the verb front-loaded; every word earns its place. There is no filler, redundancy, or buried context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one documented parameter, no nested objects or enums), and the account-scoped listing intent is clear enough for invocation. However, with no output schema and no annotations, the agent is left without any hint of the return shape, pagination, or prerequisites (e.g., secondary DNS being enabled), and no sibling differentiation is offered. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single account_id parameter fully described in the schema, so the baseline is 3. The description's 'for an account' modestly reinforces that the listing is scoped to the account_id parameter, but it adds no format, constraint, or behavior details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a specific resource ('secondary DNS TSIG keys'), and a scope ('for an account'), making the action unambiguous. It is naturally distinguishable from nearby siblings like list_secondary_dns_peers and list_secondary_dns_acls because it names the exact resource type, though it does not explicitly call out an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention the closely related siblings — get_secondary_dns_tsig for a single key, or list_secondary_dns_peers and list_secondary_dns_acls for other secondary DNS resources — so an agent gets no help choosing among the secondary DNS cluster tools. Context must be inferred entirely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation and 'for an account' conveys scope, but the description does not disclose pagination behavior, response format, or account-level authorization requirements. This is minimal disclosure for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero waste; the verb, resource, and scope are all front-loaded. Every word earns its place, and nothing is redundant or missing for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity — one fully documented parameter, no enums, no nested objects, no output schema — so the minimal descrption is nearly adequate. However, with no annotations, an agent is left inferring pagination behavior and the shape of the returned connector list, which a short additional sentence could have clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id already documented as 'The account ID', so the baseline is 3. The phrase 'for an account' mildly reinforces the parameter's role but adds no new syntax, format, or validation detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List), resource (WARP connectors), and scope (for an account), making the tool's purpose unambiguous. It distinguishes from siblings like get_warp_connector and list_magic_transit_connectors through the specific resource name and verb, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to choose this tool over alternatives such as get_warp_connector (single connector) or list_magic_transit_connectors (a different connector type). No prerequisites, exclusions, or routing conditions are mentioned, leaving an agent to guess from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure, but it only says 'List' and 'in an account.' It does not disclose pagination behavior, response shape, permissions required, or whether any filtering is applied, leaving significant behavioral details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrasing. It front-loads the action and resource clearly, making it appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no nested objects) and fully documented schema, the description is minimally adequate. However, the absence of an output schema and any mention of pagination or result contents leaves some gaps for an agent trying to predict the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter, account_id, so the baseline is 3. The description adds some scope context ('in an account') but does not add meaning beyond what the schema already provides for the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('Worker services'), and the scope ('in an account'), so it is clear about the core action. However, it does not distinguish this tool from closely named siblings like list_workers, list_worker_routes, or list_worker_secrets, so no sibling differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_workers or get_worker_script. There is no mention of prerequisites, exclusions, or conditions that would help an agent choose this tool confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. 'List' implies a read-only operation, but the description does not mention pagination, result limits, permissions, or what exactly is returned. For an unannotated tool, this leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The verb and resource are front-loaded, and every word contributes meaning, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no nested objects, and the schema fully documents the parameter, so the description does not need to explain inputs. However, with no annotations and no output schema, the description would benefit from noting that the result is a list of workflows and whether pagination or additional options apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter account_id is already described in the schema. The description's phrase 'for an account' merely restates that scope and adds no extra formatting, constraints, or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (List), resource (Workers Workflows), and scope (an account). The title is null, so the description provides the primary semantic signal and clearly identifies the tool as an account-scoped list operation, distinct from related workflow-instance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is 'for an account,' which just mirrors the required account_id parameter. There is no guidance on when to choose this over list_workflow_instances, get_workflow, or list_workers, and no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. The verb 'Get' reasonably implies a read-only retrieval, and 'configuration' suggests the response contains settings. However, it does not explicitly state side-effect-free behavior, response shape, or permissions, though these are less critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: action first, then resource, then scope. It is appropriately brief for such a simple tool, though it does not use its space to add sibling differentiation or behavioral nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema and no annotations, the description is minimally sufficient: it names the resource and the scope. However, it does not describe what the configuration contains or how it differs from similar API Shield/API Gateway config tools, leaving some ambiguity for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, zone_id, with 100% coverage. The description adds only generic zone context and no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get API Shield configuration' with a zone scope. It is clear and unambiguous about the operation, but it does not differentiate from similarly named siblings like get_api_gateway_config or get_api_gateway_settings, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The phrase 'for a zone' only restates what the zone_id parameter already implies, and no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. 'Get details' clearly conveys a read-only, single-resource operation, which is the core behavioral trait, but nothing is said about error behavior, permissions, or response contents. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately sized for a simple getter, though 'details' is vague and the sentence largely restates the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter GET tool with full schema coverage, the description is nearly adequate: an agent can determine the operation and required inputs. However, there is no output schema and no explanation of what 'details' will be returned, nor a pointer to list_calls_apps for discovering app_id, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both account_id and app_id documented in the input schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('specific Calls application'), and the word 'specific' signals singular retrieval rather than listing. It does not explicitly name the sibling list_calls_apps or spell out what 'details' includes, so it is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_calls_apps or get_calls_turn_key. The word 'specific' implies the caller already has an app_id, but the description never states this or provides any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a non-destructive read operation, which is the most important behavioral trait. However, it does not disclose output format, required permissions, error behavior, or whether any account-specific defaulting occurs, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no filler. It earns its place, but it is arguably too sparse because it omits context that would help an agent distinguish CNI settings from related CNI or settings tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter documented in the schema, an agent can at least form a valid call. However, there is no output schema, no annotations, and the description does not explain what the returned CNI settings look like or what CNI means. For a simple one-parameter getter this is minimally complete, but it still leaves ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, account_id, already carries a description in the schema. The phrase 'for an account' maps directly to account_id but adds no extra semantics such as ID format, validation rules, or whether the account must be the caller's own account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get'), the resource ('CNI settings'), and the scope ('for an account'). It is distinguishable from unrelated setting getters like get_ssl_settings or get_zone_settings, though it does not explicitly differentiate from the sibling get_cni_interconnect or clarify what CNI refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_cni_interconnect, list_cni_slots, or other settings getters. It merely restates the basic action without giving selection context, exclusions, or relationships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; saying 'Get ... details' signals a read-only operation that returns policy details and implies no mutation. However, it does not disclose response format, authorization requirements, error behavior, or how to discover policies – a clear gap for an non-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. It would be fair to want more substance, but as written it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter GET with full schema coverage, this is minimally sufficient: an agent knows the action, resource, and required IDs. Yet with no output schema or annotations, it lacks any statement about the returned details or the list tool that supplies policy_id, leaving some context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both policy_id and account_id are already described in the schema. The description adds no extra meaning about how the parameters relate, so it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('email security allow policy'), so an agent can tell this is a retrieval operation. It does not explicitly distinguish itself from list_email_security_allow_policies or other email security getters, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool instead of list_email_security_allow_policies, or how to obtain a valid policy_id. The 'Get' verb implies retrieving one existing policy, but there are no exclusions or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. 'Get' implies a read-only operation with no side effects, which is clear enough for a simple fetch. However, it does not mention response shape, potential errors, or authorization expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler or redundant clauses. It is front-loaded with the verb and resource, though it is somewhat sparse in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter get-by-ID tool, the description plus schema is minimally adequate. Since there is no output schema, 'details' is vague about what will be returned, and the distinction from get_ip_prefix_bgp_status is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions, and coverage is 100%, so the baseline is 3. The tool description adds no additional meaning about how account_id and prefix_id relate to the lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and resource ('IP prefix'), and it is distinct from a listing operation. However, it does not differentiate itself from sibling tools like get_ip_prefix_bgp_status, since 'details' is left vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as list_ip_prefixes or get_ip_prefix_bgp_status. The schema implies a look-up by ID, but the description does not state a scenario, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The verb 'Get' implies a read-only, non-destructive operation, but the description does not explain what 'details' includes, how results are returned, or whether there are permission requirements. It provides basic behavioral context but not thorough transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core verb-resource pair is front-loaded. It is concise and readable, though it is also somewhat under-specified in what it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, this description combined with the schema is minimally viable. However, because there is no output schema and the description does not say what fields or structure the returned details take, an agent cannot fully predict the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning, examples, constraints, or relationship between account_id and catalog_name, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the resource ('R2 catalog'), and the singular phrasing distinguishes it from list_r2_catalogs. 'Details' is generic, but it is still clear that this is a single-catalog lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as list_r2_catalogs, nor does it mention prerequisites, filter conditions, or when not to use it. Usage must be inferred almost entirely from the tool name and input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only restates what the tool name already implies ('get details') and does not describe return format, error behavior, authorization requirements, or whether any side effects are involved. This is a common gap for read tools without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. While it is terse and could contain more context, the conciseness itself is praiseworthy; any missing substance is better addressed under contextual completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read operation with fully documented required parameters, the definition is minimally viable. However, there is no output schema and no description of what the returned preset details contain, nor any note about behavior when the preset does not exist. These are clear gaps for an agent needing to interpret the result or handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three required parameters are already documented at the schema level. The description adds no extra semantic context about what makes a preset unique or how the IDs relate to each other, but no compensation is needed given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('Realtime Kit preset details'), so the core action is identifiable. However, it does not explicitly distinguish itself from sibling tools such as list_realtime_presets or get_realtime_recording, relying mostly on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a singular, read-only operation on a specific preset, which contrasts with the sibling list_realtime_presets, but it never states when to choose this tool over alternatives. No exclusions or prerequisites are mentioned, leaving the selection heuristic implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The 'get' verb conveys that this is a read-only, non-destructive operation, which is the key safety-relevant trait. However, nothing is disclosed about what 'details' includes, error behavior when the integration does not exist, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clean sentence with no wasted words and the core operation front-loaded. It is appropriately terse for a simple retrieval tool, though it is minimal enough that it adds little beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity get-by-id tool with two well-documented parameters, the description is near-sufficient. The notable gaps are the lack of any mention of the related list_risk_scoring_integrations sibling, and the absence of an output schema means the agent gets no hint of what the returned 'details' contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so per the baseline rule the schema already documents both parameters. The description adds no parameter meaning beyond the schema, and the schema's own descriptions ('The account ID', 'The integration ID') are somewhat tautological, but the description is not required to compensate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get details of') and resource ('a risk scoring integration'), making the core operation clear. However, it does not explicitly distinguish itself from the closely related sibling list_risk_scoring_integrations; the agent must rely on the conventional get-vs-list naming pattern to tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list_risk_scoring_integrations (for enumerating integrations) and list_risk_scoring_behaviors exist, but the description names none of them and gives no exclusion criteria. Usage context is only implicit in the tool's name, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only conveys that this is a read operation ('Get') and gives example inputs; it does not describe what happens for an unknown or invalid setting_name, authorization requirements, error behavior, or the result shape. For a tool with zero annotation coverage, this is a thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler words: the verb, resource, and scoping qualifier ('by name') all appear up front. It is efficiently sized, though it earns the score for brevity rather than content density, since the same sentence could have carried sibling-routing or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter GET with 100% schema coverage, the description is minimally viable: an agent knows what to call and what arguments to pass. However, with no annotations and no output schema, the description leaves gaps around error behavior, return shape, and — given the large sibling list containing get_zone_settings — how this tool relates to the plural variant. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 — both zone_id and setting_name are already documented in the schema, including example values. The description's examples (ssl, min_tls_version, security_level) are actually a subset of the schema's own example list, so it adds no new parametric meaning beyond restating the existing examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('a specific zone setting by name'), with concrete examples (ssl, min_tls_version, security_level) that anchor what the tool operates on. The word 'specific' and the singular form implicitly differentiate it from the sibling get_zone_settings (plural), though it does not explicitly name that sibling. Clear, but stops short of explicit sibling contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by name' implies the usage case — you call this tool when you already know which setting you want — but there is no explicit when/when-not guidance or mention of alternatives like get_zone_settings (list all) or get_ssl_settings (aggregate). Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that routes are listed, with no mention of pagination, read-only semantics, response shape, error conditions, or account-level vs gateway-level behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler words, and it front-loads the core operation and resource. It is concise, though it could have added a bit more context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list operation with no output schema or annotations, the description is minimally sufficient: an agent can infer the intent and required parameters. However, it lacks details such as return format, pagination, or how the route list is scoped to the gateway, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add meaning beyond the schema; it does not explain how account_id and gateway_id relate or how to discover valid gateway IDs, but the baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('routes'), and the domain ('AI Gateway'). It clearly distinguishes from sibling tools such as list_ai_gateways (lists gateways, not routes) and get_ai_gateway_route (retrieves a single route).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_ai_gateway_route or list_ai_gateways. The description implies the basic use case but provides no preconditions, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It only states 'List jobs' and gives no details about pagination, return format, job states, authentication requirements, or read-only guarantees. Listing implies a safe read operation, but the description adds no explicit behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and its target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a generic parameter schema, the one-line description is not enough. It does not explain what an 'AI Search job' is, what information the listing returns, whether pagination or filtering is available, or any operational constraints. An agent would need to infer much of the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's generic 'The account ID' and 'The instance ID' texts, and it does not explain the relationship between the two parameters or how to identify the correct instance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('jobs for an AI Search instance'), which clearly distinguishes it from sibling tools like list_ai_search_instances, list_ai_search_items, and get_ai_search_job. Even without naming alternatives, the resource scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_ai_search_job or list_ai_search_items. There is no mention of prerequisites, scoping, or situations where another tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It conveys a read-style list operation and narrows the resource to registered brands, which is helpful. It does not mention pagination, response shape, account scoping, or permission expectations, but for a simple list tool the core behavior is at least clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant phrasing. It is appropriately sized for such a simple tool, though it sacrifices useful context by being so minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter and no output schema, the description is minimally sufficient: an agent can infer it lists registered brand-protection brands. It lacks context on what a 'brand' is, whether results are paginated, and how to choose this endpoint over the many related brand-protection list tools, so completeness is adequate but not strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is documented 100% in the input schema with 'The account ID'. The description adds no additional meaning about how account_id relates to brand registration or what values are expected, so the schema carries the weight. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('registered brands') with a domain qualifier ('for brand protection'), so the tool's basic function is understandable. However, it does not explicitly differentiate itself from closely related siblings like list_brand_protection_logos or list_brand_protection_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other brand-protection list endpoints, nor any mention of prerequisites or intended context. The agent must infer usage entirely from the name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' does imply a read-only operation and the parenthetical adds rule-category scoping, but nothing is disclosed about pagination, response shape, ordering, or whether all rules or a subset are returned. For a list endpoint with zero annotation coverage, this is a meaningful omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler: the verb 'List' and the resource appear immediately, and the parenthetical efficiently scopes the content. It earns slightly less than 5 because the brevity reads more like under-specification than deliberate compression, given the missing behavioral context captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The calling contract is trivially simple — one required, fully documented parameter — so an agent can invoke it correctly. However, with no output schema and no annotations, the complete absence of any mention of response format or pagination leaves real gaps for a list endpoint, and the description does nothing to disambiguate among the many sibling ruleset tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is documented with 'The account ID' — so the baseline of 3 applies. The tool description adds no parameter-specific meaning beyond what the schema already provides, which is acceptable but does not enhance the agent's understanding of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('Zero Trust Gateway rules'), with a parenthetical narrowing scope to DNS/HTTP/Network filtering. This helps distinguish it from sibling tools like list_gateway_locations and list_gateway_proxy_endpoints, though it does not explicitly name alternatives, and the many ruleset siblings (list_zone_rulesets, list_account_rulesets, list_firewall_rules) are only implicitly excluded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The scope phrase 'Zero Trust Gateway rules (DNS/HTTP/Network filtering)' combined with the account_id parameter implies account-scoped usage, but given roughly a dozen rule-related siblings in the list, an agent receives no direct routing help to pick this over list_zone_rulesets or list_account_rulesets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'List' implies a read-only operation, but the description does not disclose pagination behavior, response format, ordering, or account-level permissions. For a list operation with unspecified outputs, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
An eight-word sentence that is front-loaded with the action and resource. Every word earns its place, and the brevity is appropriate for a one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter), and the description states its high-level function and scope. However, with no output schema and no annotations, the response shape, pagination, and expected result format are undocumented, leaving an agent to call the tool without knowing what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — account_id is fully documented with type, maxLength, and description. The description's 'for an account' loosely aligns with the parameter, but adds no formatting, validation, or semantic detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a specific resource ('load balancer origin pools'), and a scope ('for an account'). The 'load balancer' qualifier helps distinguish origin pools from related sibling resources like list_load_balancers, list_load_balancer_monitors, and get_origin_rules, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — use it when you need origin pools for an account — but gives no explicit guidance on when to prefer it over alternatives or when not to use it. Given the large sibling set containing several load balancer list/get tools, a routing pointer would add value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states that the operation is a list (read) scoped to a zone, which is useful, but it does not disclose pagination, ordering, response shape, or rate limits, making the transparency only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is efficient, but slightly underspecified for the broader tool context, so it does not reach the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one simple parameter and no output schema, so the description only needs to cover a small surface. However, it omits pagination and return-format guidance and does not mention get_page_rule as the single-item alternative, leaving it minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because zone_id has the description 'The zone ID'. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('page rules') scoped to 'a zone', clearly identifying the core operation. It distinguishes from get_page_rule (single fetch) but does not explicitly disambiguate from other zone-scoped rule list tools like list_zone_rulesets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The sibling set includes get_page_rule, list_zone_rulesets, and many other list_* tools, but the description does not mention any exclusions or point to a better-fit sibling, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the scope ('active connections'), but it says nothing about pagination, response shape, whether results are limited, or whether the operation is read-only. For a network inspection tool this leaves important behavior unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. While terse, every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two required parameters and no output schema, so full return-value documentation is less critical. However, the description does not explain what an active connection entry contains, whether results are paginated, or how this relates to tunnel configuration and connectivity state. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents account_id and tunnel_id adequately. The description adds no parameter-level detail, but it does not need to because the schema carries the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('active connections for a Cloudflare Tunnel'). It clearly distinguishes this from sibling tools like list_tunnels or get_tunnel by targeting connections rather than tunnel objects or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of alternatives such as list_tunnels, get_tunnel, or get_tunnel_configuration. It does not mention prerequisites like needing a tunnel_id first, nor does it describe scenarios where this endpoint is or is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does signal a read-only operation via 'Get details,' but it does not describe response contents, error behavior, permissions, or any other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word earns its place, and it is immediately clear what resource is being retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter get operation, the description is minimally viable, but it lacks output schema information and fails to clarify how this tool relates to nearby siblings. An agent might be able to call it correctly, but it would benefit from more context about return values and when to choose this over related Access certificate tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both account_id and certificate_id described in the input schema. The tool description adds no additional meaning about these parameters, so it neither helps nor harms beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and resource ('Access mTLS certificate'), so it clearly identifies what the tool does. However, it does not explicitly distinguish itself from sibling tools like get_access_certificate_settings or list_access_certificates, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_access_certificates or get_access_certificate_settings. The name implies it is for a single certificate by ID, but the description provides no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. "Get details" clearly signals a read-only retrieval operation with no destructive side effects, but it does not disclose response shape, error behavior, or any access requirements beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant content. It front-loads the essential operation and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two fully documented parameters, so the description is minimally adequate. However, there is no output schema and no description of what 'details' includes, which leaves some ambiguity about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents account_id and identity_provider_id adequately. The description adds no extra parameter meaning or format details, so it stays at the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: "Get details of an Access identity provider." It is immediately distinguishable from the sibling list_access_identity_providers because 'get' implies retrieving one item, though it does not explicitly emphasize that it is for a single identity provider by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_access_identity_providers. An agent must infer from the name and sibling set that this tool fetches a single provider rather than enumerating all of them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'get details' and does not describe return structure, error behavior, auth requirements, or whether this is strictly read-only. An agent cannot infer what response shape to expect or how failures are signaled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the action and resource, which is appropriate for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema and no annotations, the description is adequate for invocation but not complete. It names the target and required parameter but omits return-value expectations and usage context, leaving the agent to infer what 'details' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id with 100% coverage, so the baseline is 3. The description adds no additional semantic value about the parameter, such as where to find the account ID, how it is validated beyond maxLength, or what happens with an invalid ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and a specific resource ('details for a specific Cloudflare account'). This differentiates it from list-style sibling tools like list_accounts, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_accounts, get_membership, or other account-related operations. The description does not mention alternatives, prerequisites, or exclusion conditions, so an agent has no direct usage routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get details,' which essentially restates the tool's name and implies a read operation, but does not describe authentication needs, response behavior, error cases, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with all parameters documented in the schema, the description is minimally adequate. However, with no output schema and no annotations, it does not cover what the 'details' response contains, and it lacks guidance on when to choose this over list_ai_gateway_routes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented. The description adds no additional meaning about the parameters, such as how route_id relates to gateway_id or what constitutes a valid route, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get details') and a specific resource ('AI Gateway route'). It implicitly distinguishes itself from sibling list_ai_gateway_routes by focusing on a single route's details rather than enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the sibling list_ai_gateway_routes. The description does not state any conditions, exclusions, or alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. 'Get details' clearly indicates a read-only retrieval operation with no mutation or side effects. However, it does not mention authentication requirements, possible error conditions, or whether the job must be in a particular state, leaving some behavioral context unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or redundant phrasing. It front-loads the core operation and is appropriately minimal for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, this is minimally sufficient: the name, verb, and schema let an agent invoke it. However, there is no output schema and the description does not explain what 'details' are returned or how job_id relates to account_id and instance_id, so the agent has limited context about the expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are documented in the schema, giving 100% schema coverage, so the baseline is 3. The description adds no parameter-level meaning beyond 'AI Search job', and the schema descriptions themselves are largely tautological ('The job ID', 'The account ID', 'The instance ID').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('an AI Search job'), so an agent can distinguish it from nearby sibling tools like list_ai_search_jobs and get_ai_search_instance. However, it does not explicitly describe that it retrieves a single job by ID, which keeps it from being a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool instead of list_ai_search_jobs or get_ai_search_instance. It does not mention prerequisites such as having the account_id, instance_id, and job_id, nor does it say to use list_ai_search_jobs first to obtain a job ID. Usage is only implied by the name and verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly signals a read operation and indicates the response grouping (per-colo), but it does not disclose date-range defaults, pagination, or whether the response includes aggregate totals. There is no contradiction with annotations because none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no filler. The key distinguishing detail ('broken down by Cloudflare colo/data center') is front-loaded and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter query, the description plus full schema is mostly adequate, but it omits guidance on when to choose this tool over sibling analytics tools and does not explain the behavior of optional date parameters. Since there is no output schema, the return shape is also left unspecified, though 'zone analytics' and 'colo' give a reasonable general expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already described ('Start date', 'End date', 'The zone ID'). The description adds only the colo grouping context and no parameter-specific details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('zone analytics'), and the distinguishing dimension ('broken down by Cloudflare colo/data center'). It is specific enough to separate this tool from generic analytics siblings like get_zone_analytics, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_zone_analytics or graphql_analytics. The description provides no context for choosing colo-level analytics over other analytics endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden, but it only restates the read intent and resource scope. It does not mention permissions, rate limits, response contents, or side effects, although 'Get' implies a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence with no filler, and the key scoping detail ('Argo Smart Routing and Tiered Caching') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single required parameter, but because there is no output schema or annotations, the description should at least sketch what settings are returned or what credentials are required. It does not, so the agent is left to infer the response shape and access prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents zone_id. The description adds no parameter-level meaning beyond that, keeping this at the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get'), resource ('Argo Smart Routing and Tiered Caching settings'), and scope ('for a zone'), making the tool's purpose unambiguous and distinct from generic siblings like get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to choose this tool over alternatives such as get_zone_settings or get_smart_shield_settings, and no exclusions or prerequisites. The only context is 'for a zone', which is implied by the required zone_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but 'Get' and 'rules' imply a read-only list operation. It does not disclose return format, pagination, or permission requirements, but for a simple account-scoped getter this is a mild rather than severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It names the resource, the layer qualifier, and the scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity and one well-documented parameter, but there is no output schema or annotation coverage. The agent is left to infer whether the response is a list, whether pagination exists, and what rule fields are included, making this adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already described as 'The account ID'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, a specific resource (Layer 4 DDoS protection rules), and an account scope. It is differentiated from the sibling get_ddos_l7_rules by the Layer 4 qualifier, though it does not explicitly contrast itself with that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus get_ddos_l7_rules or other security-rule/list tools. There are no exclusions, prerequisites, or decision criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must convey behavior. It implies a read operation through 'Get' but does not disclose permissions, response content, or whether any configuration is affected. The gap is moderate for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the verb and resource are stated immediately. Nothing extraneous competes for attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter the schema covers the input, but with no annotations and no output schema the description is only minimally complete. It names the resource but omits response shape, auth/user-level scope, and relationship to DLP profiles or datasets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already described as 'The account ID'. The description adds only the context that the settings belong to an account, so it does not significantly augment the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and a precise resource ('DLP payload logging settings') scoped to an account. This clearly identifies the operation and separates it from sibling DLP tools such as get_dlp_profile or get_dlp_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No use-case guidance or alternatives are mentioned. An agent must infer when to call this versus related getters; there are no conditions, exclusions, or scheduling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only states the return type. It does not mention authorization requirements, read-only guarantees, rate limits, or what happens when data is unavailable; the read-only nature is only implied by the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It front-loads the core purpose and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation with fully described parameters, the description is minimally adequate. However, the absence of usage guidance, output-schema, and any note on optional domain/required account_id leaves some context gaps for an agent choosing among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters completely (100% coverage), so the baseline is 3. The description adds no additional meaning beyond the schema; it only restates the domain focus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('WHOIS information for a domain'). It is immediately distinguishable from sibling intel tools like get_intel_domain, get_intel_ip, and get_intel_asn, which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the surrounding get_intel_* siblings or get_registrar_domain. The phrasing only states what it returns, leaving the agent to infer the appropriate context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral burden: 'Get' makes the read-only intent clear and implies no mutation. However, it does not mention required permissions, data scope, or edge-case behavior such as what happens when the prefix has no BGP status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence with the verb and object front-loaded. There is no filler or redundancy, and it is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter the description is mostly sufficient: the purpose and target resource are clear. Yet since there is no output schema, it would benefit from explaining what the BGP status response contains or any conditions that make a prefix ineligible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline for parameter semantics is 3. The description adds slight context by tying prefix_id to an IP prefix, but it does not explain the relationship between account_id and prefix_id or how to obtain valid IDs beyond the thin schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource—'Get BGP status for an IP prefix'—so an agent can tell this is a read operation on BGP status. It is clear but does not explicitly contrast with sibling tools like get_ip_prefix or list_ip_prefixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over get_ip_prefix or list_ip_prefixes, and no mention of prerequisites or exclusions. The only cue is the implied resource name, which is not enough to guide alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden, but it only restates the operation implied by the tool name. It does not explicitly disclose that this is a read-only operation, what details are returned, or how errors like a missing tunnel are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler words. It is front-loaded and easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the schema and description are enough to invoke the tool. However, without an output schema or additional behavioral context, the exact nature of the returned 'details' is left undefined, and there is no pointer to the corresponding list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both required parameters with descriptions, so the description does not need to add parameter-level detail. Baseline score is appropriate because the description itself provides no extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and a specific resource ('Magic Transit IPsec tunnel'), making the tool's purpose immediately clear. The word 'specific' distinguishes it from the sibling list_magic_transit_ipsec_tunnels, and 'IPsec' distinguishes it from the GRE tunnel getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over related alternatives such as list_magic_transit_ipsec_tunnels or get_magic_transit_gre_tunnel. It also does not mention prerequisites like obtaining a tunnel_id beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. 'Get details' clearly signals a read-only retrieval with no side effects, which is the core behavioral trait. However, it does not mention response shape, error behavior, permissions, or anything beyond the most basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler or redundancy. The core action and resource are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required IDs and no nested objects or output schema. The schema covers parameters, but the description leaves the return value vague ('details') and gives no sense of what information the response contains or how this tool relates to list_page_rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both zone_id and pagerule_id have descriptions in the schema. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get' with the resource 'page rule' and the qualifier 'specific', clearly indicating this fetches one identified object rather than a list. It distinguishes itself from list_page_rules, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like list_page_rules. The phrase 'specific page rule' implies an existing ID is required, but no explicit when-to-use, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It transparently indicates a read operation by saying 'Get details,' but it does not disclose access requirements, error behavior, or what 'details' encompasses, which would add useful context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word adds meaning, and the core action and resource are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is minimally adequate, but with no output schema or annotations it does not specify the returned shape, permission requirements, or relationship to list_permission_groups. The agent can invoke it correctly from the schema, but richer context would improve selection confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents account_id and group_id. The description does not add further parameter-level detail beyond naming the resource type, which meets only the baseline expected from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (get details) and a specific resource (IAM permission group), making the tool's purpose clear. It differentiates reasonably from sibling list tools like list_permission_groups by implying a single-group lookup, and from get_resource_group by naming IAM permission group specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose this tool over alternatives such as list_permission_groups or get_resource_group. Usage context is only weakly implied by the word 'get' and the singular 'a permission group'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the operation. It does not mention whether this is read-only, what the response contains, whether any permissions are required, or how errors behave. 'Get' implies non-mutation, but no meaningful behavioral context is added beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant elaboration. It front-loads the action and object immediately, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 plus schema is minimally adequate: the required parameters are all documented. However, there is no output schema and no annotation support, and the description does not describe what 'details' include or how to obtain the recording_id, so the agent is left with a vaguer representation of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings are already fully documented in the input schema. The description adds no additional semantic detail about how the parameters relate or any constraints beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a clear resource ('Realtime Kit recording details'), so the core purpose is evident. It does not explicitly differentiate from siblings like list_realtime_recordings or get_realtime_session, but the singular 'details' strongly implies a single-record fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the get-vs-list naming pattern: this tool is for retrieving details about one specific recording once the recording_id is known, while list_realtime_recordings is for enumeration. However, the description provides no explicit when-to-use or alternative guidance, leaving the agent to infer the correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that this is a read operation via 'Get', but adds no detail about required zone type, error behavior, authentication needs, or whether any state is affected. The description essentially restates the tool name without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant explanation. It is appropriately sized for a one-parameter getter and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter with full schema coverage and no nested objects, so basic invocation is possible. However, there is no output schema and the description never explains what the returned configuration contains or how it relates to other secondary DNS tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter zone_id, including a plain description and maxLength, so the description does not need to add parameter details. The description itself does not reference the parameter, but this is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('secondary DNS outgoing zone transfer configuration'), making the operation and target unambiguous. The 'outgoing' qualifier also distinguishes it from closely related sibling tools like get_secondary_dns_incoming and get_secondary_dns_primary without requiring the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no prerequisites, and no mention of conditions under which this configuration would apply. The sibling list contains several other secondary DNS tools, but the description does not help an agent choose among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. The verb "Get" reasonably conveys a read-only operation, but the description does not disclose the shape of the progress data, polling behavior, or any side effects. It is not misleading, just minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. Every word contributes to identifying what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the description plus schema is minimally sufficient to identify and invoke the tool. However, with no output schema and no annotations, it leaves unspecified what the progress response actually contains and how this differs from get_slurper_job, which is a real but not severe gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both required parameter descriptions are present, so the baseline is 3. The description adds no extra meaning to the parameters beyond connecting them to a migration job, but no schema gap exists to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies a specific operation ("Get progress") on a specific resource ("migration job"). The word 'progress' distinguishes it from siblings like get_slurper_job and list_slurper_jobs, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of get_slurper_job or list_slurper_jobs, and no prerequisites or discovery steps are mentioned. The intended usage is only implied by the tool name and the generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' reasonably signals a harmless read operation, and 'settings' suggests the return content. However, it does not disclose response shape, permission requirements, or whether all settings or only a subset are returned. This is adequate for a simple getter but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word earns its place, stating the operation, resource, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-paramer getter with a fully documented schema, the description is minimally complete. The absence of an output schema and annotations is partially mitigated by the simple, safe read-only nature, but the description does not define what 'Smart Shield settings' includes or whether any zone is eligible, leaving some contextual ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and zone_id is already described as 'The zone ID', so the parameter semantics are fully handled by the schema. The description only reinforces the zone scope without adding new parameter meaning, which meets the baseline for full schema-only coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('Smart Shield settings'), and the scope ('for a zone'). It is not a tautology because it adds the zone-scoping detail, and it is recognizable among many settings-getter siblings. However, it does not explicitly distinguish Smart Shield from related tools like get_page_shield_settings or get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and there are many similar settings getters among the siblings. It implies the obvious context—retrieve Smart Shield settings for a zone—but provides no exclusions, prerequisites, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' only signals read-only retrieval and gives no information about response shape, error behavior, permissions, or scoping. This is thin for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core resource and specificity are front-loaded. It is appropriately sized for a simple one-resource getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Required parameters are fully documented and there are no nested objects, so the basic invocation context is clear. However, with no output schema and a minimal description, an agent cannot anticipate return contents or failure modes, leaving the definition usable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters ('The zone ID' and 'The waiting room ID') with 100% coverage, so the description adds no parameter-level meaning. The schema does the necessary work here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('waiting room'), and 'specific' distinguishes this from list-style siblings like list_waiting_rooms. However, it largely restates the tool name and does not name the sibling it should be contrasted with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies this tool is for retrieving one waiting room rather than listing all of them, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer alternatives from sibling names like list_waiting_rooms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of disclosing behavior. It only says 'List', which implies a read-only operation, but it does not describe response shape, pagination, permissions, ordering, or whether the reports are summarized or full. This is minimal transparency for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no wasted words. The operation and scope are front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema list tool, the basic invocation is fully understandable: supply account_id and get a list of abuse reports. However, it lacks behavioral detail such as pagination or return shape, and it does not mention get_abuse_report as the way to retrieve a single report, so it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents account_id with 100% coverage, so the description does not need to explain it. The description adds no additional meaning about the account_id format or where it comes from, but the baseline of 3 applies because the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), resource ('abuse reports'), and scope ('for an account'), making the core purpose clear. It is distinguishable from the sibling get_abuse_report by the plural resource and list verb, though it does not explicitly call out the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an account' provides useful scope context, indicating this is an account-level collection operation rather than a zone-level or single-item read. However, it gives no explicit guidance about when to use this instead of get_abuse_report, and no mention of filtering, pagination, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does convey that this is a read-only listing operation scoped to an account, which is useful. However, it does not mention pagination, return shape, ordering, or any other behavioral characteristics, leaving some ambiguity for a list endpoint with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation, resource, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is structurally simple with one required parameter and no output schema, so a short description is acceptable. However, the ambiguity with the nearly identical sibling list_account_mtls_certificates and the lack of any return or pagination detail make it only minimally complete for an agent selecting among many similar list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes account_id as 'The account ID' with 100% coverage. The description's phrase 'for an account' lightly reinforces the account-level scope but adds no meaningful detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), resource ('Access mTLS certificates'), and scope ('for an account'). It is clear about the basic operation but does not distinguish itself from the very similar sibling 'list_account_mtls_certificates', so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as list_account_mtls_certificates, list_custom_certificates, or list_client_certificates. The name and description imply the use case, but the confusing sibling overlap makes the lack of explicit routing a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The word 'List' signals a non-mutating read and 'for an AI Gateway' signals scoping, but the description provides no detail about pagination, result limits, response shape, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six words long, front-loads the operation, and contains no filler or redundant explanation. It is concise without sacrificing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-string-parameter list operation, the description plus schema is minimally adequate. However, there is no output schema and the description does not explain what an AI Gateway dataset is, what the returned list contains, or how the result is structured, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both account_id and gateway_id are already defined in the input schema. The description adds no parameter-level meaning, so the baseline schema coverage is sufficient and no penalty beyond that is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List) and a clear resource (datasets for an AI Gateway), so an agent can tell this is a collection-returning operation. It does not explicitly contrast itself with get_ai_gateway_dataset or list_ai_gateway_routes, so it lacks strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as get_ai_gateway_dataset, list_ai_gateway_evaluations, or list_ai_gateway_routes. There are no prerequisites, exclusions, or conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of disclosing behavior. It only states the listing operation and account scope, without mentioning pagination, response shape, ordering, rate limits, or other runtime behavior an agent may need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states verb, resource, and scope in ten words, which is appropriately concise for a one-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and the parameter is fully documented, so an agent can likely invoke it with account_id. However, there is no output schema and the description does not mention pagination or result structure, leaving an important gap for an agent that needs to consume the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single account_id parameter is already described as 'The account ID'. The description's phrase 'in an account' echoes that schema meaning without adding new parameter details, so it neither improves nor harms parameter clarity beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('AI Gateway instances') with account scope, making the operation immediately clear. It also distinguishes itself from sibling tools such as list_ai_gateway_routes, list_ai_gateway_datasets, and get_ai_gateway_logs by targeting gateway instances specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_ai_gateway_routes or get_ai_gateway_logs. The description gives no exclusions, preconditions, or comparisons to sibling tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the only source of behavioral context. 'List' conveys a read-only operation and 'available' suggests a catalog lookup, but the description does not mention result shape, pagination, or whether results are account-scoped. This is adequate but leaves clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with no filler. The verb and object are front-loaded, making the purpose immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, this is close to sufficient, but the absence of an output schema and any detail about what information is returned for each model leaves an agent guessing about the response. It is adequate for selection but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because account_id already has a description in the input schema. The tool description adds no further parameter semantics, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('available Workers AI models'), so an agent can identify the tool's domain. It does not explicitly contrast it with related siblings such as list_workers or list_ai_gateways, so it stops short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over related alternatives like list_workers, list_worker_services, or list_ai_gateways. There are no exclusions, prerequisites, or contextual hints beyond the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. 'List' implies a read-only collection, but the description does not mention pagination, response shape, ordering, or any auth/rate-limit behavior. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that leads with the action and resource, with no filler or repetition. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter zone-scoped list, the description is mostly adequate, but with no output schema or annotations it should say whether results are paginated and what an 'operation/endpoint' actually represents. The potential ambiguity between API Shield and API Gateway siblings is also unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so zone_id is already fully documented in the input schema. The description's 'for a zone' merely echoes the parameter; it adds no new semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('API Shield operations/endpoints') with an explicit zone scope. This is enough to distinguish it from nearby siblings such as list_api_shield_schemas and get_api_shield_config, which target different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. With many sibling list tools such as list_api_gateway_operations, list_api_shield_schemas, and list_api_gateway_schemas, an agent gets no exclusion or 'use instead' signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden; 'List' itself signals a read-only retrieval with no side effects. However, it does not disclose pagination behavior, response shape, or any product-specific nuance, so it only partially meets that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence contains the verb, resource, and scope with zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description plus schema is sufficient to construct a correct invocation with zone_id. It is less complete in helping an agent disambiguate from other schema list endpoints or anticipate the return format, especially since there is no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and zone_id is already fully described by the input schema. The description's 'for a zone' restates the same scope without adding semantics such as formats, constraints, or related filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('API Shield schemas'), and a scope ('for a zone'), so the core operation is unambiguous. It does not, however, differentiate this from similarly named siblings such as list_api_schemas or list_api_gateway_schemas, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over the many nearby schema-listing tools, nor any exclusions or prerequisite context. The only implicit hint is that the operation is scoped to a zone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a read-only operation, which is useful, but it discloses nothing about pagination, result limits, filtering, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds scope: 'devices', 'enrolled', and 'Zero Trust/WARP' all clarify the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-parameter list call, but minimal. Without usage guidance, pagination details, or return format, it leaves an agent to infer several operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (account_id is described), so the schema already handles parameter documentation. The tool description adds no parameter-level meaning, which matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List devices enrolled in Zero Trust/WARP'. It is clear and distinguishable from related siblings like list_device_posture_rules or list_device_policies, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives, nor any exclusions. The usage context is only implied by the generic 'List devices...' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'List' implies a read operation, but the description does not disclose pagination behavior, response shape, filtering, ordering, or any other behavioral trait that could affect correct invocation and interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description is minimally adequate, but with no annotations and no output schema it leaves pagination, response format, and edge-case behavior implied rather than explicit. The agent can make the call but must rely on API conventions for the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and zone_id is already documented as 'The zone ID'. The description adds no parameter-level detail beyond echoing the zone scope, so the schema remains the primary source of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('load balancers'), and a clear scope ('for a zone'). It is immediately distinguishable from closely related siblings such as list_load_balancer_monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives, no exclusions, and no mention of related list endpoints. The agent is given no decision-making context beyond the obvious resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that this is a list/read operation, but it does not mention pagination, response shape, ordering, or any other behavioral traits an agent would need to know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully documented parameter, so the description is minimally viable. However, there is no output schema and no mention of pagination or response format, which leaves a gap for a list-operation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single required account_id parameter with 100% coverage. The description's phrase 'for an account' aligns with that parameter but adds no extra semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List Magic Transit IPsec tunnels for an account.' This clearly distinguishes it from sibling tools like get_magic_transit_ipsec_tunnel (singular fetch) and list_magic_transit_gre_tunnels (different tunnel type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_magic_transit_ipsec_tunnel for a single tunnel or list_magic_transit_gre_tunnels for GRE tunnels. The verb 'List' implies collection retrieval, but the description does not explicitly mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only says 'List', which implies a read operation, but does not disclose pagination behavior, response shape, rate limits, or whether the account must have Magic WAN enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word earns its place: the verb, resource, and scoping are all present in a compact, readable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description correctly identifies the action and scope. However, it omits useful context such as return value expectations, pagination, or the relationship to get_magic_transit_site, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already documented as 'The account ID'. The description's phrase 'for an account' aligns with the schema but adds no new parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a distinct resource ('Magic WAN sites'), and a scope ('for an account'). This clearly differentiates it from sibling tools like list_magic_transit_routes and get_magic_transit_site by resource and collection-vs-single semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives. It does not mention get_magic_transit_site for retrieving a single site, or list_magic_transit_routes for routes, leaving the agent to infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It only states 'List', which implies a read-only operation, but it does not mention pagination, ordering, filtering, response format, or any other behavioral traits an agent would need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the core operation and resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description plus schema covers the essentials: what the tool does and the required parameters. However, with no output schema and no annotations, an agent still lacks information about pagination or the shape of the returned deployments list, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions already document account_id and project_name. The tool description adds no additional parameter semantics, but the schema is sufficient, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('deployments for a Pages project'), making the tool's function immediately clear. It also distinguishes this tool from similar siblings like list_worker_deployments and list_pages_projects by tying it explicitly to Pages projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives only the basic action and resource. It provides no guidance on when to choose this tool over alternatives, such as list_worker_deployments or get_pages_project, and no exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys a read-only listing operation scoped to Page Shield detections, which is useful. However, with no annotations provided, it does not disclose other behavioral traits such as pagination, result limits, or whether Page Shield must be enabled for the zone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It says exactly what the tool does and nothing more, which is ideal for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list call with 100% schema coverage, the description is minimally sufficient. However, the absence of any usage guidance or behavioral context, and no output schema, leaves the agent to infer some details that a more complete description could provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter, zone_id, with a clear description. The tool description adds no additional parameter semantics, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List') and the resource ('connections detected by Page Shield'). It differentiates from sibling tools like list_page_shield_scripts and list_page_shield_policies by naming a distinct resource type, though it does not explicitly compare itself to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites apply, or how it differs from alternatives. Given the large sibling list, an agent is left to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It conveys a read-only scoping operation ('List ... for an account'), but does not disclose pagination, response shape, permission requirements, or whether the output includes all groups or only those directly assigned. This is adequate for a simple list operation but not richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words; the verb, resource, and scope are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one required parameter, and the schema fully documents it. However, there is no output schema and the description does not describe return values or pagination, which would be needed for an agent to fully interpret results. For a simple list with one well-documented parameter, the description is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for account_id is complete ('The account ID') and coverage is 100%, so the baseline is 3. The tool description adds no parameter meaning beyond reaffirming 'for an account,' which mirrors the schema rather than adding new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List'), a specific resource ('IAM permission groups'), and a scope ('for an account'). It differentiates from siblings like get_permission_group (singular) and list_token_permission_groups (token-specific) by using 'IAM' and 'list', though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_permission_group, list_token_permission_groups, or list_account_roles. The description does not state when this tool is appropriate or when a sibling should be preferred, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing about pagination, result limits, ordering, or whether summary or full pipeline details are returned. 'List' implies a non-destructive read, but that is inferred from the verb rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, with zero waste. Every word serves a purpose: 'List' (operation), 'R2 pipelines' (resource), 'for an account' (scope). Appropriate size for a one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required param, no nested objects), and the description covers what it does and the scope. However, there is no output schema and the description does not hint at the return shape, pagination behavior, or whether the response is a plain array or a wrapped object, leaving a meaningful gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the account_id parameter is already documented as 'The account ID.' The phrase 'for an account' mildly reinforces the parameter's meaning but adds nothing beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('R2 pipelines'), and a specific scope ('for an account'). An agent can unambiguously distinguish this from the sibling get_r2_pipeline (singular retrieval vs plural listing) and list_r2_buckets (different R2 resource) without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of get_r2_pipeline for single-pipeline lookup, no exclusions, and no context about scenarios where listing all pipelines is appropriate. The only hint is 'for an account,' which ties to the required parameter but does not help an agent choose between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' transparently signals a read-only enumeration, but the description adds nothing beyond that: no mention of pagination, response shape, ordering, or what an ACL consists of. Adequate for a simple read operation, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Eight words with no filler, front-loaded with verb and resource. Every word earns its place, and for a single-parameter list tool this length is appropriate rather than under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one well-documented parameter, the description is near minimum viable: an agent can infer it should pass account_id and receive a list of ACLs. But with no output schema and no annotations, the description still leaves pagination behavior, the shape of returned ACL objects, and the choice between list and get variants unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single account_id parameter is already documented in the schema, and the baseline of 3 applies. The phrase 'for an account' mildly reinforces that account_id identifies the owning account, but the description adds no syntax, format, or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('secondary DNS ACLs') with account scoping, so an agent can tell it apart from same-prefix siblings like list_secondary_dns_peers and list_secondary_dns_tsigs by resource name alone. However, it never explicitly contrasts itself with the singular get_secondary_dns_acl or other list variants, so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't say 'use this to enumerate all ACLs while get_secondary_dns_acl fetches one', mention account-level prerequisites, or note any exclusions. The only context, 'for an account', is scope rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the action and resource without mentioning pagination, response shape, permissions, or whether this returns all peers across the account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the action and resource are front-loaded. It earns its place, even though it is otherwise minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with no output schema, the description is barely adequate. It does not state what is returned, whether pagination applies, or how account_id is used beyond the schema, so it leans heavily on the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents account_id with 100% coverage, so the description adds little beyond saying 'for an account'. The single parameter is fully described in the input schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'secondary DNS peers', and scopes it to an account. It does not explicitly differentiate from the sibling get_secondary_dns_peer, but the plural 'List' versus 'get' makes the intended operation reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: enumerate all secondary DNS peers for a given account. However, there is no explicit guidance about when to choose this over related tools like get_secondary_dns_peer or list_secondary_dns_tsigs, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and scope, without mentioning pagination, result ordering, permissions, or what the response contains beyond what 'List' implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action, resource, and scope with no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity — one required parameter and no output schema — the description is mostly adequate for invoking the tool. However, it lacks any detail on pagination, limits, or return shape, which leaves a minor but real gap for a list-type operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is already fully documented in the schema as 'The account ID', and the description's 'for an account' aligns with it. With 100% schema description coverage, the description adds no new semantic detail, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('secrets stores') with an account scope, clearly stating the core operation. It is distinguishable from siblings like get_secrets_store and list_secrets_store_secrets by naming the plural resource, though it does not explicitly call out those differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an account' implies account-level scoping, and the sibling list includes alternatives such as get_secrets_store and list_secrets_store_secrets, so an agent can infer when to use this tool. However, the description provides no explicit when-to-use or when-not-to-use guidance and does not mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not state whether results are paginated, how they are sorted, or whether the returned regions are scoped to the provided zone_id. No side effects are mentioned, but the absence of output details leaves an agent under-informed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant words. It names the action and the resource immediately and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description plus schema is minimally sufficient for an agent to invoke the tool. However, with no output schema, the description does not clarify the shape or semantics of the returned regions (e.g., IDs vs. display names), leaving some ambiguity about how to consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, zone_id, is already documented as 'The zone ID.' The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List available regions for speed tests.' It clearly communicates the tool's purpose and is distinguishable from siblings like list_speed_tests, which list tests rather than regions. It could be slightly stronger by explicitly naming the sibling it is not, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: the tool should be used when the caller needs the set of regions that can be targeted by speed tests. There is no direct comparison to list_speed_tests or get_speed_schedule, so an agent must infer when this tool is preferable to those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. 'List' clearly signals a read-only operation and 'in an account' establishes scope, but the description does not mention response shape, pagination, or authentication requirements. For a simple account-level list tool, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, six-word sentence with no filler. It front-loads the action and resource, and is appropriately sized for a tool with one required parameter and a fully documented input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple account-scoped list operation with one required parameter, the description is minimally sufficient. However, there is no output schema, no mention of return shape or pagination, and the large sibling list contains similar resources like list_worker_services, so the guidance is adequate but leaves real gaps for an agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter account_id is already fully described as 'The account ID'. The description's 'in an account' weakly reinforces the parameter's purpose but does not add meaningful semantic information beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names the exact resource ('Worker scripts') scoped to an account. It is clearly distinguishable from siblings like get_worker_script or list_worker_routes by the resource type, though it does not explicitly call out those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to prefer this tool over list_worker_services, list_worker_routes, or get_worker_script. The description only states what the tool does; it does not mention alternatives, exclusions, prerequisites, pagination, or filtering behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes what is listed, not whether the operation is safe/read-only, whether pagination applies, whether auth scopes are needed, or what the response shape looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then uses a parenthetical to clarify the scope without bloating the description. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the core purpose is clear, but there are gaps: no output schema, no mention of pagination or response format, and no distinction from the closely related list_account_rulesets. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter, zone_id, with a description and maxLength. The tool description adds no extra meaning about how zone_id is used or formatted, so the baseline of 3 applies given 100% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('all rulesets for a zone'), and gives examples of what counts as a ruleset (WAF, rate limiting, transform rules). This scope clearly distinguishes it from account-level siblings like list_account_rulesets and single-resource tools like get_ruleset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives or when not to use it. It does not mention list_account_rulesets for account-level needs or get_ruleset for retrieving a single ruleset, leaving the agent to infer usage solely from the name and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It conveys that this is a read/get operation and that the result is a UUID, which is meaningful, but it does not mention response shape, error cases, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description gives the essential information: the input is a zone and the output is a DCV delegation UUID. It is adequate for a simple lookup, though it could mention the response envelope or what DCV delegation means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter with 100% coverage, so the baseline applies. The description's 'for a zone' adds no meaning beyond the schema's zone_id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a specific resource ('DCV delegation UUID') and a scope ('for a zone'). It is clear and not tautological, though it does not explicitly distinguish itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives or when it should not be used. The phrase 'for a zone' only scopes the input, not the decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. 'Get' implies a read operation with no destructive side effects, which is accurate, but the description does not disclose what 'details' are returned, possible error behavior, or idempotency. It is minimally adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and is easy to scan. It loses one point because the brevity is somewhat boilerplate ('get details') rather than adding structuring detail that would make the description more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity, the schema fully documents both required parameters, and the get semantics are clear enough to make a correct call. However, there is no output schema, no annotations, no description of what the returned details contain, and no relationship to sibling tools like list_dlp_datasets, leaving meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id and dataset_id already described in the input schema. The tool description adds no parameter-specific meaning beyond implying the dataset is selected by ID, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get') and resource ('specific DLP dataset'). The word 'specific' signals a single-item fetch rather than the listing behavior of sibling list_dlp_datasets, and 'DLP dataset' distinguishes it from other resource getters in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus list_dlp_datasets or get_dlp_profile, nor any precondition such as needing a known dataset_id. The word 'specific' is only an implicit hint, not explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'Get' clearly signals a read-only operation, and the description adds what the response will contain (encryption mode and TLS version). It does not mention authentication requirements, potential errors, or whether the settings are returned in a specific nested structure, but for a simple fetch tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It front-loads the action and resource, then specifies the key contained settings, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description is reasonably complete. It names the resource and key returned fields. It would be slightly stronger with explicit mention of the response shape or a note that this complements other SSL-related endpoints, but these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a description for zone_id ('The zone ID'), so the baseline of 3 applies. The description adds no additional parameter-level detail beyond the schema, but none is needed for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('SSL/TLS settings for a zone'), and names concrete included content ('encryption mode and TLS version'). It is clear about what the tool does, though it does not explicitly differentiate from closely related siblings like get_ssl_verification or get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_universal_ssl_settings or get_zone_settings. Usage context is only implied by the tool name and the generic 'for a zone' phrasing, so an agent must infer when this specific settings getter is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Get' strongly implies a read-only, non-mutating operation, which provides basic transparency. However, it does not mention authentication requirements, response format, or any side-effect-free guarantee explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource. Every word earns its place, and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only getter with no output schema and no annotations. The description provides enough information for an agent to identify the correct operation and supply the required zone_id. It is slightly incomplete in not indicating what the returned settings contain, but that is a minor gap for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the zone_id parameter is already described as 'The zone ID'. The description adds no meaningful semantic detail beyond restating that the settings belong to a zone, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('URL normalization settings') scoped to a zone. It is unambiguous and distinct from sibling tools in practice, though it does not explicitly call out why it differs from related settings getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_zone_settings, get_cache_settings, or get_ssl_settings. The description merely restates the tool's function without offering decision criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey the read-only nature and scope, and 'List all roles' does imply a non-destructive enumeration. However, it doesn't mention pagination, whether built-in and custom roles are both included, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to defining the operation's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list operation, the description and schema together are sufficient to call the tool: the action is clear and the required account_id is documented. It doesn't describe the response shape, but no output schema exists and the operation is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter account_id is already described as 'The account ID'. The description reinforces that the roles belong to a Cloudflare account but adds no new parameter-level information, which matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('roles'), and scopes it to a Cloudflare account. It clearly states what the tool does, though it doesn't explicitly contrast it with sibling list tools such as list_permission_groups or list_account_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—retrieving account roles—but provides no guidance on when to prefer this tool over similar account-level list tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'List' implies a read-only operation, and 'alert types that can be configured' indicates the return content. However, it does not mention response shape, pagination, or any side effects, though for this simple enumeration tool the gap is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is reasonably complete: it states what will be returned and the schema documents the required account scoping. It would be slightly stronger if it described the response format, but no output schema exists and the added value would be marginal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single account_id parameter with 100% coverage, so the baseline is 3. The description adds no additional meaning about how account_id affects which alert types are returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: list available alert types that can be configured. It clarifies that the tool returns alert type definitions rather than alert instances, which distinguishes it from many sibling tools. However, it does not explicitly name or contrast itself with related notification/alert tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_notification_policies or list_brand_protection_alerts. There are no exclusions, prerequisites, or context about where this tool fits in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it only says 'List', which implies a read operation but does not disclose whether the response contains sensitive TURN credentials, whether results are paginated, or any permission requirements. For a tool returning credentials, this lack of context is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler and front-loads the verb and resource. It is appropriately concise for a simple one-parameter list tool, though it could be more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-required-parameter, no nested objects, no output schema tool, the description provides the essential action and scope, making a correct call plausible. However, the lack of any note about return shape, pagination, or the distinction from get_calls_turn_key leaves the description just barely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id with 100% coverage, so the description adds no parameter-level meaning. The description correctly implies the account scope by mentioning Cloudflare Calls, but this is not enough to raise above the schema-covered baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb (List), resource (TURN keys), and product scope (Cloudflare Calls), which distinguishes it from sibling tools like get_calls_turn_key (single-key get) and list_calls_apps (Calls apps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' implies this tool is for fetching the full collection of TURN keys rather than a single key, but it never explicitly says when to prefer it over get_calls_turn_key or how to handle an account with many keys. No alternatives or exclusions are named, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation and the firewall-rule context gives domain meaning, but the description does not disclose pagination, return contents, or any other operational behavior. This is a notable but not severe gap for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It communicates the verb, object, and scope efficiently in six words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the schema and description together are largely sufficient to invoke the tool correctly. The absence of pagination or return-shape details is a minor gap, but the low complexity and clear resource scope keep the description usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, zone_id, with 100% coverage. The description adds nothing about the parameter's format, possible values, or how it affects the result, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'List' and resource 'filters' clearly, with context that they are used by firewall rules. It is distinguishable from sibling tools like list_firewall_rules in wording, though it does not explicitly contrast itself against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus closely related siblings such as list_firewall_rules or list_zone_rulesets. The firewall-rule context hints at the relationship but does not state which tool to prefer or when to avoid this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the listing action. It does not mention pagination, the shape of the returned data, read-only safety, or any account-level prerequisites beyond the required parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It front-loads the action and resource and keeps the BYOIP clarification minimal and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one fully documented parameter, the description is mostly sufficient for an agent to invoke the tool. The only minor gap is that it does not explicitly state the output format or pagination behavior, but these are relatively predictable for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single account_id parameter is already documented as 'The account ID'. The description adds nothing beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('IP prefixes'), and clarifies scope ('for an account') plus the BYOIP context. It clearly separates this from sibling tools like get_ip_prefix (singular) and list_ip_prefix_delegations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related siblings such as get_ip_prefix or list_ip_prefix_delegations. The intended context is only implied by the name and the single scope qualifier, with no explicit when/when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. 'List' clearly signals a read-only operation, but the description does not disclose pagination behavior, account-scope details beyond the schema, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter and no output schema, the description is mostly sufficient for an agent to select and invoke the tool. Minor gaps remain around pagination and the relationship to get_mnm_rule and get_mnm_config.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already documented in the schema. The tool description adds no additional meaning or context about how account_id is used beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List Magic Network Monitoring rules.' This clearly identifies the operation and distinguishes it from the singular get_mnm_rule and related config tools, though it does not explicitly call out sibling differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as get_mnm_rule or get_mnm_config. The description only states the action and resource, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly signals a read-only 'List' operation and identifies what is returned, but it does not disclose pagination, ordering, scope behavior beyond the account_id parameter, or error characteristics. This is adequate for a simple list tool but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. The verb and resource are front-loaded, making it easy to scan. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with no output schema, the description is largely complete: it says what action is performed and what resource is returned. It stops short of explaining response shape or pagination behavior, but the tool's simplicity and the schema's full account_id documentation make this a minor gap rather than a critical one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: account_id is documented with type and maxLength. The description adds no new parameter-level meaning, so the schema does the heavy lifting and the description receives the baseline score. It does not repeat the parameter, which is fine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('configured notification webhook destinations'), so an agent can tell what the tool returns. It does not explicitly distinguish itself from notification siblings like list_notification_policies or list_notification_history, but the resource is named precisely enough that the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many sibling notification tools. The description only says what it lists, not why an agent should choose it over list_notification_policies, list_notification_history, or list_available_alerts. Usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must signal behavior itself; the 'Get' verb conveys read-only operation, and 'for an account' scopes the resource. It does not mention auth requirements, error conditions, or what the settings block contains, but for a simple settings getter this is an acceptable minimal baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler, front-loading the verb and resource. It earns its place by fully stating the operation and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter and no output schema, the description conveys the essential call shape, but it doesn't describe the response or what is included in 'Access organization settings.' It's enough for a basic getter but leaves the agent to infer return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents account_id with 100% coverage, and the description's 'for an account' only restates the role of that parameter. No additional format, source, or validation details are given, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), resource ('Access organization settings') and scope ('for an account'), so an agent can tell what the tool returns. It doesn't explicitly differentiate it from sibling getters like get_account, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when account-level Access organization settings are needed, but it gives no explicit guidance on when not to use it or which sibling getter to prefer. For a single-purpose getter this is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' signals read-only behavior, and there is no indication of side effects. Since no annotations are provided, the description carries the full burden, but it does not disclose authentication requirements, error behavior, or what happens when the key is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repeated information. Every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the description and schema are mostly sufficient. However, there is no output schema and no detail about the response shape, and the relationship to list_calls_turn_keys is left implicit, so an agent must infer some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (account_id and key_id) with clear descriptions. The tool description adds no additional parameter semantics beyond implicitly indicating that a specific key is being retrieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('a specific TURN key'), clearly indicating a point lookup. It does not explicitly name the sibling list_calls_turn_keys, but the word 'specific' helps distinguish it from a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool should be used when a particular TURN key ID is known and its details are needed, rather than listing all TURN keys. However, there is no explicit when-to-use or when-not-to-use guidance, and the alternative list_calls_turn_keys is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' clearly signals a read-only operation, but the description does not describe behavior for missing or invalid IDs, authentication scoping, or the structure of the returned details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, repetition, or extraneous detail. It names the action, resource, and scope efficiently in eight words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with two clearly required parameters and no nested objects, so the core invocation is understandable. However, with no output schema and no annotations, the description is too terse to fully specify what 'details' are returned or how this get tool differs behaviorally from adjacent analytical get tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so account_id and cluster_id are already documented in the input schema. The description adds no parameter-level meaning beyond identifying the resource, so it stays at the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and identifies the resource ('details of a specific DNS Firewall cluster'). The word 'specific' helps distinguish it from sibling list_dns_firewall_clusters, though 'details' remains generic rather than naming what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies this is the single-cluster lookup companion to list_dns_firewall_clusters, so an agent can reasonably infer when to choose it. However, it does not explicitly state when to prefer it over related read tools like get_dns_firewall_analytics, nor does it name any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are present, the description carries the full burden of disclosing behavior. The verb 'Get' conveys that this is a read-only operation, but the description does not disclose the return shape, behavior when no notification configuration exists, or authentication requirements. It is minimally adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence. There is no filler, repeated information, or ambiguity, and every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the description plus schema is mostly sufficient for an agent to invoke it. However, there is no output schema and the description does not hint at the response structure or the empty-configuration case, so some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both account_id and bucket_name with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the precise resource, 'R2 bucket event notification configuration'. This makes the operation and target unambiguous and differentiates it from sibling tools such as list_r2_buckets and get_r2_share.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other R2-related tools, no required context, and no indication of prerequisites or typical scenarios. An agent must infer applicability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' communicates a read-only retrieval and 'details' implies the return content, but response shape, error behavior, rate limits, and account/pipeline prerequisites are not disclosed. For a simple getter this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused phrase that front-loads the verb and resource. There is no filler, no repetition of the parameter names, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with full schema coverage and no output schema, the description is mostly adequate. However, it leaves unspecified what 'details' actually contains and does not contrast with list_r2_pipelines, so an agent may still be unsure what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description names the resource but does not explain how account_id and pipeline_name are used, what uniquely identifies a pipeline, or any format constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pair ('Get details of an R2 pipeline') and identifies the singular resource, which differentiates it from list_r2_pipelines and other list-style tools. However, it does not specify which details are returned or disambiguate from related get_* R2 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular 'get' and 'details' imply this is for retrieving one pipeline's details rather than enlisting pipelines, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention the sibling list_r2_pipelines or prerequisites like an existing pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. 'Get' indicates a read-only operation, but the description does not mention what is returned, whether pagination is involved, or how missing/empty rules are handled. It is adequate for a simple getter but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It front-loads the action and clearly names the resource and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one well-documented parameter and no output schema, so the minimal description is mostly sufficient. However, it lacks any indication of the return shape or usage context, and there is no guidance to steer an agent away from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter zone_id is fully documented in the input schema with a clear description ('The zone ID'). The tool description adds no extra parameter semantics beyond identifying the zone scope, so the schema already carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get'), the resource ('HTTP request header modification rules'), and the scope ('for a zone'). The 'request header' phrasing distinguishes it from the sibling get_response_header_rules and similar rule-list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of related tools like get_response_header_rules, get_url_rewrite_rules, or get_origin_rules. The intended use is only implied by the name and the phrase 'for a zone'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Get' and the noun 'configuration' communicate a read-only retrieval, but the description does not disclose what the response contains, whether schedules can be empty, or any prerequisites beyond the parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It immediately identifies the action and resource, making it easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description provides the bare minimum required to call it. However, with no output schema and no annotations, it should ideally clarify what the returned schedule/configuration looks like and how it relates to neighboring speed-test tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions: 'URL to get schedule for' and 'The zone ID'. The description adds no additional parameter semantics, so the baseline of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get scheduled speed test configuration', and scopes it to 'a URL'. This clearly separates it from sibling tools like get_speed_test or list_speed_tests, which concern test results or listings rather than scheduled configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not explain how it differs from get_speed_test, list_speed_tests, or get_speed_page_trend, leaving the agent to infer the distinction from the word 'scheduled' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. The 'Get' verb indicates a read-only operation, and the description clarifies the target (zone certificates), but it adds no detail about possible status values, error cases, or whether any setup/side effects are involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single efficient sentence that front-loads the verb and resource with zero filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool the definition is minimally adequate: the schema supplies the required zone_id and the description states the purpose. However, with no output schema or annotations, the lack of any detail about return shape/statuses and the absence of sibling differentiation leave notable gaps for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, since zone_id is documented as 'The zone ID.' The description adds no additional parameter context beyond this, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('SSL verification status for a zone's certificates'), which clearly identifies the tool's function. It is semantically distinguishable from close siblings like get_ssl_settings and get_universal_ssl_settings, though it never explicitly differentiates itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a zone's certificates' gives some contextual scope, implying use when certificate verification status is needed for a specific zone. However, the description provides no guidance on when to prefer this tool over related SSL tools (e.g., get_ssl_settings, get_universal_ssl_settings) and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Get' clearly implies a read-only operation scoped to a zone, but the description does not disclose response shape, authentication requirements, error behavior, or any other operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word earns its place and the core action/resource/scope is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter, the description plus schema is technically sufficient to invoke the tool, but it provides no context about what token validation settings are, what the response contains, or how this relates to similar get_*_settings tools. Minimal but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter zone_id with a description 'The zone ID'. The description adds no additional parameter detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a distinct resource ('token validation settings'), and a clear scope ('for a zone'). This makes it easy to distinguish from sibling settings getters like get_schema_validation_settings or get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many related settings getters. There are no alternatives, exclusions, or contextual conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' clearly indicates a read-only operation and the account scoping is useful. However, it does not disclose pagination behavior, ordering, permissions, rate limits, or what is returned, which are common concerns for list endpoints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or repetition. It front-loads the action and resource, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description covers the basic invocation needs. However, with no output schema and no annotations, the absence of pagination or return-format information leaves a meaningful gap, especially given the very large sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter. The description adds no additional meaning to account_id beyond what the schema provides, matching the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a precise resource ('Cloudflare Access groups'), and a clear scope ('for an account'). This distinguishes it effectively from many sibling tools like list_access_apps, list_access_policies, and list_access_tags, so an agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus related access-list tools, nor does it mention any exclusions, prerequisites, or alternatives. It only states what it lists, leaving an agent to infer when it is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It communicates read-only intent via 'List' and account scoping, but it does not mention pagination, response shape, or whether all or only active policies are returned, which matters for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler; the core resource and scope are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter, low-complexity read operation. However, with no output schema and no annotation safety hints, the missing pagination and return-format details leave the agent to infer list behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (account_id is described as 'The account ID'), so the description need not add much. It reinforces the account scope but adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List'), a distinct resource ('Cloudflare Access policies'), and an account scope. This clearly differentiates it from siblings like list_access_apps, list_access_groups, and list_access_service_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to choose this over the many list_access_* siblings, and no exclusions or alternatives. The account scope is implied by 'for an account,' but there is no explicit routing or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The word 'List' signals a read-only retrieval operation, and the parenthetical adds useful semantic context, but the description does not disclose pagination, ordering, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. The parenthetical 'DNS resolver endpoints' is a high-value clarification that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description and schema cover the core invocation needs. However, with no output schema or annotations, response shape and pagination behavior are left implicit, so the context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents account_id as 'The account ID'. The description adds no parameter-specific meaning, which is acceptable given the high schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs the specific verb 'List' with the resource 'Gateway locations' and clarifies their meaning as 'DNS resolver endpoints'. This distinguishes the tool from related siblings like list_gateway_rules and list_gateway_proxy_endpoints without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description only states what it lists, leaving the agent to infer the usage context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself carries the safety burden. 'List' clearly signals a read-only operation and 'for a zone' scopes it, which is adequate minimum transparency. However, it does not disclose pagination, response shape, or any zone-specific behavior such as filtering or empty-result semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words or repeated schema details. It is easy to parse and exactly as concise as the information warrants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description and schema are enough to make the call, but the absence of any output schema or annotation means the description could usefully state what kind of response is returned and how this list differs from the nearby certificate-list tools. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents zone_id with 100% coverage, so the description need not repeat it. 'For a zone' reinforces the scope but adds no meaning beyond the schema property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a specific resource ('Keyless SSL certificates'), and a clear scope ('for a zone'). Among the many sibling list tools, 'Keyless SSL certificates' uniquely distinguishes this from generic certificate, client certificate, and origin CA certificate lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool instead of list_certificate_packs, list_custom_certificates, list_client_certificates, or list_origin_ca_certificates. There are no prerequisites, exclusions, or alternative conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It clearly indicates a read-only listing of past alerts, but it omits details such as pagination, ordering, date range, or response shape. This is minimal transparency without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with a useful clarifying parenthetical; there is no filler and no redundant restatement of the tool name. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter and no output schema, the description is nearly adequate, but it lacks usage context and behavioral details such as pagination. The presence of similarly named sibling tools creates some selection risk, and the description does not address that risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id is fully described in the schema with 100% coverage, so the description does not need to add parameter syntax. It also does not provide any additional meaning beyond what the schema already states, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'notification history' and clarifies it as 'past alerts sent,' which clearly distinguishes it from sibling tools like list_notification_policies and list_available_alerts. There is no ambiguity about what action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_notification_policies, list_available_alerts, or list_notification_webhooks. The description implies it is for past sent alerts but does not state exclusions or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details on its own. It only says 'List Cloudflare Queues in an account' and does not mention pagination, rate limits, authentication requirements, or whether the full set of queues is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It is front-loaded and appropriately sized for such a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description is minimally adequate, and the schema covers the required parameter. However, with no output schema and no annotations, it omits useful details about pagination and the expected return shape, leaving an agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and account_id already has a clear description. The tool description adds no meaningful parameter details beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('Cloudflare Queues'), and an account scope. It naturally distinguishes from sibling get_queue through the list vs. get verb and names 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need to list queues in an account. However, it does not explicitly mention alternatives like get_queue, nor does it provide exclusion criteria such as 'for a single queue, use get_queue'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'List' makes the read-only nature clear and 'in an account' establishes account scoping, but pagination, ordering, response shape, and permission caveats are not mentioned. This is a minimal, non-misleading disclosure rather than a rich one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes meaning, and the length is appropriate for a tool with one required parameter and a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the core selection and invocation information is present. However, with no output schema and no annotations, the description leaves the return format and pagination behavior unspecified, making it adequate but not complete enough for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and account_id is already documented as 'The account ID', so the baseline is 3. The description's phrase 'in an account' loosely reinforces the parameter's role but adds no additional semantics such as accepted formats, ownership details, or validation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('R2 storage buckets') with explicit scope ('in an account'). It distinguishes this tool from sibling R2 tools like list_r2_pipelines and list_r2_catalogs by naming the resource type, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to enumerate an account's R2 storage buckets. However, it provides no explicit guidance about when not to use it, no comparison to sibling list tools, and no prerequisites such as required permissions or auth scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List recipients' and does not disclose read-only semantics, pagination, permission requirements, invalid-ID behavior, or response shape. The agent must infer safety and side effects from the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. The action and resource are front-loaded, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with two required parameters and no nested objects or output schema, so the one-line description is minimally viable. However, it provides no return-format or pagination context, which would make the agent more confident about the response it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions, and schema description coverage is 100%, so the description adds no parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the verb 'List' and a specific resource ('recipients of an R2 share'), which is distinct from the sibling get_r2_share (fetching a share) and list_r2_share_resources (listing resources). It leaves no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb and resource: call this when you need the recipient list for a given R2 share. It does not explicitly contrast with alternatives such as get_r2_share or list_r2_share_resources, but the one-line purpose signals the intended scenario adequately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does communicate that this is a read-only listing operation and that only names are returned, which is useful. However, it does not mention pagination, ordering, permissions, or whether secret values are intentionally excluded beyond the 'names only' phrase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning, and 'names only' efficiently sets output expectations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation with full schema coverage, the description is mostly adequate. However, with no output schema and no annotations, details about the response shape, pagination, and authentication requirements are absent. The description tells what is listed but not fully how the result is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both account_id and store_id have basic descriptions. The tool description adds no further parameter semantics, so it does not exceed the baseline expected when the schema already documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('secrets in a secrets store'), and the scope ('names only'). This distinguishes it from sibling tools like list_secrets_stores and get_secrets_store, which operate on stores rather than the secrets within them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related tools such as list_secrets_stores, get_secrets_store, or list_worker_secrets. There is no mention of prerequisites, exclusions, or scenarios where a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It conveys that this is a read-only listing operation, but it does not mention pagination, ordering, filter behavior, or what the response contains. For a list endpoint, details like pagination and result shape are meaningful behavioral context that is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning: the action, the resource, and the scope are all present. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for basic selection and invocation given the single parameter and full schema coverage. However, with no output schema and no mention of pagination or response characteristics, an agent has limited information about what invoking this tool will return, which leaves a noticeable gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, account_id, is already described as 'The account ID' in the schema. The tool description adds no new parameter-level meaning, but none is needed given the schema's complete coverage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('team virtual networks'), and scopes it to an account. This clearly separates it from the singular 'get_teamnet_virtual_network' sibling and from related but different resources like 'list_teamnet_routes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an account' implies account-level usage, which aligns with the required account_id parameter. However, it does not explicitly state when to choose this tool over the singular get_teamnet_virtual_network or the related list_teamnet_routes, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'List', which implies a read operation, but does not explain pagination behavior, whether all rules are returned, or any auth/permisions context. For a list tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It clearly front-loads the action and resource, and every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description provides the minimal core purpose but omits details like pagination, response shape, and edge-case behavior. The agent can probably call the tool correctly, but the description does not fully equip it for post-call interpretation or for handling large result sets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single zone_id parameter fully documented as 'The zone ID'. The description's phrase 'for a zone' loosely reinforces that the parameter is the zone identifier, but adds no meaningful semantic detail beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a distinct resource ('user agent blocking rules'), and a scope ('for a zone'). It differentiates itself from sibling tools like list_firewall_rules and list_ip_access_rules by naming a unique resource type, so an agent can identify what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the verb and resource: use when needing to list user agent blocking rules for a zone. However, the description provides no explicit guidance about when to prefer this tool over related rule-list tools, nor does it mention any exclusions or prerequisites beyond the zone context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly signals a read-only, account-scoped listing operation, but it does not mention pagination, ordering, permission requirements, or what happens if the account has no indexes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. The core facts — action, resource, scope — are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation the description is adequate, but there is no output schema, no annotations, and no mention of pagination or result shape. An agent can infer the basic semantics from the tool name, but the description itself remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, account_id, is already documented in the schema. The description's 'in an account' phrase reinforces the parameter's role without adding meaningful new information, so the schema-driven baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('Vectorize indexes'), and a clarifying parenthetical ('vector databases') plus an account scope. This distinguishes it from the sibling get_vectorize_index, which targets a single index, even though the distinction is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_vectorize_index. The description implies an account-level enumeration, but it does not state when a user should choose this over a single-index getter or any other sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the operation and gives no details about pagination, authentication, rate limits, what fields are returned, or whether any side effects occur. This is a minimal disclosure that adds little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. The action and scope are front-loaded, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description is minimally viable. However, with no output schema and no annotations, it leaves gaps such as pagination behavior, return format, and whether any filtering beyond zone_id is supported. It also does not point to get_waiting_room for single-room retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with zone_id already described as 'The zone ID'. The description adds only 'for a zone', which reinforces the role of the parameter but gives no additional format, constraints, or behavioral details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus a clear resource ('waiting rooms') and scope ('for a zone'), which unambiguously identifies the action. It also distinguishes this tool from the sibling get_waiting_room, which retrieves a single waiting room rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the verb and resource — an agent can infer that this tool is for enumerating waiting rooms for a given zone. However, there is no explicit guidance on when to prefer this over get_waiting_room, no exclusions, and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' conveys a read-only operation, but the description does not disclose pagination behavior, response format, authorization requirements, or any additional behavioral characteristics that could affect an agent's expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action, resource, and scope with zero filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and no nested objects, so the description is largely sufficient for selecting and invoking it. However, with no output schema, the return shape and any pagination behavior are left unspecified, which is a meaningful gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation, with zone_id already described as 'The zone ID'. The description reinforces that the hostnames belong to a zone, but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a specific resource ('Web3 hostnames') and a clear scope ('for a zone'). This distinguishes it from sibling tools like list_custom_hostnames or list_zerotrust_hostname_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, but the description implies the tool should be used when an agent needs to retrieve Web3 hostnames for a given zone. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', which conveys read-only intent, but it does not mention pagination, response shape, result limits, or any filtering behavior. For a list endpoint, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with a useful parenthetical clarification. There is no redundant information or wasted words, and the core action and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the minimum needed is mostly present. However, the absence of annotations and any mention of pagination or returned data makes it only minimally viable rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already documents zone_id as 'The zone ID'. The description does not add parameter-level detail, so it is at the baseline for a fully covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a specific resource ('zone lockdown rules'), and adds a clarifying parenthetical ('IP allowlisting for URLs') that explains what the resource is. This makes the tool distinguishable from the many sibling list_*_rules tools because it names the exact Cloudflare feature being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical implies the use case: managing IP allowlisting for URLs. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named, so the agent must infer when to choose this over related rule-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' signals a read operation and the scope is stated, but there is no mention of pagination, response shape, or that 'all zones' may require iterating over pages. This is a meaningful gap for a list endpoint with page and per_page parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It conveys the core action, resource, and scope efficiently and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly documents parameters, but with no output schema and no annotations, the description should at least hint at pagination or response characteristics. 'List all zones' is minimally viable, yet an agent could reasonably wonder whether one call returns everything or whether it must page through results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters with helpful descriptions. The tool description adds only the 'domains' synonym and the account scope, which does not materially enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('zones'), adds the parenthetical clarification ('domains'), and states the scope ('in the account'). This clearly distinguishes it from single-zone tools like get_zone and from other account-level list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's usage: call it when you need the zones belonging to the account and want them as a list. However, it does not explicitly contrast it with get_zone or mention when not to use it, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. The verb 'Get' implies a read-only operation, and the scope is stated, but no additional context is given about response behavior, edge cases, or prerequisites. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler, redundant content, or repetition of schema details. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with no output schema, the description provides enough context to select and invoke the tool correctly: what resource is fetched and which zone it applies to. It could be more informative about what the settings contain, but nothing essential is missing for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the only parameter, zone_id, is already documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('Authenticated Origin Pulls settings') scoped to a zone. This distinguishes it from the many sibling getters because the resource is uniquely named and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any exclusions or related tools. The agent must infer usage solely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the only behavioral disclosure. The 'Get' phrasing reasonably implies a read-only retrieval, and the resource is concrete, but the description does not mention response shape, permissions, or any caveats. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with no filler. The core action, resource, and scope are all front-loaded and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only settings lookup with full schema coverage, the description is largely complete for selecting and invoking correctly. The main gap is that there is no output schema or description of what the response contains, but the nature of 'settings' makes this a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter ('zone_id') with 100% coverage, so the description adds no parameter-level meaning. The baseline of 3 applies because the schema does the required work and no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a specific resource ('content upload scan (malware) settings'), and a clear scope ('for a zone'). It is sufficiently distinct from sibling settings tools by the named resource, though it does not explicitly contrast itself with a particular alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need a zone's malware scan settings. However, it gives no explicit guidance about when not to use it or which sibling tool to prefer, leaving the agent to infer the decision from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Get' clearly signals a non-mutating read operation, which is the primary behavior an agent needs to know, but the description adds no further context such as error behavior, permission requirements, or response shape. For a simple read this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single nine-word sentence with zero filler; every word — 'details', 'specific', 'Magic WAN site' — earns its place. The description is front-loaded with the verb and resource, making it instantly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two required parameters, both fully documented in the schema, and a self-evident return value implied by 'details', the short description provides what an agent needs to invoke it correctly. No output schema exists, but the return is obvious from the verb and resource. Minor gaps like not-found error behavior are acceptable for such a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both account_id ('The account ID') and site_id ('The site ID') are described in the schema, so the baseline of 3 applies. The description text adds no parameter-level meaning beyond what the schema already provides. No compensation for gaps is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('details'), and scope ('a specific Magic WAN site'), which clearly conveys single-site retrieval as opposed to the list_magic_transit_sites sibling. However, it doesn't explicitly name the sibling tools it should be chosen over, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies the tool is for retrieving one site by ID rather than enumerating sites via list_magic_transit_sites, but no explicit when-to-use or when-not-to-use guidance is given. There is no mention of alternatives or the conditions that would route an agent to a different tool, leaving usage to convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must carry the behavioral burden. The verb 'Get' correctly implies a read-only retrieval and the object 'configuration' indicates what is returned, but it does not disclose permissions, error behavior, or what happens if no primary nameserver is configured. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place and the core resource and scope are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description is sufficiently complete: it identifies the exact resource and the required input context. It does not describe the return shape, but this is partially mitigated by the clear resource name and the low complexity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the zone_id parameter is already fully described as 'The zone ID'. The description adds only the generic phrase 'for a zone', which does not meaningfully extend the schema's parameter documentation, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a precise resource ('secondary DNS primary nameserver configuration'), and a scope ('for a zone'). This distinguishes it from related siblings like get_secondary_dns_incoming, get_secondary_dns_outgoing, and list_secondary_dns_* tools without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over the many related secondary DNS tools, nor any prerequisites or exclusion conditions. An agent must infer from the name and resource phrase that this is for retrieving a zone's primary nameserver configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It honestly states this is a retrieval operation returning a HAR file from a URL scan, but it does not disclose output format, availability conditions, or failure behavior. Basic transparency is present but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It immediately communicates the action and the artifact being retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter read operation, and the description names the result a HAR file from a URL scan. It lacks format or error details, but for a straightforward get-by-ID tool the core context is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters. The description does not add further meaning beyond connecting the tool to URL scans, but it does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource it gets a HAR file, scoped to a URL scan. This clearly distinguishes it from sibling tools such as get_url_scan, since the unique artifact is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives. The description implies the context URL scans, but never mentions when not to use it or what sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List' does imply a read-only operation and the account scope is stated, but it does not disclose pagination behavior, whether inactive tokens are included, or the shape of the result. This is adequate for a simple read-only listing tool but leaves some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every part adds meaning: the verb, the resource type, the vendor context, and the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and no output schema, the description is nearly complete. It names the resource, the action, and the scope. It could be improved by noting that the response is a list of token objects, but the verb 'List' already implies the return style.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, account_id, is documented as 'The account ID'. The description does not add meaning beyond the schema, but the schema already fully explains the parameter. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus a specific resource ('Cloudflare Access service tokens') and an explicit scope ('for an account'). This clearly distinguishes it from sibling Access tools like list_access_apps, list_access_policies, and list_access_groups, and also from list_account_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as list_access_apps or list_access_policies, or how it differs from the many other Access list operations. The only scoping cue is 'for an account', but it does not help an agent choose among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. The verb 'List' implicitly signals a read-only enumeration operation, and '(WebRTC)' clarifies the resource domain, but the description does not address pagination, result limits, or response shape. For a simple list tool this is adequate but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six words with zero waste; the operative verb and resource are front-loaded, and the '(WebRTC)' parenthetical earns its place by preventing confusion with other Calls-related tools. Every element contributes to selection accuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one well-documented parameter and no nested objects, the description conveys the resource and scope sufficiently for an agent to invoke it correctly. The main gaps—pagination behavior and return format—are minor given no output schema exists, but slightly more detail would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single required parameter (account_id, described as 'The account ID') is already fully documented in the schema. The description adds product context by tying the parameter to Cloudflare Calls, but it does not add meaningful parameter-level semantics beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific verb 'List' and names the exact resource, 'Cloudflare Calls applications,' making the operation immediately clear. The parenthetical '(WebRTC)' disambiguates this from adjacent Calls tools like list_calls_turn_keys and get_calls_app, so an agent can identify the correct tool without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings, such as get_calls_app (fetch a single app) or list_calls_turn_keys (a different Calls sub-resource). Usage is only implied by the verb 'List' in the tool name; no context, prerequisites, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the operation is a read-only listing scoped to an account, but it does not mention pagination, response shape, permissions, or rate-limit considerations. The core behavior is minimally transparent but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the action and scope. Every word earns its place and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, one fully documented parameter, and no output schema, the description is adequate for straightforward invocation. It lacks optional context like pagination or a pointer to get_dlp_profile for single-record needs, but these are not essential for a basic list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents account_id with 100% coverage, and the description adds no additional constraints, defaults, or format details. The baseline of 3 applies because the schema does the necessary work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'DLP profiles' and the scope 'for an account,' clearly identifying the operation. It distinguishes itself from siblings like get_dlp_profile and list_dlp_datasets/list_dlp_patterns by naming a distinct resource and list-vs-get action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does; it offers no guidance on when to choose it over alternatives such as get_dlp_profile for a single profile or list_dlp_datasets for related resources. No exclusions, prerequisites, or conditional context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does state that this is a non-mutating read operation ('List'), which is useful, but it adds no further behavioral context such as pagination, response shape, or account-level requirements beyond the schema. This is minimally adequate for a simple list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It front-loads the verb and object and every word contributes to understanding, making it an appropriately concise definition for a one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list with no output schema, the description supplies the core selection and invocation information. It could be improved by noting what the response contains or whether pagination applies, but the essential details needed to call the tool correctly are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents account_id with 100% description coverage, and the description adds no additional parameter-level meaning beyond restating the account scope. The schema does the heavy lifting, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a concrete resource 'Workers KV namespaces' and scopes it to 'in an account'. This clearly identifies the operation and distinguishes it from sibling tools such as list_kv_keys and get_kv_namespace, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance about when to use this tool versus alternatives. It does not mention that list_kv_keys should be used for enumerating keys or get_kv_namespace for a single namespace, so an agent has no routing information beyond the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only rewraps the tool name's semantics and adds no information about pagination, result shape, read-only guarantees, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that is front-loaded and contains no filler or redundant detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description is nearly sufficient for correct invocation. It could be improved by noting pagination or pointing to the get_magic_transit_connector sibling, but nothing critical is missing for a basic list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is already fully described by the schema with type and maxLength. With 100% schema description coverage, the description's 'for an account' adds no meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('Magic Transit connectors'), and the scope ('for an account'). This clearly distinguishes it from get_magic_transit_connector and other Magic Transit list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use: listing connectors for an account. However, it does not name alternatives such as get_magic_transit_connector for a single connector, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description simply restates the list operation without adding behavioral context. It does not mention pagination, ordering, whether expired or revoked certificates are included, or any other behavior beyond listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description provides the essential invocation details. Pagination and response behavior are not described, but the simplicity of the tool and full schema coverage make the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the zone_id parameter already includes a description. The tool description adds only the contextual phrase 'for a zone' and does not materially extend the parameter semantics provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a specific resource (Origin CA certificates), and the scope (for a zone). It clearly distinguishes this tool from sibling certificate-related tools such as list_custom_certificates and list_certificate_packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the resource name and zone scope, but there is no explicit guidance about when to choose this tool over alternatives like list_certificate_packs or list_custom_certificates. No exclusions or routing hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'List' signals a read-only operation, and 'for an account' sets scope, but it does not mention pagination, filtering behavior, permission requirements, or what the returned data includes. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler or redundancy. It front-loads the operation and resource immediately, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter list operation with no output schema, the description is largely sufficient to allow correct invocation. The only minor gap is the absence of any mention of response shape or pagination, but the low complexity keeps this from being a serious deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to carry parameter documentation. The description adds only 'for an account,' which weakly reinforces the account_id parameter without adding meaningful new semantics beyond the schema's 'The account ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List'), the resource ('IAM resource groups'), and the scope ('for an account'). It also distinguishes itself from the sibling tool get_resource_group through the 'List' verb versus 'get', and from list_permission_groups by naming 'IAM resource groups' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool over alternatives such as get_resource_group or list_permission_groups. The phrase 'for an account' implies account scope, but there are no stated selection criteria, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. 'List' clearly implies a read-only enumeration, which is helpful, but the description does not disclose whether the result is paginated, account-scoped beyond the schema hint, or what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one clearly schema-documented parameter, the description is mostly sufficient. It lacks explicit return-format or pagination details, but the low complexity and the 'list' verb make the tool usable without extensive elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes account_id with 100% coverage, so the baseline is 3. The description adds no extra semantic detail about the parameter, such as its role in scoping the integration list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Zero Trust risk scoring integrations'), making the operation unambiguous. It also distinguishes itself from the sibling get_risk_scoring_integration by implying enumeration of all integrations rather than retrieval of one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_risk_scoring_integration or list_risk_scoring_behaviors. The description does not state conditions like 'use this to fetch all integrations' or 'use get_risk_scoring_integration for a single integration.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The verb 'List' clearly indicates a read-only enumeration, which is useful. However, it does not mention pagination, ordering, response format, rate limits, or permissions, leaving some behavioral details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to identifying the operation and its scope, making it appropriately concise without being vacuous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool—one required parameter, no output schema, and a straightforward list operation—the description is nearly complete. It omits response details and pagination behavior, but an agent can determine how to invoke the tool correctly from the provided description and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter, zone_id, with 'The zone ID', and the description's phrase 'for a zone' aligns naturally with that parameter. The description does not add extra detail about the format or origin of the zone ID, but it does not need to because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('Worker routes'), and a scope ('for a zone'), making the tool's core purpose clear. It does not explicitly differentiate Worker routes from sibling tools like list_workers or list_worker_services, but the resource name is distinctive enough to avoid major ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a zone' implies this tool is appropriate when routes need to be enumerated for a specific zone, and the single required zone_id parameter reinforces that context. However, there is no explicit guidance about when to use this tool instead of alternatives, nor any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavior. 'Get details' communicates a read-only lookup with no side effects, but it does not disclose authentication needs, response shape, or any additional behavioral nuances. For a simple GET this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and the resource immediately and nothing else is extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with two fully documented required parameters, the description is sufficient for basic invocation. However, with no output schema and no usage guidance, it leaves 'details' undefined and does not help the agent know what the response will contain or how to handle related alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both required parameters already have clear descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond implying the tunnel_id identifies the specific GRE tunnel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and a precise resource ('a specific Magic Transit GRE tunnel'), clearly distinguishing it from list-oriented and IPsec/route/site siblings in the sibling list. The word 'specific' also differentiates it from list_magic_transit_gre_tunnels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use for a single known GRE tunnel is implied by 'specific', and the required tunnel_id supports this. However, there is no explicit guidance on when not to use it, no pointer to list_magic_transit_gre_tunnels for enumeration, and no mention of prerequisites like account context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. The verb 'Get' signals a read-only fetch and the parenthetical adds useful context about what origin rules do, but the description does not state the return shape, whether it returns all rules for the zone, or any auth or rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. The verb and resource are front-loaded, and the parenthetical earns its place by clarifying what origin rules are.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description is mostly sufficient to invoke it, but with no output schema it leaves the response shape unstated and does not clarify list vs. single-rule semantics. It is adequate but has clear gaps around return behavior and alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, zone_id, is already fully described in the schema as 'The zone ID' with 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a specific resource ('origin rules for a zone'), and gives clarifying examples ('override origin server, host header, etc.') that distinguish it from sibling rule-retrieval tools like get_url_rewrite_rules or get_request_header_rules. It is not a tautology and clearly identifies the resource being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The zone-scoped phrasing implies the tool should be used when inspecting origin-rule configuration, but an agent is not told how this differs from related getters like get_zone_rulesets or get_ruleset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. The verb 'Get' communicates a read operation, and the parenthetical adds domain context, but the description does not explicitly state that this is non-destructive, what permissions are required, or what the returned settings object contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with the action and resource front-loaded and a useful clarifying phrase appended. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is mostly adequate, but with no output schema and no annotations it leaves the return shape unspecified. A brief statement about what 'settings' includes or that the call only reads configuration would make it more self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the single required parameter zone_id is described as 'The zone ID'. The tool description adds no parameter-level information beyond 'for a zone', so the schema is doing the work and the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a specific resource ('Page Shield settings'), and the scope ('for a zone'), with a clarifying parenthetical that this is client-side security monitoring. This distinguishes it from generic getters like get_zone_settings or get_ssl_settings without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'for a zone (client-side security monitoring)' phrasing implies the usage context, but the description never states when to prefer this over sibling tools such as list_page_shield_scripts, list_page_shield_connections, or get_smart_shield_settings. There is no when-not-to-use or alternative tooling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' and 'current authenticated user' imply a read-only operation scoped to the caller, which is useful. However, it does not explicitly state authentication requirements, possible errors, or the complete response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The action and target resource are front-loaded, and the example fields are parenthetical and brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is extremely simple with no parameters and no output schema, this description is mostly sufficient for selecting and invoking it. It could be more explicit about the difference from account-scoped endpoints and list the full return fields, but the core semantics are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify. A baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get current authenticated user details'. It clearly indicates the tool returns the caller's own identity information, which helps distinguish it from sibling tools like get_account and get_membership, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need details about the currently authenticated user. However, it gives no explicit when-not-to-use guidance or alternatives, and with many sibling tools such as get_account, get_membership, and verify_token, some ambiguity remains about scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'List' clearly indicates a read-only enumeration operation, and 'for a zone' scopes it. However, it does not disclose pagination behavior, ordering, filtering, or any details about what is returned beyond the implied list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds value: the verb, the resource type, and the scope are all necessary and present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter fully documented in the schema, the description is minimally sufficient for invocation. However, there is no output schema and no mention of pagination, response shape, or distinctions from related certificate tools, leaving some behavioral context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the sole parameter zone_id is described in the schema. The description's phrase 'for a zone' aligns with the parameter but adds no additional format, constraints, or semantic detail beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('SSL certificate packs'), and a clear scope ('for a zone'). This distinguishes it from siblings such as get_certificate_pack (single-item retrieval) and list_custom_certificates (a different certificate resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: if an agent needs to enumerate SSL certificate packs for a zone, this is the appropriate tool. However, the description offers no explicit guidance about when to prefer this over alternatives like get_certificate_pack or list_custom_certificates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. 'List' implies a read-only operation, but there is no mention of pagination, filtering, return shape, or any side effects. Compared to simpler list tools that at least state scoping constraints, this adds almost no behavioral detail beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word adds meaning: 'List' is the verb, 'Logrush jobs' is the resource, 'for an account' is the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param list tool, the description is minimally viable: it names the operation and scope. However, with no output schema and no annotations, it does not mention pagination, result format, or boundaries like zone-vs-account, leaving some ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, account_id, is already documented as 'The account ID.' The description adds no extra meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a clear, specific verb+resource statement: 'List Logpush jobs for an account.' The account scoping cleanly distinguishes it from the sibling list_logrush_jobs_zone, so an agent can tell them apart without extra context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an account' provides clear context for when to use this tool: account-level Logrush jobs. It does not explicitly exclude zone-level jobs or name the sibling tool, but the scoping is unambiguous enough for a single-param list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' implies a read-only operation and 'detected by Page Shield' narrows the result set, but there is no disclosure of pagination, ordering, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only eight words, front-loads the verb and resource, and contains no filler or redundant phrases. This is appropriately concise for a simple one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description and schema are minimally sufficient, but the absence of pagination/result details and lack of explicit differentiation from Page Shield siblings leave gaps. There is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, zone_id, is fully documented in the schema (100% coverage), so the baseline applies. The description adds no extra semantic detail about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('scripts detected by Page Shield'), making it immediately distinct from sibling Page Shield tools such as list_page_shield_connections and list_page_shield_policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving Page Shield-detected scripts, but it does not explicitly state when to prefer it over the closely related Page Shield list tools, nor does it provide exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It conveys a read-only listing action and the account scope, which is useful, but it does not disclose pagination, result shape, ordering, or other API behavior relevant to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or repetition. Every word carries meaning and the structure is maximally easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter account-scoped list operation, the core invotation is clear and the schema supplies the required parameter. However, the absence of an output schema and any mention of pagination or return format leaves some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is already fully described by the input schema (100% coverage). The description's 'for an account' merely echoes the schema and adds no additional semantic detail about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a specific resource ('R2 catalogs'), and an account scope. The plural form and resource name clearly distinguish it from siblings like get_r2_catalog (singular fetch) and list_r2_buckets (different R2 resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description encodes the use case: call this when enumerating R2 catalogs for an account. It does not explicitly name alternatives or state when not to use it, so some inference is required from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It clearly identifies this as a read-only listing operation and states the content type, but it does not describe response structure, pagination, ordering, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, redundancy, or unrelated information. Every word adds meaning: verb, resource, scope, and content clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, this is minimally adequate: an agent knows what to call and with what input. The lack of an output schema and any mention of response shape or pagination leaves some uncertainty, but the core invocation path is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single parameter, zone_id, with a clear description. The tool description adds no additional parameter detail beyond the zone-scoped context, so this is an acceptable baseline but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Security Center insights') with a clear scope ('for a zone'). The parenthetical clarifies that 'insights' includes security issues and recommendations, removing ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a zone' implies this is a zone-scoped list operation, and the required zone_id parameter reinforces that. However, the description does not mention when to prefer this tool over alternatives or note any related account-level or different-scoped tools, leaving usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' clearly signals a read-only enumeration, but the description does not disclose pagination, response contents, or any zone-specific constraints beyond the required zone_id. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that immediately states the action and scope. No filler or redundant phrasing; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no nested objects, no output schema), the description covers the essential semantics. However, it lacks any detail about the returned data, pagination, or edge cases such as invalid zone_id. It is functional but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter zone_id is already described as 'The zone ID'. The description adds only the context that the snippets belong to a zone, which aligns with but does not significantly enrich the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('Cloudflare Snippets'), and a scope ('for a zone'). This is sufficient for an agent to distinguish it from the many sibling list_* tools, none of which target Snippets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to enumerate Snippets for a given zone, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. Since Snippets is a distinct resource, the usage context is reasonably inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It reasonably conveys that this is a read-only listing operation and adds the 'active' qualifier, but it does not disclose permissions, pagination behavior, session variety, or whether sessions are ephemeral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no redundancy. It names the operation, the resource type, and the scope, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, it covers the essential information: what is listed and for which script. However, since there is no output schema and no annotations, the return shape and any invocation constraints are left unspecified, requiring the agent to infer them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both required parameters (account_id and script_name) are already described in the input schema. The description only restates the Worker-script scope and adds no parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('active tail log sessions'), and the scope ('for a Worker script'). This is immediately clear and distinguishes it from sibling worker tools like list_worker_secrets, list_worker_deployments, and get_worker_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use it when you need active Worker tail sessions. However, there is no explicit guidance about when to prefer this tool over related worker list tools, nor any exclusions or alternative routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Verify' and 'get its status' suggest a read-only validation operation with a status result, but the description does not explicitly state that no state changes occur, what authentication scope is required, or failure behavior. It provides basic but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler, front-loaded with the action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter verification tool, the description is largely sufficient: it names the operation, the subject, and the output category (status). It does not enumerate possible status values or explicitly say no parameters are required, but the empty schema already communicates that. Overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The phrase 'current API token' usefully signals that the token comes from the request context rather than a parameter. No parameter descriptions are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and identifies the resource ('the current API token') plus the result ('get its status'). It clearly indicates this operates on the caller's own token, providing some distinction from siblings like verify_account_token, though it does not name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended scenario—checking the status of the token currently used for authentication—but does not state when to prefer it over verify_account_token or list_account_tokens, nor any exclusions. Usage guidance is therefore implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get details' clearly indicates a read operation with no obvious side effects, but the description adds no context about error behavior, required permissions, or what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is front-loaded with the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two required, well-documented parameters, the description is sufficient to understand what the tool does. There is no output schema, but 'details' adequately conveys that the tool returns certificate information, though it could be more specific about what fields are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both zone_id and certificate_id already documented in the schema. The description adds no additional meaning about parameter usage, formats, or relationships, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('details of a specific custom SSL certificate'). The word 'specific' distinguishes this from list_custom_certificates, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving one certificate by its ID rather than enumerating all custom certificates, but it does not explicitly name alternatives or state when not to use it. Prerequisites beyond having the zone_id and certificate_id are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. The verb 'Get' and 'settings' clearly signal a read-only, non-destructive operation, which is the main behavioral trait an agent needs. However, it does not mention authentication requirements, rate limits, or whether the settings response has any notable structure or defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value: the verb, the resource, and the scope are all present, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter settings getter, the description and schema together are nearly sufficient. The absence of an output schema means the description could have been slightly more explicit about what 'fraud detection settings' includes, but the core use case is fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, zone_id, is already documented in the schema. The description's 'for a zone' aligns with the parameter but does not add meaningful detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('fraud detection settings') plus a clear scope ('for a zone'). This distinguishes it from the many other get_*_settings tools in the sibling list, such as get_bot_management or get_token_validation_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs to retrieve fraud detection settings for a zone, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. It provides no comparative guidance against sibling settings tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. 'Get details' conveys a read-only operation with no side effects, but the description adds no further behavioral context such as error behavior, whether the route must already exist, or what the returned detail object contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word ('Get', 'details', 'specific', 'Magic Transit static route') contributes precision and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with no output schema, this is nearly complete: it identifies the resource and the specific scope. It could be improved by pointing to list_magic_transit_routes for discovering route IDs or by describing the returned detail fields, but these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover both required parameters (route_id and account_id) at 100%, so the description does not need to repeat them. The description adds no parameter-level meaning beyond the schema, making baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the precise resource ('a specific Magic Transit static route'). This clearly distinguishes it from the list_magic_transit_routes sibling, which is the natural alternative for fetching multiple routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving one existing route by ID, but it gives no explicit guidance about when to choose it over list_magic_transit_routes or how to obtain route_id. The intended usage is inferable from the name and wording, but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'Get' implies a read-only operation, and the 'modern WAF rulesets API' note adds useful endpoint context. It does not disclose response shape, error behavior, or whether the zone must already exist, but for a simple read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that states the action, resource, scope, and API variant with no filler. The key differentiator ('modern WAF rulesets API') is placed at the end but earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description provides enough context to identify the correct endpoint and scope. Since there is no output schema, a bit more detail about the return shape would help, but the tool is simple enough that the definition is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter zone_id is already fully described in the schema as 'The zone ID', so the description adds no additional parameter-level meaning. Schema description coverage is 100%, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the target resource ('rate limiting rules'), the scope ('for a zone'), and the API generation ('modern WAF rulesets API'). This distinguishes it from legacy rate-limit siblings like list_legacy_rate_limits and get_legacy_rate_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'modern WAF rulesets API' implicitly tells the agent this is the modern counterpart to legacy rate-limit tools, providing some usage context. However, it does not explicitly state when to prefer this over related ruleset tools such as get_ruleset or list_zone_rulesets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' implies a read-only fetch, which is accurate, but the description does not clarify whether the result is a list or a single rule, pagination, or response shape. It is not misleading, just minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler. The key qualifiers ('HTTP response header modification', 'for a zone') are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the core is covered: what is being fetched and for which resource. It could be slightly richer, e.g., noting the response is a list, but nothing critical is missing for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the only parameter (zone_id) already has a description in the schema. The tool description adds only the context that the rules are zone-scoped, which is already implicit in the parameter name and schema. This is the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a precise resource ('HTTP response header modification rules'), and the scope ('for a zone'). It disambiguates from the sibling get_request_header_rules because 'response' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description: use it when you need response header modification rules rather than request header rules or other rule types. However, it does not explicitly state when not to use it or name an alternative, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Get' signals a read operation, and the zone scoping adds context, but the description does not explicitly say the call is non-destructive, what the returned settings look like, or whether any authorization or error caveats exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler or redundant phrasing. The key resource and scope are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description is mostly complete: an agent knows the required input and the action. It falls slightly short because it does not describe the shape or nature of the returned settings, leaving some inference to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter zone_id is already fully described in the schema ('The zone ID'), and schema coverage is 100%. The description adds no extra parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a specific resource ('API schema validation settings'), and a clear scope ('for a zone'). This distinguishes it from sibling tools like get_token_validation_settings and generic zone-setting getters, so an agent can identify the intended target without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb and resource, but there is no explicit guidance about when to choose this tool over alternatives such as get_token_validation_settings or get_api_shield_config. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. 'Get details' correctly implies a read-only, non-destructive operation. It does not disclose response shape, auth requirements, or error behavior, but for a simple retrieval tool the read-only implication is the most important trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or repeated schema information. The core operation and resource are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity two-parameter GET tool with no output schema or annotations. The description, combined with the well-documented schema, is largely sufficient for an agent to call it correctly. It would be more complete if it clarified what is returned beyond 'details' or explicitly tied the parameters to the target peer, but nothing essential is missing for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both account_id and peer_id are already documented clearly in the input schema. The description adds no additional meaning about parameter relationships, formats, or lookup semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get details of') and a specific resource ('a specific secondary DNS peer'). The word 'specific' clearly distinguishes this singleton-get tool from sibling list tools such as list_secondary_dns_peers, and the resource naming keeps it distinct from get_secondary_dns_primary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you use this tool when you need details about one particular secondary DNS peer rather than listing all peers. However, it does not explicitly state when to choose it over alternatives or mention any preconditions such as needing a peer_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It signals a read-only operation ('Get') and defines the response scope as 'all settings' across the named categories. It does not mention response shape, pagination, or permission prerequisites, but for a simple zone-id GET these are minor omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, followed by a useful scope qualifier. There is no filler, no repetition of the tool name, and no boilerplate phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-required-parameter getter with no output schema, the description is mostly sufficient: an agent can infer both the return scope and how it differs from get_zone_setting. Minor gaps are the lack of an explicit pointer to the singular alternative and any indication of the response structure, but these do not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with zone_id already documented as 'The zone ID'. The description adds only the contextual hint that these settings belong to a zone, not new parameter-level semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and object ('all settings for a zone'), then narrows the scope by enumerating SSL, security, caching, and performance settings. This clearly distinguishes it from sibling tools like get_zone_setting (single setting) and category-specific getters such as get_cache_settings or get_ssl_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a comprehensive read when an agent needs the full settings picture, but it never explicitly states when to prefer this over get_zone_setting or the narrower category getters. No exclusions or alternative tool names are given, so the usage context must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates a read-only listing operation and pins the scope to account level, which is useful. However, it does not disclose pagination, ordering, authentication requirements, or response shape beyond what 'list' implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded with the verb and resource, making it easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list endpoint with full schema coverage, the description conveys the resource, scope, and operation well enough for an agent to select and invoke it. It would benefit from mentioning pagination or return format, but those are not critical gaps at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so account_id is already documented. The description reinforces the account-level scope but adds no new semantic detail about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('mTLS certificates') and scope ('at account level'). This distinguishes it from zone-level certificate tools and the singular get_account_mtls_certificate sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at account level' provides implicit context that this tool is for account-scoped mTLS certificates, but it does not explicitly mention when to prefer this over alternatives like list_client_certificates or get_account_mtls_certificate. Usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does reveal that this is a read-only list operation scoped to a zone. It does not mention pagination behavior, response shape, or how filters interact, which makes it minimally adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the action, resource, and scope are front-loaded. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zone-scoped list tool, the description plus a fully documented parameter schema is sufficient to invoke correctly: provide zone_id and optionally hostname and per_page. It omits an explicit return-shape statement, but there is no output schema and 'List' strongly implies a paginated array of custom hostnames.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the required zone_id plus optional hostname and per_page parameters are already documented. The description's 'for a zone' aligns with zone_id but adds no new meaning about filtering or pagination defaults, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific verb 'List' and the exact resource 'custom hostnames (SSL for SaaS)' with scope 'for a zone.' The parenthetical clarifies what custom hostnames are and helps distinguish this from the sibling list_custom_certificates tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a zone' gives clear context that this is a zone-scoped enumeration operation. However, it does not name alternatives such as get_custom_hostname for a single hostname or list_custom_certificates for certificates, nor does it state when not to use this tool, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'List' implies a read-only operation and the zone scoping is clear, but the description does not disclose pagination behavior, response format, or what fields each rule includes. For a simple list tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 10-word sentence with zero waste. The verb and resource are front-loaded, and the clarifying parenthetical earns its place by disambiguating the rule type. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this simple — one required parameter, 100% schema coverage, no output schema — the description conveys essentially everything needed to invoke it correctly: what it lists, at what scope, and what the resource means. Minor gaps like pagination and return details are tolerable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single parameter zone_id is already documented as 'The zone ID'. The description's 'for a zone' phrasing merely echoes the schema and adds no format, default, or constraint detail. Baseline 3 is appropriate when the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a precise resource (IP access rules), and a scope (for a zone). The parenthetical '(IP blocking/allowing)' clarifies what these rules are, which helps an agent distinguish this from sibling tools like list_firewall_rules, list_zone_lockdown_rules, or list_user_agent_rules without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical hint that these are IP blocking/allowing rules implies the use case but does not explicitly say when to choose this tool over alternatives. With a huge sibling list containing many similar list_* rule tools, explicit routing guidance (e.g., 'for non-IP firewall rules use list_firewall_rules') would materially help but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the disclosure burden. It does convey that the operation is a list/read scoped to a zone and that the API is deprecated. However, it does not disclose pagination behavior, response shape, or what deprecation implies operationally (e.g., removal/unavailability), which would matter for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence with no filler. The resource and scope come first, and the deprecation status is delivered as a compact parenthetical that earns its place by changing user behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter list tool with no output schema and no annotations, the description is mostly sufficient: it names the resource, scope, and deprecation status. The only meaningful gaps are pagination details and an explicit current alternative, but these are minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already documents zone_id as 'The zone ID'. The description adds only 'for a zone', which reinforces the parameter's scope but does not add format, constraints, or additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and a specific resource ('legacy rate limiting rules for a zone'), and the parenthetical '(deprecated API)' distinguishes it from current rate-limit tooling such as get_rate_limiting_rules and from the singular get_legacy_rate_limit. An agent can identify what the tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(deprecated API)' provides an implied usage cue that this endpoint should be avoided or used only for legacy cases, but it does not name an alternative or state explicit when-to-use/when-not-to-use conditions. Among the sibling tools, get_rate_limiting_rules and get_legacy_rate_limit exist, but the description does not point to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. 'List' makes the read-only nature clear, but the description adds no details about pagination, response format, or auth requirements. It is adequate for a simple list operation, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence says exactly what the tool does with no filler. Every word earns its place for a tool with a single parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation, the description is nearly complete: it names the resource, the scope, and the action. It omits output/pagination details, but no output schema exists and the return type is reasonably inferable from 'List ... tunnels'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, account_id, is already described ('The account ID'). The description's 'for an account' reinforces the parameter's meaning but adds no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a precise resource ('Magic Transit GRE tunnels'), and a scope ('for an account'). It distinguishes this tool from siblings such as list_magic_transit_ipsec_tunnels, list_magic_transit_routes, and get_magic_transit_gre_tunnel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call it when you need to enumerate all GRE tunnels belonging to an account. However, it does not explicitly mention alternatives, nor does it say when to prefer the singular get_magic_transit_gre_tunnel or related list endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation, which is the core behavior, but it adds no detail about pagination, response shape, or operational caveats. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, no-waste sentence that states the action, resource, and scope without fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity: one required parameter, fully documented by the schema, and no nested objects or output schema. The description plus schema gives an agent enough to select and invoke it correctly. It stops short of a 5 because it omits any mention of pagination or what the returned list contains beyond the resource name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter account_id is already described as 'The account ID.' The description's 'for an account' adds no substantive meaning beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Magic Transit static routes') with account scoping, making the tool's job immediately clear. It also distinguishes itself from nearby siblings like get_magic_transit_route and list_magic_transit_gre_tunnels by naming 'static routes' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when you need a list of Magic Transit static routes for an account, but it provides no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusions, which matters given the large number of sibling list and get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Listing is an inherently read-only operation, and the word 'available' hints that the response is scoped to token-eligible permission groups. With no annotations, the description carries the behavioral burden, but it does not mention pagination, ordering, or permission prerequires; these are moderate gaps rather than severe omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource with no wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with no output schema, the description names the resource and scope clearly enough for an agent to invoke it. It does not describe output formatting or edge cases, but those are reasonably inferrable from a list operation; the main missing element is an explicit nod to the closely related list_permission_groups tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is fully described in the schema with 100% coverage. The tool description adds token-permission context but does not provide additional parameter-level details beyond what the schema already states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('permission groups for API tokens'), with a qualifier that distinguishes it from the sibling list_permission_groups. An agent can immediately understand what this tool returns and that it is scoped to token permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for API tokens' implies when this tool should be used, especially compared to the sibling list_permission_groups. However, it never explicitly names alternatives or states when not to use this tool, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey behavior. 'List' signals a read-only enumeration, and the account scope is stated, but the description does not mention pagination, response shape, or any permissions/limitations. It is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and resource, with a helpful parenthetical. No redundant words or content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list call with no output schema, the description covers what the tool does and its scope. It does not describe pagination or return value details, but the operation is simple enough that 'List ... widgets for an account' gives an agent sufficient information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter account_id is described in the schema as 'The account ID'. The description's 'for an account' reinforces the parameter's meaning but adds no new detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List), a specific resource (Turnstile widgets), a scope (for an account), and clarifies the domain with 'CAPTCHA alternatives'. The verb and resource make it easy to distinguish from get_turnstile_widget and other list_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an account' implies the tool is used to enumerate widgets belonging to a given account, but it does not explicitly state when to prefer this over get_turnstile_widget or mention any exclusions. Usage context is implied, not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry behavioral disclosure. It discloses a key safety property—secret values are not returned—but says nothing about pagination, ordering, permissions, or error behavior when the script does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler. The main action is front-loaded and the important negative behavior is appended in parentheses, keeping it compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, two-parameter list tool with no output schema, the description adequately explains the returned data (secret names) and the important non-returned data (values). It could mention permissions or response form, but these are not critical for selecting and calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema. The description does not add parameter-level detail, but none is necessary; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List secret names for a Worker script.' The parenthetical 'does not return secret values' adds a scoping property that separates it from value-returning operations and clarifies exactly what the list contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to enumerate secret names for a Worker script, and the parenthetical warns against expecting secret values. It does not explicitly name alternatives or state when to prefer this over sibling list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get details' clearly signals a read-only operation, but the description does not disclose response format, possible errors, or authorization requirements. It is minimally adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or redundant wording. Every word contributes to identifying the action and resource, and it is front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with two fully described parameters, the description is mostly sufficient. However, there is no output schema and the description does not indicate what 'details' will be returned, nor does it cover edge cases like not-found behavior. It is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both tsig_id and account_id, so the schema does the heavy lifting. The description adds no additional parameter meaning beyond what the schema already states, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get details') and a specific resource ('secondary DNS TSIG key'). The word 'specific' differentiates this from the sibling list_secondary_dns_tsigs, so an agent can immediately tell the two apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'details of a specific ... key' clearly implies this tool is for fetching a single TSIG key identified by ID, rather than listing all keys. It does not explicitly name alternative tools or exclusion conditions, but the usage context is clear enough for this simple get-by-ID operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden; it does state a read-only 'list' action and an account scope. It does not describe pagination, required permissions, or response characteristics, leaving some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and scope, with no filler. It earns its place even though more behavioral detail could be added elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with no output schema, the description is minimally adequate but relies on the agent to infer response shape and pagination behavior. It gives the core concept but not full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id is fully documented in the input schema with 100% coverage. The description reinforces the account-level scope but adds no new format or constraint details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List'), a resource ('rulesets'), and a scope ('account level'). This clearly distinguishes it from zone-level or single-ruleset siblings such as list_zone_rulesets and get_account_ruleset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at the account level' gives clear context for when this tool applies, contrasting with zone-scoped ruleset tools. It does not name alternatives or exclusions explicitly, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' correctly implies a read-only operation, but the description does not disclose pagination, output shape, ordering, or whether all namespaces are returned. It is minimally transparent but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource with no wasted words. It is appropriately sized for a one-parameter list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is functionally sufficient for a simple account-scoped list operation: it names the resource, scope, and the required account_id is documented in the schema. However, with no output schema, it does not clarify the response shape or list limits, so it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single account_id parameter already has a clear description. The tool description merely repeats the account scope and adds no additional meaning about the parameter format, constraints, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Durable Object namespaces'), and adds the scoping phrase 'in an account'. This cleanly distinguishes it from sibling list tools such as list_kv_namespaces or list_d1_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the operation to an account-level listing, which is useful context for selecting this tool. It does not explicitly name alternatives or exclusions, but the resource is specific enough that usage is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' conveys a safe, read-only operation and 'for the authenticated user' discloses the identity scope, which is useful context. However, it does not disclose return shape, pagination behavior, or what fields a membership contains, and there is no output schema to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence with zero filler. The verb and resource are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no annotations and no output schema, the description covers core purpose and scope but omits the response shape entirely. One clause noting that it returns the accounts and roles associated with the user would materially help. Adequate, but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100% and there is nothing for the description to explain. Per the 0-params baseline, no parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a specific resource ('account memberships'), and an explicit scope ('for the authenticated user'). The scope phrase distinguishes it from the conceptually adjacent sibling list_account_members, which lists the users of an account rather than the current user's own account associations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: retrieve the authenticated user's memberships when you need to know which accounts the current user belongs to. However, it never explicitly names alternatives (get_membership, list_accounts, list_account_members) or states when not to use this tool, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does state the observable result (subscription tier values) and the decision-relevant meaning, but it does not explicitly cover error behavior, authentication/authorization needs, or confirm the read-only nature beyond the verb 'Get'. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the operation, the output values, and the purpose with zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with no output schema, the description is nearly complete: it gives the required input domain, the possible output values, and the practical use. It only lacks explicit notes on error behaviors or authentication, which are minor for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the single required parameter with 100% coverage ('The zone ID'). The description adds no additional parameter semantics, so the baseline score of 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource, plus the exact enumerated values (Free/Pro/Business/Enterprise), and explains the purpose of the result ('determines available features'). This distinguishes it from sibling zone getters such as get_zone or get_zone_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'determines available features' clearly signals the context in which an agent should call this tool: when it needs to know what features a zone's plan supports. It does not name alternatives or exclusions, but for a simple read-only tier lookup the implied usage is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It correctly signals a read-oriented list operation and adds the valuable scoping detail that results are limited to what the current API token can access. It does not mention response shape, pagination, or error behavior, but for a parameterless list operation this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that states the verb, resource, and scope without unnecessary words. It is immediately readable and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description is largely complete: it tells the agent what it will get and under what access scope. The only missing piece is the return format, which is not documented by an output schema, but this is unlikely to prevent correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already covers everything. The description adds no parameter-specific detail because none is needed; the scoping context it provides ('accessible with the current API token') is the only relevant semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('Cloudflare accounts') along with the exact scope ('accessible with the current API token'). This makes it easy to distinguish from sibling tools like get_account or list_account_members, which operate on different resources or granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to enumerate Cloudflare accounts available to the current token. However, it does not explicitly mention alternatives or state when not to use it, leaving the agent to infer the routing decision from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. 'List' conveys a read-only operation, but the description does not mention pagination, response contents, ordering, or any permission prerequisites. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes to identifying the action, resource, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with a self-explanatory name, the description plus schema is almost sufficient. It omits response format details, but an agent can correctly select and invoke the tool with the provided zone_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, zone_id, is fully described in the schema at 100% coverage. The description repeats the zone scoping but adds no parameter syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('custom SSL certificates') scoped to 'a zone,' making the tool's purpose immediately clear. This also distinguishes it from sibling tools like list_certificate_packs and list_client_certificates, which target different certificate categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the tool is for retrieving user-uploaded custom SSL certificates for a particular zone and requires a zone_id. It does not explicitly name alternatives or state when not to use it, but the scope wording is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
'List' communicates a read-only retrieval action, which covers the basic behavior. With no annotations, the description carries the full burden, but it does not disclose pagination, ordering, or other response traits; for a straightforward list operation this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. The key information—action, resource, and scope—is all present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one required, fully documented parameter and no output schema—the description is nearly complete. It could be slightly more complete by mentioning pagination or explicitly contrasting the account-scoped sibling, but no critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with zone_id documented as 'The zone ID'. The description's 'for a zone' phrase adds slight scope context but does not materially go beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('Logpush jobs') with an explicit scope ('for a zone'). This clearly distinguishes it from the sibling list_logpush_jobs_account, which operates at the account level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for zone-scoped Logpush jobs, providing enough context for an agent to select it over account-scoped alternatives. However, it does not explicitly mention the account-scoped sibling or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, and the zone-scoped TCP/UDP proxy context is helpful, but the description does not mention pagination, ordering, response shape, or any rate-limit/auth considerations. This is adequate for a simple list tool but leaves room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that states the action, resource, scope, and technical context with zero filler. Every element adds value, and the key disambiguator '(TCP/UDP proxy)' is placed immediately, making it easy for an agent to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description is mostly complete: it identifies the resource, the zone scope, and the protocol context. However, with no output schema and no mention of pagination or response contents, an agent cannot fully predict what the tool returns. This is a minor gap but not a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single zone_id parameter. The description reinforces the zone scope but adds no meaningful detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (List) and resource (Spectrum applications) plus the exact scope (for a zone), and the parenthetical '(TCP/UDP proxy)' distinguishes this from other application-listing siblings like list_access_apps and list_calls_apps. It is immediately clear what this tool does and how it differs from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is a zone-scoped operation for Spectrum applications, which tells the agent when it applies. It does not explicitly state when not to use it or name alternative tools, but the scope and resource are specific enough that the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'List' conveys a non-mutating read operation and the rollback context adds practical meaning, but the description doesn't mention ordering, pagination, or what identifiers/fields the returned deployments contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action and resource, with 'useful for rollback decisions' as a compact parenthetical. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only list with fully documented parameters, the description is complete enough to select and invoke the tool. The lack of an output schema means return-field details are absent, but the resource and purpose are sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both account_id and script_name are already described in the input schema. The tool description adds no parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List'), a specific resource ('deployments'), and scopes it to 'a Worker script', which clearly differentiates it from sibling tools like list_worker_builds or get_worker_script. The rollback note adds purpose without confusing the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case ('useful for rollback decisions'), which tells the agent when this list will be valuable. It does not name alternatives or state when not to use it, so it misses only the explicit exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It conveys that this is a non-mutating retrieval of public data via the verb 'Get', but it doesn't explicitly state the response form (CIDR blocks), that results change over time as Cloudflare updates ranges, or the absence of side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 11-word sentence front-loads the verb and resource, then appends the use case. Every word earns its place; there is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of minimal complexity (0 params, no output schema, no nested objects), the description covers purpose and application scenario well. The only gap is the unstated response format (CIDR notation and how IPv4/IPv6 are grouped), but 'IP ranges' standardly implies CIDR in this domain, making this a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing for the schema to document and nothing for the description to clarify about inputs. Per the baseline for 0-param tools, this is a 4; the description adds useful context about the returned data rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), a specific resource ('Cloudflare's IP ranges'), and the exact data scope ('IPv4 and IPv6'). This is unambiguously distinct from all 300+ siblings, including superficially similar ones like get_intel_ip (reputation lookup), list_ip_prefixes (account-owned prefixes), and list_ip_access_rules (firewall rules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'useful for allowlisting' provides a clear, concrete context for when this tool should be invoked. It doesn't name explicit exclusions or alternatives, but for a zero-parameter utility with no meaningful sibling overlap, that would be noise rather than value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![cloudflare-mcp MCP server](https://glama.ai/mcp/servers/pocc/cloudflare-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pocc/cloudflare-mcp)

Score Badge

Copy to your README.md:

[![cloudflare-mcp MCP server](https://glama.ai/mcp/servers/pocc/cloudflare-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pocc/cloudflare-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pocc/cloudflare-mcp'

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