porkbun-mcp

by major

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.1.2
Disambiguation4/5
Most tools are clearly separated by resource and action, but the pairs dns_get vs dns_get_by_name_type and dns_edit vs dns_edit_by_name_type could be confused if descriptions aren't read carefully. Overall, each tool has a distinct purpose, with only a few closely related variants.
Naming Consistency4/5
Tool names follow a consistent resource_verb pattern, e.g., dns_list, dns_create, domains_update_nameservers. However, there are minor inconsistencies: 'add' vs 'create', 'retrieve' vs 'get', and pluralization differences like url_forwards vs url_forward, which slightly reduce strict uniformity.
Tool Count3/5
With 25 tools, this is at the high end of the acceptable range. The count is justified by the broad scope (DNS, domains, DNSSEC, SSL, pricing), but it feels heavy and could be streamlined by consolidating some by-ID and by-name-type variants.
Completeness4/5
The tool set covers core DNS CRUD, domain management (nameservers, URL forwards, glue records), DNSSEC, SSL retrieval, and pricing. Minor gaps exist, such as domain purchase or transfer operations, but the tool surface is quite complete for typical domain management workflows.
Average 3.7/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on April 10, 2026
- 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?
The description only says 'Create a DNSSEC record,' which essentially restates the tool name. It adds no behavioral context beyond what the idempotentHint=false annotation already implies. No information about effects, required permissions, or potential consequences is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to state the purpose. It wastes no words, though it is somewhat under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and five required parameters, the description provides minimal context. It does not explain return values, prerequisites, how this fits into DNSSEC management, or any idempotency details beyond the annotation. The tool is underspecified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no additional meaning beyond what the schema already provides, which earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a DNSSEC record, which is a specific verb+resource. It distinguishes itself from sibling tools like dns_create (regular DNS records) and dnssec_delete (deleting DNSSEC records), though it could be more specific about what type of DNSSEC record (e.g., DS record).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when DNSSEC creation is appropriate, or how it differs from dns_create. The description offers no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already communicates the destructive nature, but the description adds no additional behavioral context. It does not mention irreversibility, DNS impact, or permission requirements. With annotations present, the bar is lower, but the description still fails to disclose any non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, highly concise and front-loaded. It contains no irrelevant information and directly states the action. Every word earns its place, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete schema and destructive annotation, the description is adequate for a simple delete operation. However, it lacks usage context, does not explain what a glue record is, and omits the consequences of deletion. The presence of an output schema would cover return values, but the description still leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (domain and subdomain) with descriptions at 100% coverage. The tool description itself does not elaborate on these parameters, but the schema provides complete meaning. A baseline score of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' with a clear resource 'glue record', distinguishing it from sibling tools like domains_create_glue_record and domains_update_glue_record. However, it closely mirrors the tool name without adding extra context, so it lacks the richness of a top-tier purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it list prerequisites or exclusions. While the existence of sibling glue record tools implies context, the description itself offers no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is idempotentHint: false. The description adds no behavioral context beyond this, such as side effects, permission requirements, or behavior when a forwarding rule already exists. It does not contradict the annotation, but also adds no meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler words. It is front-loaded with the action and resource, making it maximally concise for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and an output schema, the description is too sparse to provide complete context. It lacks usage guidelines, behavioral side effects, and how this operation interacts with existing forwarding rules. The schema compensates for parameters but not for overall operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, but the schema already carries the semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' and resource 'URL forwarding rule', clearly distinguishing it from sibling tools like domains_get_url_forwards and domains_delete_url_forward. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, nor any prerequisites, exclusions, or context. The description is solely a statement of action without any situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is idempotentHint: true, which is not contradicted by the description. However, the description adds no behavioral context beyond the annotation, such as whether the operation replaces all existing nameservers or merges with the current list, any validation rules, or propagation delays. The agent is left guessing about the effect of the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler text. It immediately communicates the core action and resource, demonstrating flawless conciseness for a tool with this simple signature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a fully documented schema and an output schema, the description lacks essential context for a mutation tool: it does not clarify whether the provided nameservers replace the existing set or are appended, nor does it mention any side effects or requirements. Given that an agent may need to decide between this and related tools like domains_get_nameservers, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (domain and nameservers) with 100% coverage. The description's phrase 'for a domain' adds minimal extra meaning, so the baseline of 3 applies as the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('nameservers for a domain'), immediately distinguishing it from read-only siblings like domains_get_nameservers and other mutation tools like dns_edit. This is a precise and unambiguous statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dns_edit or domains_add_url_forward. It lacks any mention of prerequisites, exclusions, or a preferred workflow, leaving the agent to infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds no additional behavioral context beyond the filtering semantics already evident from the name and schema. It does not describe pagination, return format, or edge cases, but the output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core function without extraneous words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain when to use this tool over dns_get or how it handles wildcard/null subdomains, which are important for correct invocation. The output schema exists, but the description lacks operational context needed for an agent to fully understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 'domain', 'subdomain', and 'record_type'. The description mentions subdomain and type but does not add meaning beyond the schema; it also omits the required domain parameter, so no extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets DNS records and specifies filters by subdomain and type. It distinguishes from siblings like dns_get by indicating a more targeted query, though it omits the required 'domain' parameter from the description, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus sibling tools like dns_get or dns_list. No alternatives, exclusions, or prerequisites are mentioned; usage context is only implied by the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action 'Delete' and adds no behavioral context beyond the destructiveHint annotation. It does not disclose irreversibility, error handling on missing records, or any side effects, so it fails to enrich the agent's understanding beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. Every word contributes to stating the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description, combined with full schema coverage and an output schema, is minimally adequate. However, it lacks usage context and behavioral detail, leaving some gaps in completeness for a fully informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (domain, key_tag) with 100% coverage, so the description adds no additional meaning. This baseline score is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the resource as 'DNSSEC record', clearly distinguishing it from DNS record deletion (dns_delete) and other DNSSEC operations like dnssec_create or dnssec_list. It accurately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites, exclusions, or context for selection mentioned. The description only states the action, leaving the agent without decision-support for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already indicates the destructive nature, but the description adds no additional behavioral context beyond the action itself. It does not mention irreversibility, permissions, or effects of deleting a record, so it fails to add value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It efficiently conveys the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool with an output schema and destructive annotation, the description is mostly sufficient. However, it could have noted the distinction from dns_delete_by_name_type or mentioned the domain scoping, so it falls slightly short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension 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 the 'domain' and 'record_id' parameters. The description's 'by ID' phrase aligns with 'record_id' but does not add substantive meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a DNS record by ID' uses a specific verb and resource, and the 'by ID' qualifier distinguishes it from the sibling dns_delete_by_name_type. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like dns_delete_by_name_type. The description gives no context for choosing this method over others, despite the sibling list highlighting a similar alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate idempotentHint=true, which the description does not contradict. However, the description adds minimal behavioral context beyond what is obvious: it does not mention how missing records are handled, whether only provided fields are updated, or any side effects. For a bulk mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and quickly conveys the tool's core purpose. However, it is perhaps too terse for a tool with 7 parameters, but conciseness itself is not penalized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 complexity (7 params, 3 required) and availability of output schema and annotations, the description provides the essential scope but leaves ambiguous behavior such as exact matching vs wildcard, partial update semantics, and error cases. It is adequate but lacks critical details for a bulk edit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented. The tool description adds no parameter-specific meaning beyond restating 'subdomain and type' as matching criteria, which is already captured in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit') and resource ('DNS records') with a specific scope ('matching subdomain and type'). It distinguishes from sibling tools like dns_get_by_name_type (read-only) and dns_edit (likely single-record edit) by explicitly indicating it operates on all matching 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?
The description implies bulk editing based on the phrase 'all DNS records matching subdomain and type,' but it does not explicitly state when to use this tool vs alternatives like dns_edit or dns_delete_by_name_type. No exclusions or alternative recommendations are provided, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose potential edge cases (e.g., unknown domain handling), rate limits, authentication requirements, or any other operational details. The annotation already covers the read-only nature, so the description provides no additional value here.
Agents need to know what a tool does to the world before calling it. Descriptions 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: 'Get nameservers for a domain.' No extraneous words, and it directly states the action and target. This is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, readOnlyHint, and an output schema, the description is largely complete. It clearly states the purpose, and return values are covered by the output schema. Minor missing context includes error behavior, but not critical for the basic 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 schema fully documents the sole parameter 'domain' with an example format, achieving 100% coverage. The tool description simply says 'for a domain' which adds no new meaning beyond the schema. Baseline of 3 is appropriate since schema handles 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 'Get nameservers for a domain' uses a specific verb and resource, clearly indicating this is a read operation to retrieve nameserver information. It distinguishes itself from sibling tools like 'domains_update_nameservers' (write operation) and 'dns_get' (DNS records), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, expected outcomes, or exclusion scenarios. The intended usage must be inferred entirely from the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the idempotentHint annotation. It does not mention side effects, whether it overwrites existing records, error handling, or any required permissions. Since the annotation already covers idempotency, the description adds no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose. It is front-loaded and contains no unnecessary words, making it 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?
For a 7-parameter edit tool with an output schema, the description is extremely brief. It lacks context about how the edit interacts with record_type, optional fields, or the alternative edit tool. While the schema and output schema cover some ground, the description does not provide enough usage context to fully specify behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters individually described. The description's 'by ID' clarifies that record_id is the identifier, but this is already evident from the schema. It adds no meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit') and resource ('DNS record'), and specifies the identifier method ('by ID'). This distinguishes it from the sibling tool dns_edit_by_name_type, which edits by name/type instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the tool is for editing when you have a record ID, but it does not explicitly state when to use it over alternatives like dns_edit_by_name_type or mention any prerequisites. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds no additional behavioral context beyond what the schema provides. It does not mention error handling, the necessity of a domain context beyond the schema's required fields, or response characteristics. The description is essentially redundant with the schema, offering minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant language. 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 an output schema, full schema coverage, and read-only annotations, the description is adequate. It does not explain return values, but the output schema covers that. The lack of explicit alternative guidance is a minor gap, but overall completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both domain and record_id. The description's phrase 'by ID' reinforces the role of record_id but adds no new meaning beyond the schema. It meets the baseline for tools with high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a specific DNS record by ID.' The verb 'Get' and resource 'DNS record' are specific, and the qualifier 'by ID' distinguishes it from sibling tools like dns_list and dns_get_by_name_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a record ID is known (i.e., 'by ID') but does not explicitly state when to use this tool over alternatives like dns_get_by_name_type, nor does it mention exclusions or prerequisites. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint already indicates this is a safe read operation. The description's 'List' is consistent but adds no extra behavioral context such as pagination, response limits, or what 'all' includes. No value beyond the annotation is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It clearly states the action and object, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple one-parameter schema, a read-only annotation, and an output schema that presumably covers return structure. The description sufficiently conveys the core function, though it lacks any caveats about large datasets or filtering behavior. Slightly more context could help, but overall it is adequate for this simple 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 parameter 'domain' has a complete schema description ('Domain name (e.g., 'example.com')'), achieving 100% schema coverage. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('DNS records') and scope ('for a domain'). It distinguishes from siblings like dns_get or dns_get_by_name_type by explicitly stating 'all' records, implying a broad listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all DNS records for a domain, but it does not explicitly mention when to use this instead of dns_get or dns_get_by_name_type, nor does it provide any exclusion criteria. The usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the destructiveHint annotation. It does not disclose whether deletion is permanent, what happens to associated data, or any side effects. With the annotation already indicating destructiveness, the description offers minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Delete a URL forwarding rule.') with no wasted words. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two well-documented parameters, an output schema, and a destructiveHint annotation, the one-sentence description is largely complete. However, it omits guidance on how to obtain the forward_id (e.g., from domains_get_url_forwards), which would be useful context but is not strictly required given the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters ('domain' and 'forward_id'), covering 100% of the parameter semantics. The tool description does not add any additional meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('URL forwarding rule'), making it immediately clear what the tool does. It also distinguishes itself from sibling tools like domains_add_url_forward and domains_get_url_forwards by naming the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'Delete' but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing to obtain the forward_id from domains_get_url_forwards, nor any exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already communicates the destructive nature, and the description does not contradict it. The description adds the filtering scope (by subdomain and type), but does not clarify whether all matching records are deleted or just one, which is a behavioral trait not covered by annotations. Given the presence of the destructiveHint, the description provides sufficient but minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. It avoids unnecessary words and is front-loaded with the action. Perfectly sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and an output schema, so return values need not be explained. However, the description leaves ambiguity about the deletion scope (all matching records vs. one), which could lead to misuse. The destructiveHint and schema provide some context, but the lack of behavioral details makes it incomplete for a destructive 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 schema description coverage is 100%, so all three parameters are already documented. The description 'by subdomain and type' only paraphrases the schema and adds no additional meaning or syntax details. Therefore, it does not elevate beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete DNS records') and specifies the selection criteria ('by subdomain and type'), which distinguishes it from sibling tools like dns_delete (which likely deletes by ID) and dns_edit_by_name_type. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (deleting by subdomain and type), but does not explicitly state when to use this over alternatives like dns_delete. There is no mention of exclusions or prerequisites, leaving the decision to the agent based on the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the operation type (create) without disclosing any behavioral details such as duplicate handling, permissions, prerequisites, or side effects. The annotation idempotentHint=false provides minimal context, but the description adds no extra transparency beyond what is already obvious from the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the core action. It is efficient and contains no unnecessary words or verbose details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally sufficient for a simple create operation, especially with a complete schema and output schema present. However, it does not explain any edge cases, failure conditions, or the significance of a glue record beyond the basic purpose, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters (domain, subdomain, ips) with examples and type information, so schema coverage is 100%. The description itself adds no parameter-specific value, but the baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (glue record for self-hosted nameservers), making it specific and easy to distinguish from sibling tools like domains_update_glue_record or domains_delete_glue_record. This is a precise verb+resource pairing.
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 purpose implies that this tool is used when creating a new glue record, which is a clear context. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks exclusions. The distinction from other glue-record tools 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?
The annotation idempotentHint: false already informs the agent that repeated calls create multiple records, covering the key behavioral trait. The description adds no further context, such as side effects, validation behavior, or prerequisites, but it does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is front-loaded with the action and resource, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a thorough schema, an output schema, and a simple operation, the description is adequate. It lacks some context like domain existence prerequisites, but the schema and annotations cover the essentials, making it complete enough for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are fully documented. The description itself adds no parameter semantics, but the schema carries the burden, resulting in a baseline 3 score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a new DNS record'), clearly distinguishing it from sibling tools like dns_list, dns_edit, and dns_delete. It is unambiguous and accurately describes the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Create' implies use for adding a new record, and the sibling names make it clear that edit/delete are for other purposes. However, there is no explicit guidance on when to use this tool versus alternatives, such as noting that dns_edit should be used for modifying existing records or that creating a duplicate may be prohibited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the operation itself. The annotation readOnlyHint=true already discloses the read-only nature, and the description does not provide any additional context such as error behavior, formatting, or ownership requirements. It simply restates the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded and free of any redundant information. It earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a one-line description is largely sufficient. The output schema and annotations fill in return values and safety. However, it lacks a note about when this tool might be preferred over related tools, though this is minor given the clear naming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'domain' parameter with type and example, covering 100% of parameters. The description adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('glue records'), scoped to 'a domain'. This distinguishes it from sibling tools like domains_create_glue_record or domains_delete_glue_record, which handle mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to fetch glue records for a domain. While it doesn't explicitly name alternatives, the sibling tools for creating, updating, and deleting glue records make the intended use clear. No exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent with that. No additional behavioral traits are disclosed (e.g., whether all forwards are returned or whether the domain must exist), but the output schema likely covers return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words, front-loaded with the action and resource, and contains no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, an output schema, and read-only annotation, the description is adequate. It could mention edge cases or alternative tools, but those are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add parameter information, but the schema has full coverage (100%) for the single 'domain' parameter, including an example format. No additional explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'URL forwarding rules for a domain', making it easy to distinguish from sibling add/delete tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The verb 'Get' implies a read operation, and sibling tool names suggest add/delete equivalents, but the description does not state this or offer any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation idempotentHint=true already signals safe-repeated execution. The description itself adds no behavioral detail beyond the fact that it updates IP addresses. It does not mention that the operation replaces all existing IPs, though this is covered in the schema. There is no contradiction.
Agents need to know what a tool does to the world before 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 concise sentence that is front-loaded with the action. No filler or redundant information. Every word earns its place, making it an example of efficient specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation, the schema fully documents parameters, and the idempotentHint annotation covers idempotency, the description is largely complete. The only missing element is a note that the IP list replaces all existing addresses, but this is already in the schema. For a compact tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the three parameters (domain, subdomain, ips) with clear descriptions. The description adds no additional parameter semantics beyond what the schema already states. This aligns with the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update a glue record's IP addresses.' It uses a specific verb ('update') and resource ('glue record's IP addresses'), and the scope is well-defined. The sibling tools include create/delete glue records, so 'update' distinguishes this tool effectively.
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 updating an existing glue record's IP addresses (as opposed to creating or deleting), but it does not explicitly state when to use this tool over alternatives or provide any prerequisites. The usage context is clear from the verb 'update' and the sibling names, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation, and the description does not contradict that. The description adds the domain scoping, but this is already present in the schema. No additional behavioral traits (e.g., pagination, error handling) are disclosed, but the simple nature of the tool and the annotation reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence ('List DNSSEC records for a domain.') that communicates the essential purpose with no redundancy or superfluous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and an output schema, the description adequately covers the core action and scope. However, it could be slightly more complete by explicitly noting that this is distinct from dns_list (which lists regular DNS records), helping agents disambiguate between the two similar-sounding tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the 'domain' parameter, including an example. The description's phrase 'for a domain' merely restates the schema parameter without adding extra meaning, validation rules, or edge-case guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('DNSSEC records'), clearly distinguishing it from sibling tools like dns_list (regular DNS records) and dnssec_create/delete. It precisely states the tool's scope in a single, unambiguous phrase.
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 that this tool is for listing DNSSEC records, implying it should be used when DNSSEC-specific data is needed. However, it does not explicitly mention alternatives or exclusions relative to dns_list, so it lacks an explicit 'vs' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the important constraint about Porkbun nameservers, which is a behavioral boundary. It does not describe response format or error behavior, but the read-only nature is covered by annotations and output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose, the second states a critical usage constraint. No wasted words; information is front-loaded and directly relevant.
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?
With a single parameter, a read-only annotation, and an output schema present, the description covers the essential context. The purpose and unique availability condition are stated. No additional details are needed for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with the description 'Domain name (e.g., 'example.com')' for the 'domain' parameter. The tool description does not add additional parameter semantics beyond this, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'SSL certificate bundle for a domain.' This is specific and distinguishes from sibling tools which focus on DNS/domain management, not SSL certificate retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit availability constraint: 'Only available for domains using Porkbun nameservers.' This implies when not to use the tool, though it does not mention alternative tools for non-Porkbun nameservers. Still, this is clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds 'in your Porkbun account' to clarify scope but provides no additional behavioral details such as pagination, sort order, or potential edge cases. This is minimal extra value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and directly states the tool's action. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters) and the presence of an output schema, the description is fully sufficient. It clearly communicates the tool's function without needing to describe return values or complex behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description doesn't need to explain parameters, and none are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 domains in your Porkbun account' with a specific verb and resource. It distinguishes from sibling tools like dns_list (DNS records) and domains_get_nameservers (nameservers), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need a full list of all domains. However, it doesn't explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the concrete output ('public IP address') without contradicting the annotation. It doesn't discuss response format or latency, but for a simple ping utility the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, self-contained sentence with no filler. It efficiently front-loads the core purpose and provides no extraneous 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?
With no parameters, an output schema present, and a readOnly annotation, the one-sentence description fully covers the tool's behavior for the agent. Nothing further is needed.
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?
This tool has zero parameters, so the description carries no burden for parameter documentation. The baseline of 4 applies because there is nothing to explain beyond what is already evident from the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Test') and clearly identifies the resource ('API connectivity') while also noting the additional output of the public IP. This distinguishes it sharply from the sibling DNS and domain management 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 clearly implies its use case—checking API connectivity and retrieving the public IP. It doesn't explicitly enumerate alternatives or exclusions, but given the tool's simplicity and the obvious distinction from the sibling domain-management tools, the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered structurally. The description adds valuable behavioral context with the heavy rate limit (1 request/10 seconds) and positions the tool as a final confirmation step, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, purposeful sentences: a one-line purpose, a warning, an alternative tool reference, and a usage constraint. No redundancy, with the most critical operational caveat (rate limit) front-and-center.
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 tool with an output schema, the description covers purpose, rate limiting, when-to-use, and alternatives. It doesn't need to explain return values because the output schema exists, making the description contextually 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?
Input schema provides complete documentation of the single 'domain' parameter with an example format, so schema coverage is 100%. The description does not add parameter-level meaning beyond 'domain name to check'; however, baseline is 3 because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Check domain availability and pricing') and clearly distinguishes itself from sibling pricing_get by directing price comparisons to that tool. It also narrows its scope to confirming specific domain availability, which sets it apart from list/read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: only when needing to confirm a specific domain is available. It names the alternative (pricing_get) for price comparisons and highlights the rate-limit constraint, giving agents clear decision rules.
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?
Beyond the readOnlyHint annotation, the description reveals that there are no rate limits and that all TLD prices are returned at once, which helps an agent understand performance and scope. This adds meaningful behavioral context without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences that get straight to the point. The first defines the purpose, the second emphasizes preference, and the third provides an alternative. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a read-only annotation, and an output schema, the description covers the essential aspects: what it does, when to use it, and how it differs from the sibling tool. It is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to document any. The description clarifies that the result covers all TLDs and that filtering by TLD happens after retrieval, which adds context beyond the empty 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 opens with 'Get pricing for all available TLDs,' a specific verb+resource statement. It further distinguishes itself from siblings by noting it is preferred for price lookups and returns all TLD prices at once, clearly separating it from domains_check_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'PREFERRED for price lookups' and 'Use this FIRST when users ask about domain costs, then filter by TLD.' It also provides a clear exclusion: 'Only use domains_check_availability when you need to verify a specific domain is actually available for purchase,' naming an alternative tool and when to use it.
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:

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

Score Badge

Copy to your README.md:

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

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