TLS Radar
Server Details
SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 17 of 17 tools scored. Lowest: 3.6/5.
Most tools have clearly distinct purposes (monitoring, issuance, scanning, account, team). Minor overlap exists between create_certificate and renew_certificate depending on order_id availability, but descriptions clarify. The obsolete register_beacon_order is clearly marked.
All tools follow a consistent verb_noun snake_case pattern (e.g., add_monitor, list_monitors, finalize_certificate). No mixing of styles or vague verbs.
17 tools cover the full scope of certificate monitoring, issuance, scanning, account, and team management without feeling overwhelming or sparse.
The tool set covers the entire lifecycle: create, monitor, renew, remove, list, scan, import/export, account, team. Minor missing functionality (e.g., update monitor) is not critical for the domain.
Available Tools
17 toolsadd_monitorAIdempotentInspect
Add a domain to ongoing certificate monitoring with expiry alerts. Requires authentication (the user runs /mcp once).
If the plan's monitor limit is reached, the response's structuredContent carries a limit-reached payload - when relaying it, LEAD with recommended_upgrade (typically Starter, $9.99/mo), mention also_available tiers in a single closing line, and offer removing an existing monitor as the free alternative. Don't dump a full tier comparison; that's choice paralysis at the moment of action.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Hostname to monitor (e.g. example.com). No scheme, no path. |
Output Schema
| Name | Required | Description |
|---|---|---|
| address | No | |
| host_id | No | |
| team_id | No | |
| scan_group_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: describes authentication needed and the specific structuredContent payload for limit-reached cases. Annotations already indicate idempotentHint=true and readOnlyHint=false, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. The third sentence is detailed but necessary for handling edge cases. Efficient overall.
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 (1 param, output schema present), the description covers purpose, prerequisites, and error handling comprehensively. No gaps.
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 provides 100% coverage with clear description of the single parameter 'domain', and the description adds valuable formatting instruction ('No scheme, no path'). No ambiguity.
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 clearly states the verb 'Add' and resource 'domain' with specific purpose 'ongoing certificate monitoring with expiry alerts'. Differentiates from siblings like remove_monitor and list_monitors.
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 mentions authentication requirement and provides detailed guidance on handling plan limit scenarios, including how to present upgrade options. Missing explicit when-not-to-use scenarios, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_monitorsAIdempotentInspect
Add multiple domains to monitoring in one call. Returns a per-domain status so the caller can show partial-success outcomes. Honors the same plan-limit checks as add_monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | List of hostnames to monitor |
Output Schema
| Name | Required | Description |
|---|---|---|
| added | Yes | |
| results | Yes | Per-domain add status. |
| team_id | No | |
| requested | Yes | |
| scan_group_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description reveals that the tool returns per-domain status for partial success and enforces plan-limit checks. This adds valuable behavioral context not present in structured fields.
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-loaded with the primary action, and contains no unnecessary information. Every sentence adds 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 existence of an output schema (not shown), the description adequately covers tool purpose, behavior, and constraints. It references sibling add_monitor for alignment and mentions plan-limit checks, providing sufficient context for an agent.
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 a description for the 'domains' parameter. The tool description does not add further details about parameter meaning beyond restating the purpose; it is at the baseline for full 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 verb 'Add', the resource 'multiple domains to monitoring', and distinguishes from the sibling 'add_monitor' by focusing on batch operation. It also mentions returning per-domain status for partial success, which adds specificity.
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 says it 'Honors the same plan-limit checks as add_monitor', providing context about constraints. It implies use when adding multiple domains at once, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_certificate_propagationARead-onlyIdempotentInspect
Check whether the DNS TXT records for a certificate order have propagated (Cloudflare/Google/Quad9). Step 2 of issuance - poll until all_found is true, then call finalize_certificate. Returns per-record resolver results.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order_id from create_certificate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| records | No | Per-record propagation status. |
| all_found | No | True when every challenge record/file is in place. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, idempotentHint, openWorldHint. Description adds that it polls, returns per-record resolver results, and is non-destructive. No contradiction. Provides context beyond 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 concise sentences: first states purpose and DNS providers, second clarifies polling and next step. No redundant information, well-structured for quick understanding.
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 check tool with one parameter and an output schema, the description covers purpose, usage context, and next steps. Could mention return format briefly, but output schema handles that. Completeness is high.
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%, so baseline 3. The description does not add extra detail for the single parameter beyond what the schema says ('The order_id from create_certificate'), but it is consistent and adequate.
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 DNS TXT propagation for a certificate order, specifies it is step 2 of issuance, and distinguishes it from siblings like create_certificate and finalize_certificate. The verb 'Check' and resource 'propagation' are specific.
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 says when to use: 'Step 2 of issuance - poll until all_found is true, then call finalize_certificate'. It implies the sequence after create_certificate and before finalize_certificate. Could mention when not to use (e.g., not before creation), but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_certificateAInspect
Start issuing a FREE 90-day Let's Encrypt certificate for a domain (no account required). Step 1 of 3.
Pick a validation method with challenge: "dns-01" (default; publish a TXT record; covers apex + www) or "http-01" (serve a file over HTTP on port 80; issues the exact domain only). dns-01 with a DNS-provider API token is the most automatable; http-01 suits a server you control on port 80.
Returns an order_id plus either dns_records (dns-01) or http_files (http-01) to put in place. Next: poll check_certificate_propagation until all_found, then call finalize_certificate.
Strongly prefer the CSR path at finalize (the private key never leaves the user's machine). Issuing automatically offers the user ongoing monitoring by email once it completes - don't add a monitor manually afterward.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Contact email for Let's Encrypt expiry notices and the monitoring handoff. | ||
| domain | Yes | Apex domain, no scheme/www (e.g. example.com). | |
| challenge | No | Validation method: dns-01 (default) or http-01. | |
| client_id | No | Optional anonymous install id from ~/.config/tlsradar/install_id (funnel attribution). If omitted, the response's install_id is a fresh one to save there. | |
| marketing_consent | No | Only true if the user explicitly opts in to a free account + reminder email. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| order_id | Yes | |
| challenge | Yes | |
| http_files | No | Files to serve for http-01. |
| install_id | No | |
| dns_records | No | TXT records to publish for dns-01. |
| next_action | No | |
| resume_token | No | Signed token to finalize past the backend's order TTL. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: it reveals multi-step process, returns order_id and records/files, and mentions automatic monitoring. Annotations already indicate non-readonly (false) and non-destructive (false), which aligns.
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?
Description is informative and well-structured but slightly verbose. It front-loads the main purpose and uses clear steps, though some sentences could be trimmed without losing 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 multi-step process and complexity of certificate issuance, the description covers all essential aspects: validation methods, what the tool returns, next steps, and caveats. Output schema exists, so return values are not required to be detailed here.
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%, but description adds significant meaning: explains challenge methods in detail, clarifies client_id and marketing_consent purpose, and provides real-world context for parameter choices.
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 clearly states it starts issuing a free 90-day Let's Encrypt certificate, step 1 of 3, distinguishing it from sibling tools like finalize_certificate and check_certificate_propagation.
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 explains when to use this tool, how to choose between dns-01 and http-01, and provides clear next steps (poll, then finalize). It also advises against adding a manual monitor because the tool handles it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_monitorsARead-onlyIdempotentInspect
Dump the user's monitors as a JSON structure suitable for backup, migration, or infrastructure-as-code workflows. Tokens and PII are NEVER included - only domain configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| teams | Yes | |
| version | Yes | |
| exported_at | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds critical behavioral details: 'Tokens and PII are NEVER included - only domain configuration,' which is beyond what annotations provide.
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, no redundancy, front-loaded with the action and output format. Every sentence adds 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 no parameters, an output schema exists, and annotations cover safety, the description fully covers the tool's behavior and output guarantees. No gaps for an agent.
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?
No parameters exist, so the description does not need to add parameter meaning. Baseline score of 4 applies as the description is clear about the tool's purpose.
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 exports monitors as JSON for backup/migration/IaC. It distinguishes from sibling tools like 'list_monitors' (viewing) and 'import_monitors' (import).
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 specifies use cases: backup, migration, and infrastructure-as-code. It implies when to use this tool over alternatives but does not explicitly exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
finalize_certificateAIdempotentInspect
Finalize and issue a certificate order in one call: validates the DNS challenges, waits for Let's Encrypt, and returns the issued cert. Step 3 of issuance - call after check_certificate_propagation reports all_found.
STRONGLY PREFER passing csr_pem (generate the key + CSR locally with openssl so the private key never leaves the machine). Returns leaf_pem/chain_pem/fullchain_pem. If you must, pass a passphrase instead to get a PKCS#12 bundle - but a CSR is safer.
If it replies "still validating", DNS hasn't fully propagated: re-check check_certificate_propagation and call again.
Needs a locally-generated CSR (csr_pem) - requires a local shell with openssl. On a surface without one (e.g. a Claude.ai custom connector) this can't complete; it returns guidance to finish in Claude Code/Cowork or the web form. Scanning and monitoring work everywhere.
On success the structuredContent carries a handoff object - relay handoff.message to the user and do NOT separately call add_monitor; the cert→monitoring handoff is automatic and server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| csr_pem | No | PEM CERTIFICATE REQUEST covering exactly {domain, www.domain}. Preferred - key stays local. | |
| order_id | Yes | The order_id from create_certificate. | |
| passphrase | No | Fallback only: ≥8 chars, protects a returned PKCS#12 bundle. Omit when using csr_pem. | |
| resume_token | No | Optional. The resume_token from create_certificate; pass it to finalize an order whose row Beacon already purged (~24h). | |
| max_wait_seconds | No | How long to wait for validation server-side. Default 60, capped at 75. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | No | |
| state | No | |
| handoff | No | Cert->monitoring handoff; relay handoff.message and do not call add_monitor. |
| leaf_pem | No | |
| chain_pem | No | |
| not_after | No | |
| fullchain_pem | No | Full certificate chain (PEM), present on success. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: describes validation, waiting for Let's Encrypt, return values, retry behavior, and server-side handoff. Annotations are minimal (no destructive/readOnly hints beyond false) so description carries full burden and excels.
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?
Slightly verbose but front-loaded with main purpose. Every sentence adds value; minor structure improvement could group related info more tightly.
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?
Covers all aspects: prerequisites, usage, error recovery, environment limits, return value format, and automatic monitoring handoff. With an output schema present, the description is fully 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?
Schema coverage is 100% and the description adds important context: preference for csr_pem (key stays local), origin of order_id, explanation of resume_token for purged orders, and max_wait_seconds limits.
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 'Finalize and issue', identifies the resource 'certificate order', and specifies it is step 3, distinguishing it from sibling tools like create_certificate and check_certificate_propagation.
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?
Provides explicit when-to-use: 'call after check_certificate_propagation reports all_found'. Also gives alternatives (CSR vs passphrase), error handling ('still validating'), environment requirements (local shell), and a warning not to separately call add_monitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountARead-onlyIdempotentInspect
Return the current user's plan, limits, and usage so the client can render upgrade nudges proactively.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| plan | No | Plan tier and limits. |
| Yes | ||
| usage | No | Current usage against the plan limits. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description does not need to repeat those. The description adds business context but no additional behavioral traits (e.g., caching, rate limits), which is acceptable for a simple read-only tool.
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 that front-loads the action and resource, followed by the purpose. No unnecessary words; highly 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 zero-parameter, read-only tool with output schema, the description fully conveys what it does and why. No gaps in context.
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?
Input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. 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 specifies the verb 'Return' and the resource 'current user's plan, limits, and usage' with a clear business purpose ('so the client can render upgrade nudges proactively'). This clearly distinguishes it from sibling tools focused on monitors and certificates.
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 its usage context (when account-level info is needed) but does not explicitly state when not to use or provide alternatives. However, given the sibling set, the tool's purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_certificate_statusARead-onlyIdempotentInspect
Return the current state of a certificate order (dns_pending, validating, ready, completed, failed) and per-authorization Let's Encrypt statuses. Use it to resume an interrupted issuance.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order_id from create_certificate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| challenge | No | |
| fullchain_pem | No | Present once the order is completed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds behavioral context by specifying the returned states (dns_pending, validating, ready, completed, failed) and per-authorization statuses, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core functionality and a usage hint. Every word earns its place; no redundancy or fluff.
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 one parameter, rich annotations, and an output schema (though not shown, it's indicated), the description is sufficient. It clearly explains the tool's purpose and usage context, making it complete for an AI agent.
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%, but the description adds meaning by specifying that the 'order_id' parameter comes from 'create_certificate' and by listing the returned states, which clarifies the parameter's role in fetching status.
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 it returns the current state of a certificate order, listing possible states and per-authorization statuses. It uses the specific verb 'Return' and identifies the resource as 'certificate order status', distinguishing it from sibling tools like 'check_certificate_propagation' or 'create_certificate'.
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 explicitly says 'Use it to resume an interrupted issuance', providing clear when-to-use guidance. While it doesn't explicitly state when not to use it, the context of resumption and the sibling tool set make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scan_historyARead-onlyIdempotentInspect
Return recent scan results for a domain the user monitors. Useful for spotting issuer changes, grade drops, or vulnerability appearances over time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return | |
| domain | Yes | Domain name as it appears in list_monitors |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| domain | Yes | |
| results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and idempotent behavior. The description adds context about returning 'recent' results for monitored domains, but does not elaborate on what 'recent means or any pagination limits. It partially compensates for the lack of annotation detail.
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 provide all necessary information without redundancy. Every word adds 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?
The description is complete for a read-only query tool with an output schema (not shown). It covers what the tool does and its typical use cases, but could briefly mention the optional limit parameter or the concept of historical data.
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%, so the schema fully documents both parameters. The description adds no additional details beyond mentioning 'domain the user monitors' which is already in the schema. Baseline score 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?
Clear verb 'Return' and resource 'recent scan results' are specified, with explicit use cases (issuer changes, grade drops, vulnerability appearances) that distinguish it from siblings like scan_domain (which initiates scans) or list_monitors (which lists domains).
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 mentions it is 'useful for spotting' specific changes, providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_monitorsAIdempotentInspect
Create monitors from a JSON structure (typically produced by export). Skips domains the user is already monitoring; honors the plan's domain limit. Returns a per-domain status.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Export payload, version 1.0. Use the `export` tool to generate one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| added | No | |
| results | No | Per-domain import status. |
| requested | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: skips existing domains, honors domain limit, returns per-domain status. No contradiction with annotations (idempotentHint=true).
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 convey the purpose, source, and behavior with no waste. Front-loaded with action and key 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?
Given the simple parameter structure and existence of output schema, the description covers essential details: source of input, duplicate handling, limit enforcement, and return status.
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%, and the description adds no additional meaning beyond the schema's own description of the payload 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?
Clearly states the tool creates monitors from a JSON structure produced by export, which is a specific verb-resource pair. Differentiates from siblings like add_monitor (single) by implying batch import.
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?
Mentions that the input is typically from the export tool, giving context for when to use it. However, does not explicitly contrast with alternatives like add_monitor for single additions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invite_team_memberAInspect
Invite a user to a team by email. Defaults to the user's current team. Honors the plan's seat limit (returns the same upgrade payload as add_monitor when the cap is hit).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Invitee role: guest or admin. Defaults to guest. | guest |
| Yes | Email address of the person to invite | ||
| team_id | No | Team UUID; defaults to the current team |
Output Schema
| Name | Required | Description |
|---|---|---|
| role | Yes | |
| team_id | Yes | |
| team_name | No | |
| invited_email | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=true? Actually readOnlyHint=false, so mutation). Description adds critical detail: returns upgrade payload on seat limit hit, which mirrors add_monitor behavior. No contradictions.
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, highly efficient. First sentence states purpose and mechanism; second adds important behavioral constraint. No冗余.
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?
Covers purpose, default behavior, and seat limit behavior. Does not mention prerequisites (e.g., authorization) or duplicate invite handling, but output schema exists so return value clarity is not required.
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%, baseline 3. Description adds 'by email' and 'defaults to current team', reinforcing parameter context beyond schema definitions.
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?
Clear verb 'Invite' with specific resource 'a user to a team' and mechanism 'by email'. Distinct from sibling tools, all of which deal with monitors or certificates.
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?
States default behavior ('Defaults to the user's current team') and edge case ('Honors the plan's seat limit...'). No explicit when-not-to-use, but siblings offer no direct alternative for inviting team members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_expiring_certificatesARead-onlyIdempotentInspect
Return monitored certificates expiring within N days. Defaults to 30.
If the response's structuredContent includes a nudge object, the user is watching enough soon-to-expire certs to benefit from a higher tier - mention it casually ONCE (lead with nudge.recommended_upgrade); skip it if it doesn't fit.
| Name | Required | Description | Default |
|---|---|---|---|
| within | No | Days from now to look ahead |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| nudge | No | Present only when an upgrade nudge is warranted. |
| entries | Yes | |
| within_days | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, covering safety. The description adds valuable context about the nudge behavior in the response, which is beyond what annotations provide. No contradictions.
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 concise with two sentences. The main functionality is front-loaded. The second sentence is a bit long but necessary for the conditional behavior.
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 output schema exists, the description adequately covers the input parameter and the special response handling. No gaps for this simple tool.
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 has 100% coverage and the description only restates the parameter's existence and default. No additional semantic meaning is added beyond the schema.
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 it returns monitored certificates expiring within N days, with a default of 30. However, it does not explicitly differentiate from sibling tools like list_monitors, which might list all monitors.
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 lacks guidance on when to use this tool versus alternatives. It only gives a conditional instruction about handling the nudge object, not context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsARead-onlyIdempotentInspect
List all certificates currently being monitored across the user's teams.
If the response's structuredContent includes a nudge object, the user is at their monitor cap - surface it casually ONCE (lead with nudge.recommended_upgrade, mention nudge.also_available in one closing line); don't force it if it doesn't fit the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| nudge | No | Present only when an upgrade nudge is warranted. |
| monitors | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and idempotent. Description adds handling for the nudge object in structuredContent and scope across user's teams, which is beyond 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: first states purpose, second provides necessary handling instruction. No wasted 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?
Complete for a list tool with no parameters and annotations. Output schema exists for return details, so no need to describe 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?
No parameters, so description does not need to add param info. Schema coverage 100%, baseline 4.
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?
Clear verb 'list' and resource 'certificates being monitored' distinguished from sibling tools like add_monitor, export_monitors.
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 explicit when-to-use or when-not-to-use guidance, but context of listing team monitors is implied. Lacks alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_beacon_orderAIdempotentInspect
OBSOLETE - do not call. The cert→monitoring handoff is server-side now (issue via create_certificate, which records the order itself). This tool is kept only so old plugin versions that still call it don't error; it remains idempotent and harmless.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Contact email the user gave Beacon | ||
| domain | Yes | Domain the cert was requested for | |
| order_id | Yes | The order_id from beacon.create_order | |
| webhook_secret | No | Per-order HMAC secret Beacon returned (used to verify the subsequent webhook). Optional - without it, this server can't verify webhooks for the order and will drop them. |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| order_id | Yes | |
| registered | Yes | |
| has_webhook_secret | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates idempotentHint=true, and the description reinforces that the tool is 'idempotent and harmless'. It also discloses the reason for its existence (supporting old plugins) and that the handoff is now server-side, providing full behavioral context beyond 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 clearly stating obsolescence, the reason, and the alternative. It is front-loaded with the key warning and contains 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?
Given that the tool is deprecated and has an output schema, the description is complete. It explains why it exists, why not to use it, and that it is safe. No missing information for an agent to make a decision.
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 each parameter described. The description adds minimal extra parameter detail, only noting that webhook_secret is optional and its consequence. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 is obsolete, with an explicit 'do not call' and explanation that it registers a beacon order. It also names the replacement tool, making the purpose unmistakable.
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 explicitly advises against using this tool and directs to create_certificate instead. It explains why it exists (backward compatibility) and that it should not be called for new operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_monitorADestructiveIdempotentInspect
Stop monitoring a domain. Accepts the domain name or the host_id returned by list_monitors.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to stop monitoring | |
| host_id | No | UUID of the host (alternative to domain) |
Output Schema
| Name | Required | Description |
|---|---|---|
| removed_address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. Description adds that it accepts domain or host_id, which is useful behavior context. No contradiction with 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, action first, no redundant words. Efficiently conveys the tool's purpose and parameter options.
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 output schema (existence noted), description sufficiently covers what the tool does and acceptable inputs. Could mention idempotency but annotations cover that.
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% and both parameters have descriptions. Description restates the acceptable inputs but adds no additional semantics beyond the schema.
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?
Clearly states 'Stop monitoring a domain' with specific verb and resource. Distinguishes from sibling tools like add_monitor and list_monitors by focusing on removal.
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?
Implies usage (when you want to stop monitoring), but no explicit when-not or alternative tools. Siblings include only add_monitor and list_monitors, so context is clear but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
renew_certificateAInspect
Renew a certificate by cloning a recent order (requires the original order_id; Beacon purges orders after ~24h). Returns a new order_id and fresh DNS TXT records - then poll check_certificate_propagation and call finalize_certificate. If you don't have an order_id (the usual case at 90-day renewal time), call create_certificate for the domain instead; that IS the renewal.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The original order_id to clone. If you don't have one, use create_certificate instead. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| order_id | No | |
| challenge | No | |
| http_files | No | |
| dns_records | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write and non-idempotent behavior. The description adds valuable behavioral context: orders are purged after ~24h, requiring timely use, and the tool returns fresh DNS TXT records. It also implies the multi-step nature of the process. No contradiction with 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, consisting of two sentences. The first sentence states purpose, input, and output; the second provides usage guidance and alternative. No extraneous words or 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 tool with a simple signature (one required parameter) and existing output schema, the description covers the core workflow and next steps. It could mention error handling for expired order_ids, but the clarity and context provided are sufficient for an agent to use the tool appropriately.
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 a clear description of order_id. The description adds context beyond the schema: it explains that order_id is obtained from a recent order and suggests using create_certificate if unavailable. This extra information aids correct parameter selection.
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 purpose: renew a certificate by cloning a recent order. It specifies the required input (order_id), the output (new order_id and DNS TXT records), and distinguishes this tool from create_certificate for the common case when no order_id is available.
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 explicit guidance on when to use this tool vs. create_certificate, including the condition of order_id availability and the typical renewal scenario. It also outlines the follow-up steps (poll check_certificate_propagation and call finalize_certificate), giving clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_domainARead-onlyInspect
Run a free, anonymous SSL/TLS scan against a hostname and return certificate details. No account required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Hostname to scan (e.g. example.com). No scheme, no path. | |
| client_id | No | Optional anonymous install id from ~/.config/tlsradar/install_id. Pass it for funnel attribution. If you omit it, the response's install_id is a fresh one to save there. |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| status | Yes | |
| share_url | Yes | |
| install_id | No | Anonymous install id to persist locally and reuse. |
| scanned_at | No | |
| share_token | Yes | |
| expiration_date | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by confirming the scan is free, anonymous, and requires no account, which clarifies the authentication and cost model. This goes beyond the annotations' safety indicators, providing concrete 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?
Two short sentences that are front-loaded with the core action. Every word is functional: 'Run a free, anonymous SSL/TLS scan against a hostname and return certificate details. No account required.' No filler or redundancy.
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 description covers the essential purpose and distinguishes usage style (free, no account). With annotations and an output schema present, the agent can infer safety and response structure. It lacks mention of potential constraints (e.g., public domain only), but is sufficient for a simple scanning tool.
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 clear descriptions for both parameters (domain and client_id). The description does not add new semantic meaning beyond reinforcing that the domain is a hostname and the scan is anonymous. 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 states the action ('Run a free, anonymous SSL/TLS scan'), the target ('a hostname'), and the result ('return certificate details'). It distinctly differentiates from sibling tools like check_certificate_propagation or get_certificate_status by emphasizing anonymity and no account requirement.
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 no explicit guidance on when to use this tool versus alternatives. While it implies a quick, anonymous scan, it does not mention related tools like get_certificate_status or check_certificate_propagation for comparison, nor does it state any prerequisites or limitations (e.g., public hostname only).
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.
Discussions
No comments yet. Be the first to start the discussion!