Check a website's post-quantum TLS readiness (ML-KEM key exchange, certificate, grade)
Scored across 7 tools
Each tool has a clearly distinct role: scanning, reading evidence, methodology, service info, example output, order creation, and payment verification. The read-only evidence tool is explicitly separated from the scan-starting tool, and the paid order flow is split into order and verification steps with clear boundaries.
All tool names use a consistent snake_case verb_noun pattern: create_..., get_..., scan_..., verify_.... This makes intent predictable across informational, scanning, and payment tools.
Seven tools is well-scoped for a TLS evidence and paid-report workflow. Each tool serves a specific step: discovery, scanning, evidence retrieval, methodology, ordering, and payment verification.
The core lifecycle is covered: scan a hostname, retrieve evidence, understand methodology, create an order, verify payment, and receive a report URL. Minor gaps exist around order status/cancellation or listing prior scans, but agents can work around these through the returned report URL and existing evidence tools.
Create a one-time full-report order for an existing scan. This does not transfer funds. Only set consent_immediate_delivery true after the payer has expressly agreed to immediate delivery and applicable withdrawal terms. The payer must send USDT on Polygon and then submit its transaction hash using verify_full_report_payment.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | ID returned by scan_tls. | |
| consent_immediate_delivery | Yes | Set true only after the payer explicitly agrees to immediate delivery and the applicable withdrawal-right terms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world. The description adds genuinely non-redundant behavior: no funds move here, consent is a legal/compliance gate, and payment settlement happens elsewhere. It does not describe the created order's shape or whether retries create duplicate orders, which matters given idempotentHint=false.
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 tight sentences, each earning its place: purpose, safety clarification, consent gate, and next step. The consent sentence partially duplicates the schema description, which is justified by the legal stakes but is slight 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?
There is no output schema, so the description should indicate what the created order returns (payment address, amount, expiry), and it does not. Workflow and constraints are otherwise complete for this two-parameter 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% and both parameters are documented in the schema, so the baseline is 3. The description restates the consent condition with the same meaning as the schema's property description rather than adding new semantics such as format, sourcing, or constraints.
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?
Specific verb and resource ("Create a one-time full-report order") scoped to "an existing scan," plus an explicit negative clarification ("This does not transfer funds") and a named follow-up sibling (verify_full_report_payment). An agent can distinguish this from the verification step without inspecting either schema.
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 the precondition (existing scan, scan_id from scan_tls), the payer's obligation (send USDT on Polygon), the required consent gate, and the exact next tool to call with the transaction hash. Both when-to-use and the downstream alternative are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an explicitly labeled archived example, not live telemetry. No payment and no network scan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, so the safety profile is covered. The description adds value beyond that by disclosing that the payload is an archived, explicitly labeled example rather than fresh data, and that it requires no payment and performs no network scan — meaningful behavioral context for an agent deciding whether the data is trustworthy.
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, front-loaded with the positive statement of what is returned and immediately qualified by the exclusion. There is no padding or repetition of the name or title.
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 parameters, no output schema, and full annotation coverage, the remaining burden is small: the description establishes content type and provenance. It could say a bit more about the shape of the example payload, but nothing essential for correct invocation 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?
The tool takes zero parameters and the schema is a closed empty object, so there is no parameter meaning to convey. The baseline of 4 applies; the description correctly implies no inputs are needed.
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 gives a concrete verb and resource ('Return an ... archived example') and immediately negates the likely wrong interpretation ('not live telemetry'), which separates it from the live-data siblings like scan_tls and get_tls_evidence. It stops short of naming a specific alternative tool, so it is clear but not fully sibling-differentiated.
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?
Saying 'not live telemetry' implies this is the fallback/static path rather than a scan, and 'no payment and no network scan' clarifies prerequisites. However, it never states the condition under which an agent should choose this over the sibling tools, leaving the when-to-use decision implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the documented measurement scope, observation states, certificate-grade rules and privacy limitations before interpreting a TLS result.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe, read-only, idempotent, closed-world profile, so the description's job is to add content-level context — which it does by naming the four categories of documentation returned. It does not say whether the output is free text or structured, nor how large it is, but for a zero-parameter documentation fetch the added context is solid.
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 front-loaded sentence that immediately establishes what is retrieved and when to retrieve it. Every clause carries information; no 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 parameters, no output schema, and full annotation coverage, the description covers what the agent needs: what content comes back and how to use it. The only minor gap is that it doesn't characterize the return shape (static prose vs. structured rules), which matters slightly since there is no output schema.
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 tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies no arguments are needed.
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 gives a specific verb ('Get') and enumerates the exact resource contents: measurement scope, observation states, certificate-grade rules, and privacy limitations. That is enough to distinguish it from get_tls_evidence (raw evidence) and get_service_info, though it never names a sibling explicitly.
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?
It states a clear usage condition — call this 'before interpreting a TLS result' — which is a genuine when-to-use cue. It stops short of naming explicit alternatives or saying when the tool is unnecessary (e.g. once the methodology is already known).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live endpoints, quotas, report price, x402 Base USDC checkout status and limitations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds useful context by labeling the data 'live' and flagging that limitations are returned, but it says nothing about how volatile pricing/checkout status is or whether quotas are per-key or global.
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 front-loaded sentence with no filler or restated title. It loses a point because the dense jargon ('x402 Base USDC checkout status') and the unqualified 'limitations' compress meaning an agent may not be able to parse without prior context.
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 and no parameters, the description carries the burden of telling the agent what comes back, and it does enumerate the return categories (endpoints, quotas, price, payment status, limitations). It stops short of any shape or ordering hint, which leaves the agent guessing at structure on first call.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is closed (additionalProperties false) and consistent with the parameterless call described.
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 gives a specific verb (Get) and enumerates the resource contents: endpoints, quotas, report price, checkout status, and limitations. It is clearly a capability-discovery tool and distinguishable in spirit from action tools like create_full_report_order or scan_tls, but it never names or rules out a sibling, so differentiation is left to inference.
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?
Usage is implied rather than stated: an agent can infer it should call this when it needs pricing, quotas, or payment status. There is no explicit when-to-use framing, no mention of calling it before purchase/verification flows, and no pointer to get_methodology or get_example_result as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read existing TLS evidence with source, checked_at, expires_at and fresh/stale/undetermined/not_scanned state. Never starts a new network scan. A missing record is not proof that a domain is unsafe.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public DNS hostname, for example example.com. HTTPS port 443 only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description still adds real behavioral context beyond them: it will not start a network scan and, importantly, that a missing record is not proof a domain is unsafe — a caveat an agent needs to avoid drawing wrong conclusions.
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 sentences, front-loaded with the core purpose, then the behavioral exclusion, then the interpretation caveat. Every sentence carries information and nothing is padded.
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 tool with no output schema, the description supplies the returned fields and the stale/undetermined/not_scanned state vocabulary plus the missing-record caveat. An agent has everything needed to call it and interpret the result.
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 full 100% description coverage for the single 'domain' parameter, including the HTTPS-443-only constraint, so the description adds no parameter meaning. The fields it lists (checked_at, expires_at, states) are return values rather than parameter semantics, so the 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 opens with a specific verb+resource ('Read existing TLS evidence') and enumerates the fields returned (source, checked_at, expires_at, and the four states). It also distinguishes itself from the scanning sibling via 'Never starts a new network scan', so an agent can tell it apart from scan_tls without opening a schema.
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?
Usage is clearly implied — read already-stored evidence — and there is an explicit exclusion: it never triggers a new scan, which routes scan-triggering intent to scan_tls. It stops short of naming scan_tls or spelling out the 'if you need fresh data, use X' condition, so it is not fully 5-level routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a new, rate-limited TLS scan of a public hostname on port 443. Returns observation_status, measured time, negotiated group and certificate summary. Starts an external connection and stores a publicly accessible result. Does not judge application safety.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public DNS hostname, for example example.com. HTTPS port 443 only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true, readOnlyHint=false and idempotentHint=false, but the description adds genuinely new behavioral facts: the scan is rate-limited, it opens an external connection, and it stores a publicly accessible result — a non-obvious privacy/data-persistence consequence. It also enumerates what is returned (observation_status, measured time, negotiated group, certificate summary), which matters since no output schema exists. It stops short of stating auth requirements or how rate limiting manifests (errors vs. throttling).
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?
Four short sentences, front-loaded with the action and immediately followed by the return payload and then the behavioral caveats. Nearly every clause earns its place; only the port-443 restatement slightly duplicates the schema.
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 one-parameter tool with no output schema, the description covers action, return fields, rate limiting, external connection, public result storage, and scope limits — enough for correct invocation. It leaves out failure behavior (invalid hostname, rate-limit rejection) and any latency expectation, which are the only material 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 coverage is 100% for the single 'domain' parameter, and the schema already specifies 'Public DNS hostname, for example example.com. HTTPS port 443 only.' The description repeats the public-hostname and port-443 constraint without adding format or validation detail, so the schema is doing the work and the 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 gives a specific verb and resource: 'Run a new, rate-limited TLS scan of a public hostname on port 443.' The word 'new' plus the enumerated return fields makes it distinguishable from retrieval siblings such as get_tls_evidence and get_example_result, and the closing scope line ('Does not judge application safety') bounds what it is not.
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?
Usage is only implied: 'Run a new' suggests this is the tool for producing a fresh measurement rather than reading existing evidence, and the port-443/public-hostname constraints implicitly exclude internal targets. However, no sibling is named, and there is no explicit statement of when to call this versus get_tls_evidence or when a full report order is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the payer-provided Polygon transaction hash. The server checks the confirmed USDT transfer, exact order amount and recipient on chain. Returns the private report URL only after confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | ||
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety and external-call profile is covered. The description adds genuine context beyond that: the server checks the confirmed USDT transfer, exact amount, and recipient on-chain, and only returns the URL after confirmation. It omits failure behavior and response shape on mismatch.
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: action, server verification, and outcome. No wasted wording, though the transition between tx hash and order linkage could be sharper.
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 2-parameter verification tool with no output schema, the description covers the core flow and the confirmation condition. It lacks the order_id/tx_hash relationship and post-verification failure behavior, leaving some gaps for an agent handling edge cases.
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 0%, so the schema only supplies types and a hash pattern. The description gives meaning to tx_hash as the payer-provided Polygon transaction hash but does not explain order_id's role or that the hash must match the order's exact amount and recipient — the critical linking semantics.
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 names a specific verb (submit) and resource (payer-provided Polygon transaction hash) and states the outcome (return private report URL after confirmation). It is clearly distinct from siblings such as scan_tls or get_methodology, though it doesn't explicitly reference them.
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?
Usage is implied: call after the payer supplies a Polygon tx hash to unlock a paid report. There are no explicit when-not conditions, no mention that an order must exist first (via create_full_report_order), and no guidance on what to do if verification fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_full_report_orderget_example_resultget_methodologyget_service_infoget_tls_evidencescan_tlsverify_full_report_paymentInspects live IPv4/IPv6 DNS resolution, TLS certificate issuer/expiry, and HTTP security grade.
Inspects live IPv4/IPv6 DNS resolution, TLS certificate issuer/expiry, and HTTP security grade.
Passive checks of a public website: email authentication (SPF, DKIM, DMARC) and basic security.
Free SSL/TLS certificate checker: expiry, chain trust, hostname match, TLS version, A/B/C/F grade.
Add one secure layer between your agents and this server.
