Scan a domain's TLS configuration and return structured JSON with grade, key-exchange group, post-quantum key-exchange status, certificate key, and scan details.
Same scan as scan_tls but returns the structured result (grade, key_exchange_group, post_quantum_key_exchange, certificate_key, scan_url, full_report_price, scan_id).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the whole burden. It discloses the return fields (including full_report_price and scan_id, which hints at a paid upsell path), but says nothing about whether the scan is read-only/safe, latency, failure modes, or rate limits for a network-facing 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?
A single front-loaded sentence with no filler; the sibling comparison comes first and the field list second. The parenthetical is long but each item is informational.
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, listing the returned fields is the right compensation and is done well. However, for a scanning tool the description never says what is scanned (TLS configuration, handshake, certificate), whether the call is costly or rate-limited, or how full_report_price relates to buy_full_report, leaving notable 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?
Only one parameter, domain, with 0% schema description coverage. The name is largely self-explanatory, but the description adds no detail on accepted formats (bare hostname vs. URL, port, IDN) or what a scan covers for that domain.
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?
Names the sibling scan_tls explicitly and states the differentiator: it returns the structured result rather than (implicitly) a raw one. The parenthetical enumerates the returned fields, so the agent knows the shape of the payoff. It stops short of a clean verb+resource statement of what the scan itself checks, but the contrast with scan_tls gives a usable 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?
The definition effectively says when to pick this over scan_tls — when you want the structured grade/key-exchange/certificate fields. There is no negative guidance (no exclusions, no note on when the raw variant is preferable or whether the scan is free).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.