cf-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes. However, some overlaps exist: cf_list_custom_rules is a convenience wrapper for cf_get_entrypoint_ruleset's custom WAF phase, and cf_list_super_bot_fight_mode_config is a subset of cf_get_bot_management_config. These could cause minor confusion but are well-documented.
Naming Consistency4/5
All tools follow the 'cf_[verb]_[noun]' pattern with snake_case (e.g., cf_get_zone, cf_list_zones). One outlier is cf_baseline_traffic_diff, where 'baseline' is used as a noun rather than a verb, breaking the pattern. Overall, naming is mostly consistent.
Tool Count2/5
32 tools is excessive for a typical MCP server, which ideally has 3-15. While the Cloudflare API is broad, many tools are convenience wrappers (e.g., cf_list_custom_rules) or very specific (cf_baseline_traffic_diff). The count feels bloated and could benefit from consolidation.
Completeness2/5
The tool set is entirely read-only, lacking any create, update, or delete operations. For a general Cloudflare interface, this is a severe gap. Even for a diagnostic-focused server, essential actions like blocking IPs or modifying rules are missing. The presence of validation and URL-building tools doesn't compensate.
Average 4.1/5 across 32 of 32 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only reveals that it's a read operation and gives the API endpoint, but lacks details on pagination, authentication, rate limits, or response shape. The existence of an output schema is not mentioned.
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 (2 sentences) with no wasted words, but it sacrifices necessary information. It is front-loaded with the purpose, but the brevity leads to incompleteness.
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 single parameter with no description and the presence of an output schema (not referenced), the description feels incomplete. It lacks explanation of the parameter and usage context, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description fails to explain the meaning or format of the 'account_id' parameter. It only implies its use in the URL, but offers no clarification 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 clearly states the tool's purpose: listing configured Access Identity Providers. It includes examples (Okta, AzureAD) and specifies the verb 'List' and resource, distinguishing it from sibling list tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or contextual hints. It simply states what the tool does without suggesting appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It implies read-only (list operation) and notes the HTTP call and return envelope, but lacks explicit read-only flag, pagination details, or auth requirements. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each adding value: purpose, contents, HTTP endpoint, return format. No fluff 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?
Given an output schema exists, the return envelope is described adequately. However, the missing parameter description and lack of usage guidance prevent full completeness for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides no details about the zone_id parameter beyond its existence. It does not explain what constitutes a valid zone_id or how to obtain it, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists managed ruleset deployments at a zone's firewall_managed phase, specifying the Cloudflare Managed and OWASP Core Rulesets. It distinguishes from siblings like cf_list_rulesets by focusing on phase-specific managed deployments, though it could be more explicit about when to use this over cf_get_entrypoint_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?
No guidance on when to use this tool versus alternatives. Sibling tools like cf_get_managed_rule_details or cf_list_rulesets exist, but the description offers no comparative context 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 provided; description only states it's a GET (non-destructive) and returns 'posture and metadata'. Lacks details on permissions, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no superfluous text. Directly states purpose and API endpoint, earning 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?
Output schema exists, so return values need not be detailed. However, parameter semantics are missing, and tool usage context (e.g., prerequisites) is absent, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description does not explain what account_id or device_id represent. No additional meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'single WARP device', clearly distinguishing from sibling cf_list_warp_devices. Adds HTTP method and endpoint for precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like cf_list_warp_devices. Implies single device retrieval but lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description must bear the burden. It discloses GET method and auto-pagination, which is useful. However, it omits authorization needs, rate limits, or data freshness; 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?
Extremely concise with two sentences, front-loaded with purpose and API reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks parameter explanations and usage guidelines. With 2 parameters and 0% schema coverage, the description is incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description does not explain any parameters. account_id and max_pages are not described; an agent cannot infer their meaning or usage from the tool definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists WARP-enrolled devices, and differentiates from sibling cf_get_warp_device by indicating plural listing vs singular retrieval. Also specifies the API endpoint and auto-pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 like cf_get_warp_device or other list tools. The description implies usage by stating it lists devices, but lacks context about prerequisites or 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, and the description does not disclose behavior beyond listing rules. It does not mention side effects, auth requirements, rate limits, or pagination. The reference to 'same shape' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that convey the essential purpose and differentiation. No redundant or irrelevant 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 simple list tool with one parameter and an output schema, the description is minimally adequate. It does not explain the return format or the significance of the phase, but the output schema likely covers the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no information about the only parameter, zone_id. The name and title are self-explanatory, but the description adds no extra meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list'), resource ('rate-limit rules'), and scope ('a zone'). It also distinguishes from a sibling tool ('Same shape as cf_list_custom_rules but targets a different phase'), providing strong 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is a 'Convenience' tool and contrasts it with cf_list_custom_rules by phase, implying when to use each. However, it lacks explicit when-not-to-use or alternative guidance beyond the sibling reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It specifies the resource and included configurations, but does not explicitly state it's read-only (though implied by GET), required authentication, or error handling. 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?
Two sentences: the first conveys purpose and output, the second gives the API endpoint. No unnecessary words 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?
The tool has an output schema, so return values are covered. The description is complete for a simple get-by-ID tool, but lacks information on permissions, error cases (e.g., not found), or required scopes. Adequate for the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description does not explain the meaning of account_id or app_id beyond their names. The context of Cloudflare Access is implied, but the description adds no explicit parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single Access app including session and CORS configuration, and provides the HTTP method and path. This distinguishes it from sibling 'cf_list_access_apps' which lists 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?
No explicit guidance on when to use this tool vs alternatives like listing apps first. The use case is implied (getting a known app by ID) but no direct comparison or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only metadata is returned and provides the HTTP method and endpoint. It does not cover authentication requirements, rate limits, or other behavioral aspects, but the key behavioral trait is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each conveying essential information: the action, the key limitation, the rationale, and the API call. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description correctly focuses on behavioral context. However, it omits details like pagination, filtering, or what 'metadata' includes, which would help an agent understand the full scope of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description only hints at account_id through the URL template, without explaining its origin or format. This is insufficient for an agent to confidently populate the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Access service tokens and explicitly notes it returns metadata only. This distinguishes it from any potential tool that might return secrets, providing a specific verb-resource pair.
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 explains the tool never returns the secret, implying it should be used only when metadata is needed. However, it lacks explicit comparison with sibling tools or guidance on when not to use it, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the API method (POST /graphql) and dataset, but does not explicitly state that the operation is read-only or what side effects exist. With no annotations, the description carries the full burden, and while it implies read-only ('Raw HTTP request rows'), it lacks explicit safety guarantees or behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the main purpose. However, it relies on an external reference (cf_query_firewall_events_raw) for parameter details, which could be improved by brief inline descriptions. Still, it is efficient and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema (7 parameters, 3 required) and no parameter descriptions. The description does not explain how to construct the filters, cursor, or verbose flag. While an output schema exists, the description references another tool for return shape, which may cause confusion. More context around pagination and filter syntax would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in the schema). The description does not compensate; it only says 'Args, returns: see cf_query_firewall_events_raw.' This does not provide any semantic meaning for the 7 parameters, leaving the agent to guess their formats and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Raw HTTP request rows over a time window' which clearly identifies the resource and action. It also distinguishes from other query tools by specifying the dataset (httpRequestsAdaptive) and use case (unsampled per-request drill-down). This sets it apart from sibling tools like cf_query_firewall_events_raw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this for unsampled per-request drill-down on traffic patterns (bot scores, cache statuses, origin response codes).' This tells the agent when to use this tool. It also references cf_query_firewall_events_raw for similar structure, implying the agent can consult that tool for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It specifies the HTTP method (GET) and that it uses a filter, which implies a read-only operation. However, it does not explicitly state safety (e.g., no side effects) or mention rate limits, pagination, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences: a clear purpose statement, parameter list with defaults, and the API endpoint. Every sentence adds value, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are documented elsewhere) and the tool is a simple list operation, the description covers the key aspects. However, it omits information about pagination (common for list tools) and whether additional filters are supported, which 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?
With 0% schema coverage, the description adds meaning for both parameters. For 'rule_type', it enumerates the valid values ('dns', 'network', 'http') and documents the default, going beyond the schema. For 'account_id', it merely repeats 'account ID', which adds little. Overall, it provides useful but not comprehensive 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 clearly states the action (list) and resource (Cloudflare Gateway rules) with specific subtypes (DNS, network, HTTP). It distinguishes from sibling tools which list other resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing gateway rules and provides parameter details, but it does not offer explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As a read-only listing tool, the description conveys non-destructive behavior and specifies the output normalization, but lacks details on error handling or 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?
Two sentences efficiently convey purpose, equivalent tool, and return shape without 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?
Given the single parameter and the presence of an output schema, the description adequately covers the tool's function and result shape, though error handling is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameters, and the description adds no explanation for the required zone_id parameter, leaving its meaning and source unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists custom WAF rules for a zone, distinguishing it from the similar sibling cf_get_entrypoint_ruleset by noting the normalized return shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes it as a convenience equivalent to cf_get_entrypoint_ruleset with a normalized output, guiding the agent to choose this when a standardized return shape is desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses auto-pagination, the envelope structure, and the compact projection to avoid token limits. With no annotations, this provides adequate transparency about the tool's behavior 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 well-structured, starting with the main purpose, then endpoint, return structure, and important note. It is not overly verbose, but the parameter section could be more 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?
Given the tool has an output schema and only two parameters (none required), the description provides sufficient context: the envelope, compact projection, and guidance on avoiding token limits. It could mention max_pages but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly explains account_id via the API endpoint. The max_pages parameter is not explained at all, leaving the agent without critical usage details for pagination control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'List Cloudflare Access applications configured at the account' with a specific verb and resource. It distinguishes from the sibling tool cf_get_access_app by noting that this tool returns a compact projection and that the other should be used for full app config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to list all applications, and it explicitly suggests using cf_get_access_app for full configuration details. However, it does not explicitly state when not to use this tool or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 description carries full burden. It discloses the API call (POST /graphql), dataset, pagination, and aggregate behavior but does not explicitly state that the operation is read-only or mention any rate limits, authentication, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (about 10 lines), well-structured with a clear purpose line, API call, parameter list, behavioral note, and return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the presence of an output schema, the description covers input params, aggregate caveats, and return envelope. It could mention that zone_id must be obtained from another tool (e.g., cf_list_zones) or clarify error handling, but overall it is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description fully explains all 7 parameters: zone_id, since/until (ISO-8601), group_by (valid dimensions), filters (with example), limit (range 1-500), and cursor (pagination). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Group' and resource 'HTTP request analytics', and specifies grouping over a time window. It distinguishes itself from sibling cf_query_http_requests_raw by focusing on grouped analytics.
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?
Description does not explicitly state when to use this tool versus alternatives like cf_query_http_requests_raw. Usage is implied but lacks clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It describes the operation as a GET call returning the full rule definition, and adds context about scope and relationship to zone deployment. It does not detail side effects, permissions, or error cases, but the behavior is straightforward for a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, front-loading the purpose. Every sentence adds value, including the API call line. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It provides sufficient context: the tool's role as a bridge, its use for FP triage, and its relationship to zone-level deployment. This is complete for a detail-lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. The description mentions 'ruleset_id' and 'rule_id' but omits 'account_id' explicitly, though implied by 'account-scoped'. It lacks individual parameter explanations, which is insufficient given the 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Look up details of a specific managed-ruleset rule' with a specific verb and resource. It distinguishes from sibling tools by noting the account scope and its role as a bridge for FP triage, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for FP triage on managed-rule hits) and mentions the API endpoint. It does not explicitly list alternatives or when not to use, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that allowlist enforcement runs after API call, wasting a CF quota even on disallowed zones. Also specifies the API endpoint and return summary. Annotations are absent so description carries full burden; this is well done.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: three lines cover purpose, parameters, API call, and behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately summarizes return data without exhaustive field listing. Includes allowlist behavior and quota cost, which is important context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds '32-char Cloudflare zone ID' for the zone_id parameter, providing format and context beyond the schema's 'Zone Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get full details for one zone' and lists specific contents (plan, name servers, settings summary, status). Distinguishes from sibling cf_list_zones (list all) and cf_resolve_zone (resolve name to ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., cf_list_zones for enumeration, cf_resolve_zone for name lookup). Usage is implied but not 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 provided. Description discloses the two GET endpoints and conditional behavior based on app_id, but lacks details on authentication, rate limits, pagination, or error handling. Adds moderate value beyond 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?
Description is concise and well-structured: purpose in first line, args explained, then underlying API calls. Every sentence is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, 1 required, and an output schema (existing), the description covers core logic and scope differentiation. It does not mention pagination or sorting, but the output schema likely covers return formats. Fairly complete for a list tool.
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?
Input schema has no descriptions (0% coverage), so description compensates by explaining account_id as 'account ID' and app_id with usage context (when provided vs omitted). Adds significant meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists Access policies, with a specific verb and resource. It distinguishes between account-wide and app-scoped policies, differentiating it from siblings like cf_list_access_apps or cf_get_access_app.
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?
Description explains when to provide app_id vs omit it for account-level policies. It provides clear context but does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses HTTP method (GET), path, auto-pagination (up to 5 pages), and response structure (envelope with data containing specific fields). No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a one-line return description, no fluff. Front-loaded with 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?
Simple list tool with output schema present; description covers pagination and return fields. Adequate.
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?
No parameters – schema coverage is 100% by default. Description adds no parameter info, but baseline 4 for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List Cloudflare accounts the configured API token can see' – a specific verb and resource. Distinguished from siblings like cf_list_zones or cf_list_rulesets.
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?
Implies usage for listing accounts, but no explicit when-to-use or when-not-to-use. Siblings are different resources, so context is clear but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions the HTTP method (GET) and return envelope structure, but does not cover safety, authentication needs, or rate limits. Adequate but not exhaustive.
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 well-structured with bullet-pointed args, API call, and returns. It is relatively concise with only essential information, though could slightly trim the return envelope detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (two parameters, no nested objects) and presence of an output schema, the description covers all necessary information: purpose, arguments, HTTP call, and return data structure. It is complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's explanation of 'scope' as 'zone' or 'account' and 'scope_id' as a Cloudflare ID adds significant meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all rulesets visible at the given scope' with a specific verb (list) and resource (rulesets), and distinguishes from sibling tools like cf_get_ruleset (specific ruleset) and cf_list_managed_rulesets.
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?
While not explicitly stating when not to use, the description gives clear context: listing all rulesets at a given scope. Sibling tools have different focuses (get single, filter managed), so differentiation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It describes the HTTP GET call, return envelope with data containing ordered rules, and implies read-only safety. However, it does not explicitly mention authentication requirements, rate limits, or confirm it is non-destructive, which would strengthen 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 well-structured with Args, Calls, and Returns sections. Every sentence adds value, from the upfront purpose to the concluding return format. It is concise yet thorough, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description explains the return envelope with 'data' and 'rules[]', adding context. It covers both parameters comprehensively and provides usage guidance. Minor omission: no mention of error handling or prerequisites, but overall complete for a simple GET endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds significant meaning: zone_id is '32-char Cloudflare zone ID' and phase includes common values like 'http_request_firewall_custom'. This goes well beyond the schema's simple titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the ordered list of rules at a zone's entrypoint for a phase, distinguishing it from sibling tools like cf_get_ruleset or cf_list_rulesets by explaining the 'entrypoint' concept and its practical use for WAF/rate-limit investigations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool for most WAF/rate-limit investigations, noting it shows executing rules. It lists common phase values but does not explicitly state when not to use it or mention alternatives, though context from sibling tools provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the HTTP method (GET) and return content (configuration + last delivery status), which implies a read operation. However, it does not explicitly state that it is read-only or discuss prerequisites, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, followed by a clear Arg list and an HTTP path. No unnecessary words, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations but the presence of an output schema, the description is fairly complete. It covers the parameters, the HTTP path, and the return values (config + delivery status). It lacks explicit mention that this is a read operation, but the GET method strongly implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed explanations for all three parameters: scope values ('zone' or 'account'), scope_id matching the scope, and job_id format (integer-as-string). This adds significant meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'Get a single Logpush job's configuration + last delivery status.' The verb 'Get' and resource 'Logpush job' are specific, and it distinguishes itself from sibling cf_list_logpush_jobs by indicating it retrieves a single job.
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 implicitly indicates use for a specific job via job_id, but does not explicitly state when to use this tool versus the listing sibling cf_list_logpush_jobs. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details the API call (GET /zones?name=...&match=all), return envelope structure, and three specific error types (zone_not_allowed, not_found, validation). Does not explicitly state read-only nature or idempotency.
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?
Concise docstring-style structure with Args, Calls, Returns, Errors sections. Front-loaded purpose. Could be slightly more compact but is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and minimal schema, the description covers input, API call, return structure, and error scenarios comprehensively. Includes disambiguation hint for rare multiple matches, fully meeting the tool's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description fully documents the sole parameter zone_name with an example ('example.com') and behavior (trailing dots stripped), providing essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Look up a zone ID by its name', specifying the DNS name convention and trailing dot stripping. Distinguishes from sibling tools like cf_get_zone and cf_list_zones by focusing on resolution by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when a zone name is given, and notes error handling for multiple matches (disambiguation needed). However, lacks explicit guidance on when to use this vs alternatives like cf_get_zone or cf_list_zones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP method (GET), the API endpoint pattern, and the return format ('envelope with `data` = full ruleset dict including `rules[]`'). This provides sufficient behavioral transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clear structure: one-line summary, Args block, call pattern, and return format. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers all necessary information for a simple GET operation: purpose, parameters, endpoint, and return type. The presence of an output schema is acknowledged, but the description already explains the return format sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning: scope is 'zone' or 'account', scope_id is a matching CF ID, ruleset_id is a 32-char ID. This significantly clarifies parameter semantics beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Fetch a single ruleset including all its rules,' clearly specifying the verb (fetch), resource (ruleset), and scope (single). This distinguishes it from siblings like cf_list_rulesets (list multiple) and cf_get_rule (single rule).
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 lists required arguments with brief explanations (scope type, scope_id, ruleset_id), implying usage context. It does not explicitly state when to use this over alternatives, but the sibling names make it clear that this is for fetching a single ruleset, not listing or getting a rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool uses a GET request (safe, non-destructive), specifies that destination_conf is redacted of secrets by Cloudflare, and details the response envelope structure. This conveys essential behavioral traits without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with a clear structure: purpose sentence, args list, API call format, and return envelope with job fields. Every sentence adds value, and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate tool complexity (two parameters, list operation), the description fully covers purpose, parameter semantics, API endpoint, and response structure. The presence of an output schema (though not provided in the input) is supplemented by a detailed return description, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions), but the description compensates fully by defining each parameter. It explains that scope must be 'zone' or 'account' and that scope_id is the corresponding Cloudflare ID, adding critical semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List configured Logpush jobs at a given scope,' which clearly states the action (list) and the resource (Logpush jobs). It distinguishes itself from sibling tools like cf_get_logpush_job, which retrieves a single job, by emphasizing the listing aspect.
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 defines the required parameters (scope and scope_id) and their meanings, aiding correct usage. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., cf_get_logpush_job), and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses internal behavior: queries firewallEventsAdaptiveGroups with a pre-applied 'botManagement' filter, explains why (no standalone bot dataset), and specifies allowed group_by dimensions. This is transparent beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 6 sentences, well-structured with the main purpose first followed by technical details and cross-references. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides important context about internal data source and dataset limitations, but lacks practical details on parameter usage (e.g., date formats, filter structure). An output schema exists, so return values are less needed, but still, completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only adds meaning for 'group_by' (allowed dimensions are firewall set) and indirectly mentions limit and cursor are pagination parameters. However, it fails to clarify formats for 'since', 'until', or usage of 'filters', 'zone_id', etc. The description does not sufficiently compensate for lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool groups bot-management events by dimensions over a time window. It distinguishes itself from sibling tools like cf_query_http_requests_grouped by specifying that bot score dimensions are not included, making its purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. the alternative cf_query_http_requests_grouped for bot score distribution. Also explains that the tool internally queries a filtered dataset, setting clear expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool runs two GraphQL queries, groups by fields, and returns a structured envelope. It doesn't mention auth or rate limits, but the behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary then details, but includes some jargon ('httpRequestsAdaptiveGroups') that could be simplified. It is concise but informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, output schema exists), the description is complete. It explains the operation, parameter semantics, and return structure, enabling an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which only has titles. It explains each parameter (zone_id, match_path, attack_since/until, baseline_lookback_days) and provides context for usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare attack-window traffic vs a prior baseline window on the same path.' It uses a specific verb ('Compare') and resource ('traffic vs baseline') and distinguishes from siblings, which are primarily list/query 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 explains the tool is suitable for the ATK archetype workflow and mentions the underlying queries. It does not explicitly state when not to use it, but the distinction from siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that the tool constructs a URL, falls back to an environment variable for account_id, validates view_type, returns an envelope, and errors on validation. No destructive actions are implied.
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 well-structured with bullet points and clear separation of args, returns, and errors. It is somewhat lengthy but every sentence adds value; could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no structured output schema, the description is complete. It covers all parameters, return envelope, error conditions, and usage details. An agent can correctly invoke this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter: view_type with a list of valid values, account_id with env fallback, zone for zone-scoped views, and filters with an example. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Construct' and the resource 'deep link into the Cloudflare dashboard for a given view.' It distinguishes this utility tool from sibling query/manage tools, which are all about retrieving or modifying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose and parameter usage, guiding when to use this tool (to build a dashboard URL). It does not explicitly state when not to use or provide alternatives, but the context from sibling tools makes it clear. The instructions on required vs optional parameters are helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains the underlying API call, the projection behavior, and an error case (not_found when rule ID not in ruleset). It does not mention auth or rate limits, but the behavioral description is sufficient 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 concise and well-structured: a one-line summary, a sentence on motivation, then Args, call syntax, and errors. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 sibling tools dealing with rulesets/rules), the description covers purpose, usage, parameters, behavior, and errors. An output schema exists, so return values need not be explained. The description is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter (scope, scope_id, ruleset_id, rule_id) and providing context for scope values. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's a convenience wrapper for looking up a single rule by ID, specifically for resolving unknown rule IDs from firewall events. This is a specific verb+resource that clearly distinguishes from siblings like cf_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool ('what does rule X do' resolution) and implies it's an alternative to fetching the full ruleset. However, it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral context: it describes the API call, clamping of limit, and return envelope. It does not mention authentication or rate limits but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, then organized into Calls, Args, and Returns sections. No redundant sentences, every line 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?
The description covers the key aspects: API call, parameters, return envelope with pagination. It references an external constant (_FIREWALL_GROUP_DIMENSIONS) without definition, which is a minor gap. Output schema exists, but description provides sufficient return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds detailed semantics for all 7 parameters, including format hints, allowed values (e.g., group_by dimensions), operators for filters, defaults, and clamping 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 clearly states the tool groups firewall events by chosen dimensions over a time window, specifying the dataset and API endpoint. This distinguishes it from siblings like cf_query_firewall_events_raw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose and parameters, and sibling names imply when to use raw vs grouped queries. However, it does not explicitly state when not to use this tool or compare alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: limit clamping, verbose mode impact on response size, pagination via cursor, and the ~20K-token ceiling. It does not cover authentication or side effects but provides sufficient 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 well-structured with a purpose summary, then sections for calls, arguments, and return. It is concise and front-loads essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, output schema presence, and no nested objects, the description covers all input semantics, return envelope, and critical constraints like limit clamping and verbose ceiling. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage; the description adds full meaning for all 7 parameters: zone_id, since/until (ISO-8601), filters, limit (clamping+default), cursor, verbose (fields+ceiling). This significantly exceeds schema 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 clearly states the tool returns raw firewall events, one row per event, over a time window. It distinguishes itself from siblings like grouped queries.
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 indicates usage for raw events over a time window but does not explicitly state when to use this tool versus alternatives like grouped queries. However, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the HTTP GET method, URL pattern, and details the full return structure with all fields and types (e.g., bool, string). This provides excellent transparency into the tool's read-only behavior and output.
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 well-structured with clear sections for args, HTTP call, and returns. It's slightly lengthy due to the full list of return fields, but every sentence provides value. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and the presence of an output schema (though not shown), the description provides the complete return structure. It covers all necessary details for an agent to correctly invoke the tool and understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter zone_id is described as '32-char Cloudflare zone ID', adding meaningful context beyond the schema's type 'string'. With 0% schema description coverage, the description fully compensates by specifying the format and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current Bot Management configuration for a zone, with a specific verb 'Get' and resource 'Bot Management configuration'. It distinguishes itself from siblings like cf_list_super_bot_fight_mode_config, which lists configs, by focusing on a single zone's full config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a specific zone's bot management config, but lacks explicit guidance on when not to use it or direct comparison to sibling tools like cf_list_super_bot_fight_mode_config. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully describes the behavior (reuses endpoint, projects fields) and details the return structure. It implies a read operation but could explicitly state safety. The clarity on output fields adds 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 concise, with a clear purpose statement followed by structured Args and Returns. Every sentence adds value, and it is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count and the description's coverage of the parameter and return values (matching output schema), the description is complete. It leaves no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section adds meaning: '32-char Cloudflare zone ID' provides context beyond the type 'string'. For one parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets the Super Bot Fight Mode configuration projection and distinguishes it from cf_get_bot_management_config by noting it projects only SBFM-relevant fields. The verb 'Get' is specific, and the resource is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'convenient when the agent is specifically investigating bot-blocking behavior' and contrasts with cf_get_bot_management_config. This clearly indicates when to use this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: name_pattern is a client-side post-filter due to API limitations, max_pages default and auto-pagination behavior, and the compact projection that drops fields to avoid token limits. This exceeds what annotations would normally provide.
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 well-structured with clear sections (Args, Calls, Returns, projection note). It is comprehensive but slightly verbose; still, every sentence adds value. It front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still provides essential context: return envelope structure, compact projection rationale, and reference to cf_get_zone for full data. This completes the picture for the agent without over-specifying.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema), but the description entirely compensates. It explains account_id defaults to an env var, name_pattern is a client-side glob, and max_pages is a pagination cap. This adds critical meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List Cloudflare zones (domains) the token can see.' This is a specific verb and resource, clearly distinguishing it from sibling tools like cf_list_access_apps or cf_list_accounts. The tool's scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose of each parameter (account_id filter, name_pattern with glob limitation, max_pages pagination cap) and explicitly directs users to cf_get_zone for full config. However, it does not explicitly state when not to use this tool vs. alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is 'best-effort', catches specific issues (balanced-paren violations, unknown operators), and notes that a valid result does not guarantee Cloudflare acceptance. It also explains the envelope format even when validation fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a main sentence, a caveat, then structured Args/Returns sections. Every sentence adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema is referenced, the description covers the behavior, parameter meaning, result format, and limitations. It is complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains the 'expression' parameter with an example: 'e.g. `(http.request.uri.path contains "/admin" and ip.src in {1.2.3.4 5.6.7.8})`'. This adds meaning beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Best-effort syntactic check of a Cloudflare Wirefilter (Rules language) expression.' It specifies the resource (Wirefilter expression) and the action (validate), distinguishing it from sibling tools which are for other Cloudflare operations.
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 notes it is 'NOT a full grammar' and that a valid response does not guarantee runtime acceptance, implying the tool is for preliminary checks. It does not explicitly state when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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