TLS certificate issuer / validity / SAN summary sourced from public Certificate-Transparency logs (crt.sh JSON). Picks the freshest leaf and reports currentlyValid + daysUntilExpiry. Read-only; price 0.0 (free).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only nature and zero cost, which is helpful for safe invocation. It mentions the source and selection logic (freshest leaf). However, it does not cover potential error conditions (e.g., domain not found), rate limits, or authentication requirements, leaving gaps for the agent.
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 with no filler. The first sentence establishes core purpose and source, the second adds specific output details and cost/read-only reminder. Information is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: source, selection logic, key output fields, and safety/cost. However, without an output schema, it does not fully describe the return structure (e.g., format of SAN summary, data types). A slightly more detailed output description would elevate completeness to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'domain', which is described as 'Domain name to inspect'. The tool description does not add additional semantics beyond the schema, such as format expectations or validation rules. A baseline score of 3 is appropriate since the schema already suffices.
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 provides TLS certificate issuer, validity, and SAN summary from public Certificate-Transparency logs. It specifies the data source (crt.sh JSON) and key output fields (currentlyValid, daysUntilExpiry). This distinctly differentiates it from sibling domain intelligence tools like DNS lookup or whois summary.
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 the tool is for TLS certificate inspection but does not explicitly state when to use it versus alternatives. There are no usage exclusions or comparisons to other domain intel tools. While the context is clear, explicit guidance on when not to use it or which sibling to choose instead is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly distinguished by domain prefixes (e.g., bid_watch, grant_watch) and specific action verbs. However, the high number of similarly structured watch tools could still cause confusion, though descriptions clarify exact purposes.
Every tool follows a consistent `domain_subdomain_action` pattern with underscores, e.g., `agent_audit_query`, `bid_watch_search`. Even long names like `commerce_catalog_agent_readiness_score` adhere to this structure.
With 147 tools, the server is far too broad, covering weather, carbon estimates, domain intel, and more—well beyond its stated 'Japan public-data ledgers' scope. This sheer volume overwhelms agents and dilutes focus.
The server offers many read-only tools for Japanese public data (bids, grants, licenses, etc.), but lacks create/update/delete operations for those domains. Additionally, numerous unrelated tools (e.g., carbon estimates, weather) feel tacked on, leaving gaps in core coverage.