Custom domains API for SaaS: connect, verify, and manage customer domains, SSL, and DNS
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.6/5.
Multiple tools operate in the same DNS/domain space, e.g., generic DNS record lookup overlaps with specific CNAME, TXT, SPF, DKIM, and DMARC lookups. Website status checker also overlaps with SSL check and redirect checker, though descriptions clarify their distinct purposes.
All tool names follow a consistent snake_case pattern with a 'tools_' prefix and an action word at the end (lookup, checker, check, finder). This makes the naming highly predictable and uniform.
16 tools is slightly above the ideal 3-15 range, but the domain intelligence scope is broad enough that each tool addresses a specific need without feeling bloated. The count is reasonable for a comprehensive domain/DNS toolkit.
The tool set covers a wide range of domain-related functionality: DNS records, email authentication (SPF, DKIM, DMARC), SSL/TLS, HTTP headers, redirects, WHOIS, availability, subdomain enumeration, and website status. No obvious critical gaps exist for its apparent purpose.
tools_cname_lookupAFree public API. Resolve a hostname's CNAME chain. Useful for debugging custom-domain CNAME setups.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to resolve, e.g. www.example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds context like 'Free public API' (suggesting no authentication or external service) and 'CNAME chain' (indicating it follows the full chain), but does not disclose details such as rate limits or error behavior. This adds some value beyond annotations but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. It front-loads the core action ('Resolve a hostname's CNAME chain') and adds a use case. Every phrase earns its place, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description covers the essential aspects: what it does, a use case, and the external API nature. It does not explain return behavior in detail, but that is not critical given the low complexity and strong annotations. It is slightly incomplete in not mentioning what happens if no CNAME record exists, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the 'host' parameter with a clear description and example ('www.example.com'). The tool description does not add additional semantic meaning beyond what the schema already offers, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a hostname's CNAME chain' with a specific verb ('Resolve') and resource ('hostname's CNAME chain'). It also identifies a distinct use case ('debugging custom-domain CNAME setups'), which differentiates it from sibling tools like dns_record_lookup that likely handle multiple record types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: 'Useful for debugging custom-domain CNAME setups.' This indicates when the tool is appropriate, though it does not explicitly mention alternatives or when not to use it. It implies a specific scenario without excluding other potential uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_dkim_record_checkerAFree public API. Look up the DKIM record at ._domainkey., parse the public key, flag issues.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check DKIM for. | |
| selector | Yes | DKIM selector — `google`, `k1`, `mxvault`, `s1`, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by mentioning that it parses the public key and flags issues, but it does not disclose specifics like rate limits, response format details, or the meaning of 'flag issues'. The safety profile is covered by annotations, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences with no filler. The first sentence states the resource and action, the second adds the parsing and issue-flagging behavior. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only API tool with no output schema, the description provides the core behavior (lookup, parse, flag) and the record path. It lacks explicit error handling or result format details, but the openWorldHint and simplicity of the tool make this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description enhances this by specifying the exact DNS record format `<selector>._domainkey.<domain>`, which clarifies how the two parameters combine. This goes beyond the schema's simple field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a DKIM record at `selector._domainkey.domain`, parses the public key, and flags issues. This specific verb+resource combination distinguishes it from sibling DNS tools like CNAME lookup or SPF record checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explicitly describing the lookup pattern and parsing behavior. It does not explicitly exclude alternatives or name sibling tools, but the scope is clear enough for an agent to know when to select it over other DNS record checkers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_dmarc_record_checkerAFree public API. Look up the DMARC record at _dmarc., parse policy/alignment/reporting tags, flag missing or too-permissive settings.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check DMARC for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a free public API and that it parses tags and flags missing or permissive settings, adding value beyond the read-only and open-world annotations. It does not contradict the annotations, and the safety profile is already covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at two sentences, but the first sentence 'Free public API.' provides marginal context and could have been integrated. The substantive sentence is dense and informative, so it's mostly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description covers the purpose, the method of lookup, and the analysis performed. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'domain' is fully described in the schema as 'Domain to check DMARC for.' The description adds meaning by specifying the lookup uses the _dmarc.<domain> convention, which goes beyond the schema and helps the agent understand the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up the DMARC record at _dmarc.<domain>, specifies it parses policy/alignment/reporting tags and flags issues. This specific verb+resource distinguishes it from sibling tools like DKIM and SPF checkers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 DMARC record checking, which is distinct from sibling tools for other DNS records. However, it does not explicitly mention when to use it over alternatives or offer exclusions, so it lacks the explicit when/when-not guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_dns_propagation_checkerAFree public API. Query the same hostname across ~10 public DNS resolvers worldwide and report which ones return the same answer. Useful right after a DNS change.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to check. | |
| type | No | Record type. Default: A. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description aligns. It adds meaningful behavioral context: free public API (auth expectations), scale (~10 resolvers worldwide), and comparison logic. No contradiction; could have mentioned rate limits or output format but not necessary given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short front-loaded sentences; no filler. 'Free public API' is useful context, followed by what it does and when to use. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (2 params, no nested, no output schema), and annotations cover safety. Description explains purpose, use case, and approximate behavior. Lacking explicit output format/fields, but for a public DNS checker the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description reinforces 'host' as hostname and implies record type via 'DNS change' but adds no syntax or formatting beyond schema. It doesn't explain how 'type' affects the comparison.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Query') and identifies the resource ('same hostname across ~10 public DNS resolvers worldwide'), clearly distinguishing it from sibling tools like dns_record_lookup or cname_lookup. The result behavior ('report which ones return the same answer') clarifies the propagation-checking purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Useful right after a DNS change.' Provides clear context but does not name alternatives or exclusions; with ~15 sibling DNS tools, an explicit 'use dns_record_lookup for a single resolver' would have been stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_dns_record_lookupAFree public API. Look up DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA) for any domain.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one record type. Default: all common types. | |
| domain | Yes | Domain to query, e.g. example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, providing a strong safety baseline. The description adds 'Free public API', which signals no authentication requirement or potential rate limits, giving extra context beyond the annotations. It does not describe return format, but that is not critical for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action. 'Free public API' is a minor addition, but every other word earns its place. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is sufficiently complete. It specifies the resource (DNS records), scope (any domain), and supported record types. The only minor gap is the lack of detail about response format or error handling, but that is not necessary given the tool's simplicity and the annotations covering safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both 'domain' and 'type' have detailed descriptions in the schema. The description's mention of record types mirrors the enum in the schema without adding new meaning. Therefore, it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up DNS records and lists the specific record types (A, AAAA, CNAME, MX, TXT, NS, SOA) for any domain. This distinguishes it from sibling tools that focus on single record types like CNAME or TXT lookups, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies general DNS lookup usage by enumerating record types and stating 'any domain'. It does not explicitly mention alternatives like specific record lookup tools, but the context is clear enough for an agent to infer when to use this tool versus siblings. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_domain_age_checkerAFree public API. Returns a domain's registration date, age in days + years, last-updated date, and expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the description is not required to restate safety. It adds context by noting it is a free public API and enumerating returned fields, but does not disclose rate limits, error behavior, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information about what the tool does, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and comprehensive annotations, the description adequately enumerates the returned data. It lacks an output schema, but the listed fields provide sufficient expectation of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description for the single 'domain' parameter, so the baseline is 3. The description adds no additional parameter-level semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a domain's registration date, age, last-updated date, and expiration, using the specific verb 'Returns' with a resource. This differentiates it from sibling tools like whois_lookup by focusing on age and expiration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It neither states scenarios nor mentions alternatives such as whois_lookup or domain_availability_checker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_domain_availability_checkerAFree public API. Check availability of a name across one or more TLDs. Pass a name (no TLD) and an optional tlds array.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Bare name without TLD, e.g. `mybrand`. | |
| tlds | No | Optional list of TLDs to check, e.g. ['com', 'io', 'dev']. Default: a standard SaaS set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds valuable context by noting it is a 'Free public API' (implying no authentication) and clarifies that it checks across 'one or more TLDs.' This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short sentences. It front-loads the 'Free public API' context, states the core function, and gives parameter guidance without any wasted words. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two params, no nested structure) and strong annotations, the description adequately covers what the tool does and how to call it. The only minor gap is the lack of mention of output format, but this is mitigated by the tool's name and clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with meaningful descriptions for both parameters. The description's 'Pass a `name` (no TLD) and an optional `tlds` array' largely repeats the schema, adding no new semantic information. This aligns with the baseline of 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check availability of a name across one or more TLDs.' This is a specific verb-resource pairing that distinguishes it from sibling DNS-related tools like whois_lookup or dns_record_lookup. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating it is a 'Free public API' and instructs how to pass the `name` and optional `tlds` array. It does not explicitly mention exclusions or alternatives, but the tool's purpose is distinct enough among siblings that no additional guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_http_header_checkerAFree public API. Fetch a URL and return its response headers + security grade based on common security headers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with scheme, e.g. https://example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds context about being a public API and outputting headers + security grade, but does not disclose potential network behavior, rate limits, or error handling. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and lack of output schema, the description sufficiently explains what the tool does and what it returns (headers + security grade). It could mention return format or edge cases, but for the tool's simplicity it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage of the single 'url' parameter with a clear description ('Full URL with scheme'). The tool description does not add any additional parameter semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a URL and returns response headers plus a security grade. This is a specific verb+resource (fetch URL) and distinguishes it from sibling tools like redirect_checker or website_status_checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('fetch a URL and return headers + security grade') but provides no explicit guidance on when to choose this over alternatives or any exclusions. The phrase 'Free public API' hints at accessibility but does not compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_redirect_checkerAFree public API. Follow a URL's redirect chain and return every hop with status code, response time, final destination.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the bar is lower. The description adds valuable behavioral details: it traces the full redirect chain and reports per-hop status codes, response times, and the final destination, which annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that conveys the tool's function, output, and access model with zero redundancy. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with robust annotations and no output schema, the description sufficiently explains what the tool does, what it returns, and the access model. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'url' parameter, described as 'Starting URL' with URI format. The description doesn't add additional meaning beyond the schema, but none is needed for a single obvious parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Follow') and resource ('a URL's redirect chain'), and specifies the output (every hop with status code, response time, final destination). This distinctly separates it from sibling tools like DNS lookups or website status checkers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the tool's specific use case (following redirect chains) and notes it's a 'Free public API', implying no authentication barrier. It doesn't explicitly state when not to use it, but the context is clear enough given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_reverse_ip_lookupAFree public API. Reverse-DNS (PTR) lookup for an IP address. Returns one or more hostnames if configured.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address, e.g. 8.8.8.8. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive hints. The description adds useful context by stating it is a 'Free public API' and noting 'if configured' to indicate hostnames may not exist, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core functionality, and contains no wasted words. 'Free public API' is superfluous but does not detract from the conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only lookup, the description covers the purpose, return type ('one or more hostnames'), and a caveat ('if configured'). With no output schema, this is sufficient for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the 'ip' parameter with type, minimum length, and an example. The description does not add extra semantic detail beyond referencing the IP address in context. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'lookup' with a clear resource (IP address) and explicitly states the return value (hostnames). It clearly distinguishes this tool from sibling DNS lookup tools that perform forward lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for reverse-DNS (PTR) lookups, providing clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_spf_record_checkerAFree public API. Look up and validate the SPF record for a domain. Counts void/total DNS lookups, flags syntax issues, validates against RFC 7208's 10-lookup limit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check SPF for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable context: it is a free public API, counts void/total DNS lookups, flags syntax issues, and validates against RFC 7208. This gives the agent insight into rate limits (public API) and the type of validation performed, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Free public API' and the core action. Every word earns its place, with no fluff or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description covers the core function and adds important behavioral details (DNS lookup counts, RFC validation), making it sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'domain' parameter described as 'Domain to check SPF for.' The description mentions 'domain' but adds no extra syntax or format details beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up and validate') and resource ('SPF record for a domain'), clearly distinguishing it from sibling tools like DKIM or DMARC checkers. The mention of RFC 7208 validation and DNS lookup counts further specifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it validates against RFC 7208's 10-lookup limit and counts void/total DNS lookups, which is specific to SPF checks. However, it does not explicitly state when not to use it or name alternatives, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_ssl_checkAFree public API. Check the TLS certificate of any public hostname. Returns issuer, subject, validity dates, days until expiry, full chain, cipher, protocol, and SAN list. No Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to check. Optionally with port, e.g. example.com:443. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive traits. The description adds 'Free public API' and 'No Bearer required', disclosing authentication needs, and enumerates return data (issuer, subject, validity dates, etc.), which is valuable since no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, front-loaded with the main action, followed by return fields and an authentication note. Every part adds value, and there is no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, return fields, and authentication. It could mention error handling for invalid hosts, but the annotations and schema provide sufficient context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of the host parameter, including the optional port example. The tool description does not add additional parameter-level meaning beyond confirming hostname scope. With 100% schema coverage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks TLS certificates of public hostnames, using the specific verb 'Check' and resource 'TLS certificate'. It lists return values, which distinguishes it from sibling DNS and web tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SSL/TLS certificate checks and notes it's a free public API with no Bearer required, providing clear context. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_subdomain_finderAFree public API. Enumerate subdomains for a target domain via Certificate Transparency logs + DNS resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Apex domain to enumerate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds the mechanism (CT logs + DNS resolution) and 'Free public API' status, giving the agent expectations about how results are gathered and potential limitations (e.g., reliance on CT logs). This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences conveying purpose, scope, and method with no redundant or filler content. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with comprehensive annotations, the description covers the essential context: what it does, how it does it, and a note on accessibility. It stops short of specifying the return format (e.g., list of subdomains with IPs), but this is 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'domain' parameter clearly described as 'Apex domain to enumerate.' The tool description mostly repeats 'target domain' and adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Enumerate') and resource ('subdomains') with a clear target ('a target domain') and method ('via Certificate Transparency logs + DNS resolution'). This uniquely distinguishes it from all sibling tools, which focus on individual record types, WHOIS, or status checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the tool: when subdomain enumeration is needed. It also notes it is a 'Free public API,' indicating no authentication barrier. While it does not explicitly mention alternatives or exclusions, the uniqueness among siblings makes the use case apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_txt_record_lookupAFree public API. Fetch all TXT records on a domain, classifying each as SPF, DKIM, DMARC, BIMI, verification token, or general.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to fetch TXT records for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context about the API being free and public, plus the classification behavior. It does not mention rate limits or potential response structures, but with annotation coverage, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence sets important context (free public API), and the second states the core action and classification detail. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete: it states the resource (TXT records), the scope (all records on a domain), and the classification categories. Combined with good annotations, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter 'domain' has a clear description. The tool description adds no extra parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches all TXT records for a domain and classifies them into specific types (SPF, DKIM, DMARC, BIMI, verification token, general). This distinguishes it from sibling tools that focus on individual record types or generic DNS lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comprehensive TXT record analysis with classification, which is a clear context. It does not explicitly mention when not to use or name alternatives, but the differentiating classification behavior makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_website_status_checkerAFree public API. Check if a website is up or down. Returns HTTP status, response time, final URL after redirects, basic SSL info.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check (include scheme). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it is a 'Free public API' (suggesting no auth needed and external network calls) and enumerates specific return fields, which is especially useful given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary action, and every word adds value: 'Free public API' sets expectations, and the output list directly informs the user. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (single required parameter), annotations cover safety, and the description lists all return values without an output schema. No missing information needed for successful invocation or interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single 'url' parameter, including the format and instruction to include scheme. The description does not add additional semantic details about the parameter beyond restating it implicitly through the tool's purpose, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with specific verbs: 'Check if a website is up or down' and lists concrete outputs (HTTP status, response time, final URL, SSL info). This distinguishes it from sibling tools focused on DNS, SSL, or headers, making its unique scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for general website status checks, but does not explicitly mention when not to use it or name alternatives like ssl_check or redirect_checker. However, the clarity of the stated purpose provides enough context for selection in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools_whois_lookupAFree public API. WHOIS / RDAP lookup for a domain — registrar, status, created/updated/expires dates, nameservers.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds 'Free public API', indicating no authentication complexity, and 'WHOIS / RDAP', showing protocol flexibility. This is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that front-loads the core action and lists key output fields. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the primary return data (registrar, status, dates, nameservers). It also notes that the API is free and public, making the tool's contract clear for a simple lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'domain' parameter with an adequate description. The tool description adds no extra detail about domain format or syntax, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'WHOIS / RDAP lookup for a domain' and enumerates output fields (registrar, status, created/updated/expires dates, nameservers). This clearly differentiates it from sibling DNS/domain tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying exactly what information will be returned, implying when it should be used. However, it lacks explicit exclusions or references to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
