01Safety
0.0 / 30
What changed in the harness
Selection accuracy 96→98, token cost down 0%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
27.6 / 30
03Economics
18.8 / 20
04Discoverability
17.2 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
1 defect found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
ip_info |
no_return_description |
Report the caller's own public IP as seen by the server. Takes no input — it reflects the egress IP of THIS MCP server's network, which is usually NOT the end user's IP. Use this to discover the server's outbound IP or test connectivity; to inspect a specific known IP, use asn_lookup or reverse_dns. Read-only; requires no API key; rate-limited. Returns a text report containing the IPv4/IPv6 address, ISP, ASN, approximate geolocation, and proxy/VPN heuristics. |
Selection evidence
Confusable tool pairs.
5 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
dns_lookup |
dns_propagation |
medium | Both take a domain and return DNS record values; a task like 'check the DNS records for example.com' or 'did my DNS record update?' could reach either. The descriptions try to disambiguate (single authoritative answer vs. multi-resolver comparison, 'right after a change'), but without that context an agent may pick the propagation tool for a plain record query or the lookup tool right after a DNS change. |
dns_lookup |
whois_lookup |
medium | Both accept the same domain input and both can report nameservers, so a generic task such as 'tell me about example.com' or 'what are the nameservers for example.com' is genuinely ambiguous between live DNS records and registration/ownership data. The ownership-vs-records distinction is a subtle semantic the agent must infer rather than something the input schema reveals. |
http_security |
security_scan |
medium | A task like 'check the security of example.com' or 'audit example.com for security issues' is ambiguous: http_security audits HTTP security headers with an A-F grade, while security_scan runs a comprehensive audit that includes the header check. Both accept similar domain/URL inputs, and only reading the descriptions closely (header posture vs. full-domain default starting point) resolves the choice. |
port_scan |
security_scan |
medium | A task such as 'scan example.com' or 'is my server secure/exposed?' could trigger either tool: security_scan explicitly includes an active port_scan of the host, while port_scan is the focused service-exposure check. Without an explicit phrase like 'which ports are open' or 'full health score', the agent may pick the specialized scan when a full audit was wanted, or vice versa. |
email_auth |
email_header_analysis |
medium | Tasks like 'did my email pass SPF/DKIM/DMARC', 'why did my email get flagged as spam', or 'check email authentication' are genuinely ambiguous: email_auth assesses a domain's sending config (takes a domain), while email_header_analysis parses a delivered message's headers (takes raw header text) to report per-mechanism auth results. The domain-vs-message distinction is the only separator and is easy for an agent to miss in natural wording. |
Compare the field