mcp-server-subreg

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools target distinct resources and actions clearly (domains, contacts, DNS, orders, credit). The only notable ambiguity is between pricelist and get_pricelist, which both fetch pricing data but are described differently enough to be mostly distinguishable.
Naming Consistency2/5
Naming conventions are mixed: retrieval uses both get_ and info_ prefixes, list operations use noun-first names (contacts_list, domains_list), and some tools are bare nouns (pricelist). This inconsistency makes it harder to predict tool names.
Tool Count3/5
With 20 tools, the server is on the heavier side, but the scope covers domain lifecycle, contacts, DNS, billing, and orders, which justifies the count. It's borderline but not excessive.
Completeness3/5
Core domain operations are present (check, register, renew, delete, list, info), plus contacts and DNS record management. However, there are notable gaps such as no delete_contact, no update_dns_record, no order listing, and no domain transfer support.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. While the verb 'check' implies a read-only operation, the description does not explicitly state that no modifications are made, nor does it disclose any caching behavior, error conditions, or output format. This leaves the agent with limited knowledge of the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no unnecessary words, appropriately brief and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description fails to specify what the tool returns (e.g., a boolean, a status string, or an error) and does not mention edge cases like invalid domains or network dependencies. Given the absence of an output schema, this is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required string parameter 'domain' with 0% schema coverage, and the description adds no additional details about the expected format (e.g., whether to include the TLD, protocol, or subdomain). The description merely repeats the word 'domain' from the parameter name, providing no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific action ('check') and resource ('domain availability'). It distinguishes from sibling tools like info_domain and register_domain by focusing specifically on availability checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as info_domain, get_tld_info, or register_domain. It lacks contextual triggers like 'before registering' or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does reveal a permission requirement (SUBREG_READONLY=false), but it omits critical side effects of a destructive operation such as irreversibility, impact on DNS records, or refund policies. This is insufficient for a delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing only essential information: the action and the prerequisite. It is concise, front-loaded, and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and no annotations, the description is severely under-specified. It lacks usage context, post-deletion effects, and any mention of alternatives or error conditions, making it only marginally more helpful than the tool name itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'domain' parameter beyond its name. It fails to specify expected format (e.g., example.com vs. punycode), whether it expects a domain ID or name, or any other constraints, forcing the agent to rely on the parameter name alone.
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 'Delete (cancel) a domain registration' with a specific verb and resource. This distinguishes it from the sibling tool 'delete_dns_record' and other domain management tools like 'register_domain' and 'renew_domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only mentions a prerequisite (SUBREG_READONLY=false) but does not compare with register_domain, renew_domain, or delete_dns_record, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions the permission requirement, which is useful, but it does not describe side effects, success/failure behavior, or idempotency. This is a minimal but not contradictory disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose and a key requirement with no filler. It is well-structured and appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description is too sparse. It lacks parameter explanations, return value information, and any edge-case guidance, making it incomplete for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the six parameters (domain, name, type, content, ttl, prio). It does not explain any of them, leaving the agent without semantic guidance for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('DNS record to a zone hosted on Subreg DNS'), which is specific and distinguishes it from sibling tools like delete_dns_record or get_dns_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?
It provides a usage prerequisite (SUBREG_READONLY=false) but does not explicitly state when to use this tool over alternatives or when not to use it. The context is clear but no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Fetch' without elaborating on the response format, error behaviors, or side effects. It does not specify whether the operation is strictly read-only or what happens if the named pricelist does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, containing no filler words. It effectively communicates the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be fully self-contained. It leaves gaps about the structure of the returned pricelist, potential errors, and whether any prerequisites exist, making it only minimally adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a 'pricelist' string with no description, and the description adds that it is a 'named/specific' identifier with an example ('reseller pricelist'). This clarifies the parameter's semantic role, but it does not specify accepted formats or constraints beyond the type, so compensation for the 0% schema coverage is only partial.
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 ('Fetch') and resource (a 'named/specific pricelist'), providing enough scope to distinguish it from a generic list-all tool like 'pricelist'. The example 'reseller pricelist' adds useful context about the kind of pricelist targeted.
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 you have a specific pricelist name, but it does not explicitly contrast with sibling tools such as 'pricelist' or mention when not to use it. There are no explicit exclusions or alternative recommendations, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Fetch' implies a read-only operation, and the listed content adds context. However, it does not disclose error behaviors, whether the TLD must exist, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the verb and resource, with no unnecessary words. It efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly sufficient, mentioning examples of returned data (min/max period, required fields). However, it lacks usage guidance and parameter constraints, making it not fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required 'tld' parameter with no description (0% coverage). The description only states that the tool fetches rules 'for a TLD', which merely repeats the parameter name without adding details about format, case-sensitivity, or accepted values, such as 'com' vs '.com'.
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 fetches registration rules for a TLD, using a specific verb 'Fetch' and a specific resource. It distinguishes from siblings like info_domain, which is for a specific domain's data, not TLD-level rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as check_domain or info_domain. It does not state scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey that the operation is a read-only fetch (via 'Fetch') and that it is scoped to the authenticated account, which is useful. However, it does not explain the return format, any potential costs, or rate limits, and the term 'full' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly explains the tool's purpose with no wasted words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is minimal but adequate for a simple getter. However, the existence of a sibling tool named 'get_pricelist' creates ambiguity that the description fails to resolve, and the lack of output schema details leaves the agent uncertain about the response structure.
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's mention of 'for the authenticated account' adds context about implicit scoping that is not captured in the empty parameter list, slightly enhancing the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full TLD pricelist for the authenticated account, using a specific verb and resource. However, it does not distinguish itself from the sibling tool 'get_pricelist', which likely serves the same purpose, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_pricelist or get_tld_info. The usage is only implicitly implied by the action 'Fetch', with no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a precondition (SUBREG_READONLY must be false) which implies the tool is a write/delete operation, but it does not elaborate on side effects, permanence, or error behavior. The requirement adds value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, but without an output schema or annotations, the description omits expected return values and failure modes. The precondition is helpful, but overall completeness is adequate but not thorough for an unannotated delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'record id' and 'zone' which hint at the parameters record_id and domain, but does not explain what 'domain' represents or how to obtain the record_id. This is minimal value, insufficient for no 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 function: 'Delete a DNS record from a zone by its record id.' It uses a specific verb and resource (delete DNS record) and distinguishes it from sibling tools like add_dns_record and delete_domain.
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 provides a condition: 'Requires SUBREG_READONLY=false,' which is a useful context for when the tool can be used. However, it does not explicitly mention when to use this tool versus alternatives, nor does it state 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?
No annotations are provided, so the description carries the burden of explaining behavior. 'Fetch' indicates a read-only operation and the examples show expected output fields, but it does not mention permissions, error conditions, or response structure beyond the examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description is mostly complete: it states the purpose and example return fields. However, it lacks explicit usage guidance and parameter format, so it is not fully self-sufficient, though the low complexity keeps the gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, 'domain', with 0% description coverage. The description says 'for a domain' but adds little beyond the parameter name—no format, example, or constraints are given. Since coverage is low, the description should compensate more.
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 ('Fetch') with a clear resource ('registration details') and sample fields (status, expiration, nameservers), making it easy to distinguish from sibling tools like check_domain or info_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for domain registration details) but gives no explicit guidance about alternatives or when not to use it. It does not mention exclusions or compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a permission requirement (SUBREG_READONLY=false), which is a useful behavioral trait, but it does not mention side effects, error behavior, or response format. This is better than no disclosure but still leaves significant gaps for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the purpose, and contains no redundant information. The external reference is presented as a single line, keeping the description focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex due to the nested 'params' object and the absence of an output schema. The description does not explain what the create operation returns or what happens on success/failure, relying on an external manual. This leaves the agent under-informed for invoking the tool and processing the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only an opaque 'params' object with no internal properties, so schema coverage is 0%. The description compensates by listing example fields (name, email, address, phone) and directing to the full Subreg schema, adding meaningful semantic guidance 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 clearly states 'Create a new contact object' with a specific verb and resource. This distinguishes it from sibling tools like update_contact and info_contact, which target different actions on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires SUBREG_READONLY=false') which gives some context for when the tool is usable, but it does not explicitly discuss when to use this tool versus alternatives such as update_contact. The usage is implied by the verb 'create' rather than explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It correctly implies a read-only operation with 'Fetch,' and 'current account credit balance' indicates the return value. However, it does not disclose response format, currency, or any access requirements, so transparency is basic 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 that states the action and object with no wasted words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (zero parameters, no output schema), the description is mostly complete: it states what the tool does and what it returns conceptually. However, it omits any detail about the value's format or units, which could matter for an agent, so it falls just short of perfect completeness.
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 correctly adds no parameter information because there are none to document, making it appropriate for the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Fetch,' and a clear resource, 'current account credit balance,' making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like credit_correction, which implies modification rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of constraints or prerequisites. The purpose is clear, but the description does not explicitly state that this should be used when checking credit balance or that credit_correction is for adjustments, so usage guidance is essentially absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The verb 'Fetch' clearly suggests a read-only operation, which is helpful, but the description does not disclose any other behavioral traits such as error handling, authentication requirements, or rate limits. It adds minimal context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and target. It contains no extraneous words and is well-structured for quick parsing, making it an excellent example of 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?
For a simple read-only tool with one parameter and no output schema, the description is largely sufficient. It covers the primary purpose and implies the nature of the order. However, it does not describe any return value structure or edge cases, though the absence of an output schema means the description does not need to detail returns. A short note on expected output could make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single required parameter, order_id, with no description. The tool description says 'previously submitted order,' which implies that order_id refers to an existing order, but it does not explicitly explain the parameter's format, origin, or any additional semantics. With 0% schema description coverage, the description only partially compensates by indicating the order's life-cycle stage.
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 'Fetch' and clearly identifies the resource as 'status and details of a previously submitted order,' distinguishing it from sibling tools like info_domain or info_contact which target different resources. It leaves no ambiguity about the tool's purpose.
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 'previously submitted order' implies that this tool is for retrieving existing orders, not creating new ones, but the description does not provide explicit guidance on when to use this tool versus alternatives, and no alternatives are named. Usage context is only implied, not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states 'Update' which implies mutation, and explicitly mentions the SUBREG_READONLY=false requirement, which is a useful behavioral constraint. However, it does not disclose side effects, error behavior, or return values, leaving notable gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action, the second provides a prerequisite and a reference. There is no fluff, redundancy, or extraneous details. The structure is front-loaded with the core purpose and uses the second sentence for additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and a nested 'params' object with loose additionalProperties, the description is incomplete for a mutation tool. It provides a prerequisite and a manual link, but does not describe return values, error conditions, or the exact fields expected in params. The external link helps but the in-description coverage is insufficient for an agent to fully understand the tool's behavior without extra lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0% description coverage and provides only 'params' as an object with additionalProperties true. The description compensates by referencing the 'Subreg Update_Contact schema' and linking to the manual, which gives a canonical definition of the params structure. This adds meaning beyond the empty schema, but it does not inline the actual parameter details, so the agent still needs external lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Update an existing contact object,' which clearly states the action (update) and the resource (contact object). It also explicitly says 'existing,' distinguishing it from create_contact and other sibling tools. This is a specific verb+resource combination that leaves no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when updating an existing contact) and provides a clear precondition: 'Requires SUBREG_READONLY=false.' It does not explicitly mention alternatives such as create_contact for new contacts, but the word 'existing' offers contextual guidance. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions a required flag (SUBREG_READONLY=false), which is a useful precondition. However, it does not disclose consequences such as charges, idempotency, or what happens if the domain is already renewed or expired. The action itself is straightforward but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the action and object, the second gives a necessary prerequisite. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations, no output schema, and 0% parameter coverage, the description should provide more context. It explains what the tool does and a prerequisite, but lacks information about return values, cost/credit implications, or how the renewal affects the domain's status. Given the sibling set, the purpose is clear, but an agent may need more guidance on expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 clarifies that 'years' means the number of years to renew, which adds semantic value beyond the raw schema. The 'domain' parameter is self-explanatory by name and context, but no format or constraints are provided. Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'renew' with the resource 'domain' and explicitly states the action ('for the given number of years'). It clearly distinguishes from sibling tools like register_domain, delete_domain, and check_domain.
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?
States the tool is for renewing an existing domain, which implies it should be used after registration and not for new domains. Also notes the prerequisite SUBREG_READONLY=false, providing an environmental requirement. Does not explicitly name alternative tools or when not to use, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the critical semantics of the amount parameter ('amount is added to the current balance; use a negative value to subtract') and the permission requirement. It does not mention reversibility, idempotency, or error cases, but for a straightforward balance adjustment, the key behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences totaling 22 words. The core purpose is front-loaded in the first sentence, and the second sentence adds crucial operational detail. Every word earns its place; there is zero fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 parameters, no nested objects, no output schema), so the description need not be elaborate. It covers the main behavior and the permission prerequisite. However, it omits any indication of success/failure response, whether the operation is reversible, or any validation constraints (e.g., max/min amount). Given the availability of sibling tool get_credit, a note about verifying the change after the call would improve completeness. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains 'amount' behavior clearly, and 'sub-user' implies that 'username' refers to a sub-user. However, the 'reason' parameter is entirely unexplained, and the description does not elaborate on the expected format or constraints for username or amount beyond the sign semantics. The compensation is partial at best.
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: 'Adjust a sub-user's credit balance.' The verb 'adjust' and the specific resource 'sub-user's credit balance' make the purpose distinct from sibling tools like get_credit (which reads credit) and info_user. It immediately communicates what the tool does and its scope.
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 a key usage condition: 'Requires SUBREG_READONLY=false.' This tells the agent when the tool can be used (when permissions allow) but does not explicitly contrast it with alternatives or state when not to use it. The context is clear and actionable, but it lacks explicit exclusion guidance, preventing 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?
No annotations are provided, so the description carries full burden. It states this is a read-only list operation scoped to the authenticated account, but does not disclose return format, pagination, or any limitations. It adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no redundant information. It is perfectly concise 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 is very simple (no params, no output schema). The description tells what it does, but does not mention what the list contains (e.g., domain names, statuses). For a basic list operation this is sufficient, but a bit more detail on return content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and an empty schema, so the baseline is 4. The description does not need to explain parameters, and no gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), the resource ('domains'), and the scope ('all domains held under the authenticated Subreg account'). This distinguishes it from sibling tools like info_domain which likely operate on a single domain.
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 needing to retrieve all domains, but does not explicitly contrast with alternatives such as info_domain or check_domain. There is no 'when not to use' guidance, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Fetch' indicates a non-mutating read operation, but with no annotations provided, the description does not explicitly state that there are no side effects, how results are returned, or any permission requirements. It provides basic transparency but relies on inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and object. There is no redundancy or filler, making it efficient and well-structured.
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 only one parameter and no output schema, the description sufficiently explains what the tool does and what it returns ('DNS zone records'). It lacks details on response structure or error cases, but for a simple fetch tool, these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a 'domain' string with 0% description coverage. The description adds the constraint that the domain must be 'hosted on Subreg DNS,' which gives context beyond the schema, but it does not clarify format or assumed characteristics of the domain value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch DNS zone records for a domain hosted on Subreg DNS,' using a specific verb (Fetch) and resource (DNS zone records). It clearly distinguishes from sibling tools like add_dns_record and delete_dns_record by focusing on 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 context is clear: use when you need to retrieve DNS zone records for a domain. It implies a read-only operation but does not explicitly state exclusions or alternatives; however, for a simple fetch tool, the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. 'Fetch details' clearly indicates a read-only operation, but it does not describe the return format, authentication needs, or potential errors. The behavior is adequately transparent for a simple lookup, but richer context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and target. There is no redundant or filler content, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides sufficient information to select and invoke it correctly: it names the resource type and the required identifier. It would benefit from mentioning the expected return format, but the low complexity reduces the need for more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a parameter name 'contact_id' with 0% description coverage. The tool description compensates by clarifying it is the 'Subreg contact id', adding meaning beyond the schema. It does not specify format or examples, so a 4 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 the specific verb 'Fetch details' and identifies the resource as 'a contact object by its Subreg contact id', clearly distinguishing it from sibling tools like contacts_list (list), create_contact, and update_contact. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a Subreg contact id and need full contact details, but it does not explicitly state when not to use it or mention alternatives such as contacts_list for listing all contacts. The context is clear but exclusions and alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Fetch' and 'authenticated user' signal a read-only operation and an authentication requirement, which is helpful. However, it does not disclose authorization details for sub-users, behavior on invalid IDs, or the structure of returned info, leaving partial 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 13-word sentence that efficiently communicates both the core purpose and the key parameter distinction with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and the description covers the basic purpose and parameter semantics. However, with no output schema or annotations, it does not specify what 'info' is returned, error behavior, or any permissions beyond the word 'authenticated,' leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one nullable integer parameter with no description, and the description directly explains its semantics: null (default) fetches the authenticated user, while providing an id fetches a sub-user. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch info about the authenticated user, or a specific sub-user by id.' It uses a specific verb ('fetch'), identifies the resource ('user'), and distinguishes between two distinct use cases (self vs sub-user), setting it apart from sibling info_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing user info) but does not explicitly discuss alternatives or exclusions. It does not mention other tools like info_contact or info_domain, and it lacks definitive 'when to use / when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a precondition (SUBREG_READONLY=false) and a units detail (period in years). However, it does not describe side effects such as billing, propagation, or whether registration is immediate, nor does it mention error conditions or return 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 three sentences long, front-loaded with the core purpose, and each sentence adds distinct value: purpose, prerequisite, and parameter semantics. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, annotations, or schema descriptions, the description is incomplete. It omits what the tool returns, the meaning of nsset and ns_hosts, and any guidance on checking domain availability first (check_domain is a sibling). These gaps leave the agent underinformed for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining that registrant_id/contacts_admin_id/contacts_tech_id/auth_id are Subreg contact object ids and references info_contact/contacts_list. It also clarifies period is in years. Though nsset and ns_hosts remain unexplained, most non-obvious parameters are covered.
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 'Register (order) a new domain' – a specific verb and resource. The parenthetical '(order)' clarifies the commercial nature and helps distinguish from sibling tools like renew_domain and delete_domain.
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 a clear prerequisite: 'Requires SUBREG_READONLY=false', indicating when the tool can be used. It also implicitly defines usage context (registering a new domain) but does not explicitly reference alternatives like check_domain for availability or renew_domain for renewals.
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 given, so the description carries the burden. 'List' implies a safe read operation, but the description does not disclose pagination, sorting, or response format. For a simple list tool, this is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, grammatically complete sentence with no filler. Efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (zero parameters, no output schema), the description covers the essential action and scope. A minor gap is the lack of response format, but this is not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing to clarify. The description's mention of 'authenticated account' adds contextual meaning beyond the empty schema, warranting a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'contact objects registered under the authenticated account,' clearly stating what the tool does. It differentiates from sibling tools like info_contact (single contact) and create_contact/update_contact.
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?
Provides clear context that this lists contacts under the authenticated account, implying when to use. Does not explicitly name alternatives or exclude other tools, but the scope is unambiguous.
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-server-subreg MCP server](https://glama.ai/mcp/servers/VitexSoftware/mcp-server-subreg/badges/card.svg)](https://glama.ai/mcp/servers/VitexSoftware/mcp-server-subreg)

Score Badge

Copy to your README.md:

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

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/VitexSoftware/mcp-server-subreg'

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