mcp-cloudflare-dns

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource and action: zones, DNS records, zone settings, cache, and page rules are clearly separated. The DNS record tools follow a standard CRUD split with no ambiguity between get/list/create/update/delete.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_, get_, create_, update_, delete_, purge_). This makes the toolset predictable and easy to reason about.
Tool Count5/5
With 10 tools, the server is well-scoped for its purpose. Each tool covers a meaningful operation without redundancy or excessive granularity.
Completeness4/5
DNS record management is fully covered with create, read, update, and delete operations. Zone lookup and settings read are present, but zone settings cannot be updated and page rules only support listing, leaving minor workflow gaps.
Average 3.4/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create a new DNS record.' It does not mention side effects like DNS propagation or duplicate conflicts, permission requirements, or the consequences of creation. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and free of filler, but it is under-specified; it does not front-load any caveats or context. It is appropriately sized for a trivial tool, yet it borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters with nuances such as TTL auto only when proxied, priority required for MX, and proxied only for certain record types, and no annotations, the description omits all operational context. An agent has to infer usage from the schema and sibling names, leaving the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the 8 parameters already has a descriptive explanation. The description adds no parameter-level information, but the schema fully compensates, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new DNS record.' restates the tool name and title almost verbatim, adding no additional scope or qualifiers. It states the operation but provides no differentiation from sibling tools beyond the verb 'create', which is already inherent in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over update_dns_record or delete_dns_record, nor any prerequisites such as the need for an existing zone. The description relies entirely on the tool name to convey usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior — a critical concern for a list operation — nor what the default result set is when no filters are applied. It only implies a read operation, leaving the agent to guess at list semantics.
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 8-word sentence has zero waste and is perfectly front-loaded. It is slightly under-specified, but that is a completeness issue rather than a conciseness defect; the descriptor itself is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema covers the return shape, but for a list operation with three parameters and no annotations, the description fails to explain pagination, default filtering behavior, or when listing differs from fetching a single record. An agent cannot fully predict the tool's behavior from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters (zone_id, name, record_type) with type details and an example for name. The description adds nothing about the filter parameters beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('DNS records') scoped to a zone. It is clearly distinct from singular operations like get_dns_record and from get_zone_settings, but it does not explicitly differentiate itself from siblings, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the related get_dns_record (single record) or update_dns_record siblings. There are no stated exclusions, prerequisites, or use-case scenarios — an agent must infer when listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It names a destructive operation ('Purge') but does not explain that purge_everything overrides urls, destroys the entire zone cache, or requires CF_ALLOW_DESTRUCTIVE=true. The schema hints at these, but the description itself adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with zero wasted words. The purpose is front-loaded and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has meaningful branching behavior (urls vs purge_everything, with an override and a safety requirement). The description alone doesn't help an agent choose between modes or understand the destructive scope. An output schema exists, but the description is too sparse to be contextually complete for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (zone_id, urls, purge_everything) documented inline. The description adds no parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Purge' and the resource 'Cloudflare cache for a zone.' This clearly distinguishes the tool from zone/DNS/page-rule siblings, but it doesn't capture the two purge modes (specific URLs vs entire zone), so it's clear but slightly generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 purge specific URLs versus the entire zone, nor does it mention alternatives or exclusions. Given there are no sibling cache tools, the main usage decision is between the two modes, and no hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'list', which implies a read-only operation, but it does not disclose pagination, ordering, default filter behavior, permissions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. It says exactly what the tool does and no more, which is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema fully documents both parameters, and an output schema exists, so the lack of return-value detail is not a gap. However, the description omits any usage context or exclusion relative to sibling tools and gives no behavioral detail beyond the list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no semantic detail beyond 'for a zone,' which maps trivially to zone_id. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('list'), a specific resource ('page rules'), and a clear scope ('for a zone'). This distinguishes it from sibling tools like list_dns_records and list_zones without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives no guidance on when to use this tool versus alternatives like list_dns_records or get_zone_settings. There are no explicit conditions, exclusions, or sibling comparisons, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly signals a non-mutating, account-wide list operation, which is useful. However, it does not mention pagination, rate limits, authentication, or what happens when many zones exist, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence delivers the core verb, resource, and scope with no filler or redundancy. The description is appropriately sized for a tool with one optional parameter and a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one well-described optional parameter and an output schema, the description supplies the essential type and scope. It lacks pagination context or sibling-routing guidance, but those are minor gaps for a basic read-only list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter name_filter is fully documented in the input schema with its own description, so schema coverage is 100%. The tool description adds nothing about the filter, but the schema already provides the necessary meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('Cloudflare zones'), and an account-level scope ('on this account'). 'All' implies a collection operation that loosely distinguishes it from get_zone, but it does not explicitly name or contrast any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus list_dns_records, get_zone, or get_zone_settings. There are no exclusions, conditions, or references to alternatives. The phrase 'when you need all zones' is implied but essentially tautological.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 reveals a key behavioral trait: partial update semantics ('Only the fields you provide will be changed'). With no annotations, this is valuable. But it doesn't disclose other important behaviors like whether updating content triggers validation, what happens to unspecified fields, or any side effects (e.g., propagation, DNS resolution impact).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The core action is stated first, and the partial-update behavior is front-loaded as the second sentence. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return format is covered. However, with no annotations, the description doesn't cover mutation implications, auth needs, or validation behavior. For an update tool, knowing that only provided fields change is helpful, but an agent might want to know if updates are idempotent or if certain fields (like content) have format restrictions beyond schema types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the partial-update semantic, which is meaningful but not parameter-specific. It doesn't clarify nuances like the '1 = auto' TTL special value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing DNS record') and the resource (DNS record). It's distinct from siblings like create_dns_record and delete_dns_record. However, it doesn't explicitly differentiate itself from list_dns_records or get_dns_record, though the verb 'update' makes it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Only the fields you provide will be changed' gives useful usage context, implying partial updates. However, it doesn't explicitly state when to use this vs alternatives, prerequisites (like needing zone_id and record_id), or when not to use it (e.g., for creating or deleting records).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The verb 'Get' makes clear this is a read operation and not destructive, but no additional behavior is disclosed, such as whether a nonexistent record returns an error or whether permissions are needed. For a simple getter this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or repetition. Every word earns its place, and the key selection criteria are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with an output schema already present, the description covers the essential facts: what to retrieve and the identifiers required. It does not need to explain return values because the output schema exists. It could have noted a sibling alternative or error behavior, but the operation is simple enough that the description does not leave a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for either parameter and schema description coverage is 0%, so the description must compensate. It does so minimally by relating the parameters to their roles: zone_id and record_id together identify the record. This adds some meaning beyond the bare parameter names, though the names were already fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('specific DNS record'), and identifies the two identifiers that select the record. It does not explicitly distinguish itself from list_dns_records, but the word 'specific' conveys that this is a single-record fetch, which is enough for an agent to separate it from list/create/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent already has a zone ID and record ID and wants one DNS record. It does not explicitly say when not to use it or mention alternatives like list_dns_records, but the 'specific' qualifier and the required IDs make the intended context reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of conveying behavior. The verb 'Get' clearly implies a read-only operation, and 'by ID' scopes the request. However, it does not state explicit behavioral details like non-mutation, error behavior, or authentication needs, though the output schema covers return structure. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loads the key purpose, and contains no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and an output schema, the description provides enough context for an agent to understand what the tool does and how to invoke it. It could mention when to use list_zones instead, but the tool's simplicity and the provided schema make it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify that the single parameter is the zone's ID and ties it to 'a specific Cloudflare zone,' which adds minimal meaningful context. It does not explain the expected format, how to obtain the ID, or edge cases, leaving it barely 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 states a clear verb ('Get'), a specific resource ('a specific Cloudflare zone'), and the key qualifier 'by ID,' which distinguishes it from list_zones and get_zone_settings. An agent can immediately understand what this tool does and how it differs from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you have a zone ID and need details for a single zone. However, it does not explicitly contrast with list_zones or explain when to prefer one over the other, leaving the routing decision mostly to inference.
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?
There are no annotations, so the description carries the behavioral disclosure burden. It explicitly reveals that the operation is gated behind CF_ALLOW_DESTRUCTIVE=true, signaling both the destructive nature and the likely failure mode if the flag is unset. It does not detail irreversibility effects, but the tool is a straightforward delete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the action stated first and the critical safety prerequisite stated immediately after. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool with an output schema present, the description covers the essential action and the important guardrail flag. It could mention recovery or side effects, but the flag plus clear verb makes it sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, and the schema already provides clear descriptions for zone_id and record_id. The description adds no additional parameter-specific semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete a DNS record.' This directly distinguishes it from sibling tools like create_dns_record, update_dns_record, and list_dns_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: 'Requires CF_ALLOW_DESTRUCTIVE=true,' which is useful operational guidance. However, it does not explicitly explain when to choose this over alternatives or mention any exclusion conditions beyond the environment flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does this by naming the returned setting types (SSL mode, security level, minification, always-https, brotli) and the 'Get' verb implies a non-mutating operation. It does not discuss permissions or error behavior, but this is a simple read-only getter.
Agents need to know what a tool does to the world before 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 the action and resource front-loaded. The enumeration of return values is useful and there is no filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter, the description is complete: it explains what the tool returns, an output schema covers the exact return structure, and the parameter is straightforward. Nothing material is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description needs to add meaning for the zone_id parameter, but it does not. The parameter name is self-explanatory, yet the description provides no detail about how zone_id should be supplied or what identifying a zone entails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('security and performance settings for a zone') and enumerates representative settings. This clearly distinguishes it from siblings like get_dns_record, purge_cache, and even get_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a zone's security/performance settings, but it gives no explicit guidance on when to choose it over get_zone or other siblings. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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/apexradius/mcp-cloudflare-dns'

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