Radar Agent Tools

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the official v2 API, returned fields, a 25 calls/day free limit, and paid x402 access. It does not describe pagination or error behavior, but the added rate-limit and cost details are meaningful.

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 three tight sentences with no wasted wording. It front-loads the core search capability, then return fields, then access limits and pricing.

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 read-only search tool with full schema coverage and annotations, the description is nearly complete: it covers purpose, return fields, rate limits, and cost. It could mention pagination or result ordering, but no critical calling information 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?

Schema description coverage is 100%, so all seven parameters are already documented in the input schema. The description lists the same search dimensions but adds no syntax, format, or interaction details beyond what the schema provides, making the baseline 3 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 states a specific verb and resource: search ClinicalTrials.gov, and it names the supported search dimensions (keyword, condition, intervention, sponsor, location). It does not explicitly differentiate this tool from siblings such as web_read or domain_intel, so it falls short of a 5.

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 when to use the tool by describing it as a ClinicalTrials.gov search, but it gives no explicit when-not guidance or alternatives. An agent can infer the use case, but routing versus sibling tools is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful context beyond them: the authoritative data source (official IANA RDAP servers), the exact record types queried, and a rate limit plus paid fallback. It does not say how partial failures behave (e.g., DNS succeeds but port 443 has no certificate), which is the main remaining behavioral gap.

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 the payload contents before the access/pricing terms. The long parenthetical field list is dense but every item is a returned value an agent would want to know, so it earns its space; a semicolon-separated list would read slightly faster.

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, the description carries the return-value burden and does so thoroughly for all three data planes. The notable gap is that the schema marks no required fields, yet 'domain' is obviously mandatory — the description implies it ('One call for a domain') without ever stating that domain must be supplied or what happens for an unresolvable domain.

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%: both parameters, including the tls default of true, are already documented in the schema. The description adds no syntax, normalization, or edge-case detail for 'domain' (subdomains, IDN, scheme prefixes) beyond the schema's own example, so 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?

States a concrete verb-plus-resource ('One call for a domain') and enumerates exactly what comes back: RDAP registration fields, live DNS record types, and TLS certificate attributes. None of the siblings (clinical_trials, federal_register, osv_vulns, prediction_markets, web_read) overlap, so an agent can route unambiguously.

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 by the domain-lookup framing rather than stated; there is no explicit 'use this instead of web_read when...' or when-not guidance. It does add a practical operating condition (25 free calls/day per IP, then $0.005 via x402), which helps an agent budget calls but is not selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description earns credit for adding quota and cost information the annotations cannot express (25 calls/day per IP free, $0.005 per call via x402). The payment endpoint is given as 'https://localhost/x402/federal-register', which reads as a placeholder and could mislead an agent attempting to use it. Pagination behavior is left to the schema's maxItems.

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 the capability, then filtering, then cost — each sentence carries information. Minor redundancy in listing document types that the type enum already enumerates, and the pricing sentence is dense with a questionable URL.

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 read-only search tool with no output schema, the description addresses what it does, what comes back, how to narrow, and the cost model. The only meaningful gap is result-set behavior beyond maxItems (pagination/truncation) and the placeholder-looking payment URL, which an agent may need to interpret.

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 description coverage is 100%, so the schema already documents all six parameters with enums and defaults. The description restates the filter dimensions but adds nothing the schema lacks, such as valid agency slug discovery or how relevance ordering behaves when no keyword is supplied. 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 names a specific verb (search) and a specific resource (the official US Federal Register), and enumerates the document classes covered plus the fields returned (abstract, agencies, publication date, links). Sibling tools are unrelated domains (clinical_trials, osv_vulns, prediction_markets), so no cross-routing ambiguity exists to resolve.

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 says what can be filtered (keyword, type, agency, date), which implies how to shape a query, but it never states when this tool is the right choice or when it is not. No prerequisites, no exclusions, and no mention of query-construction strategy such as preferring a broad date range when relevance ordering is used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context by disclosing the free tier limit of 25 calls/day per IP and the paid x402 rate, though it does not describe error behavior or pagination.

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 definition is front-loaded and compact: the vulnerability lookup purpose comes first, followed by a separate pricing/limit sentence. Every phrase contributes useful information, and there is no redundant 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?

For a five-parameter tool without an output schema, the description compensates by listing the returned fields and documenting cost limits. It still omits the key invocation constraint that at least one package identifier is expected and how purl/package/version interact, but the complete schema coverage fills most remaining 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 description coverage is 100%, so the schema already documents all five parameters. The description reinforces the package/version use case and ecosystem coverage but does not add parameter-specific rules such as whether purl takes precedence over package or when version should be omitted.

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?

States that it retrieves known vulnerabilities for an open-source package version from OSV.dev, names the covered ecosystems and sources, and lists the returned fields. This is specific enough for an agent to know exactly what resource it provides, and it is clearly distinct from unrelated sibling tools.

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 used when checking a package version for known vulnerabilities, but it does not give explicit when-to-use/when-not-to-use guidance. It also does not explain the relationship between the purl, package, version, and ecosystem parameters, leaving selection logic to the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses concrete behavioral facts the annotations cannot: the default result ordering (volume), the quota and pricing model including the x402 endpoint, and the shape of the returned data. Rate limits and per-call cost are exactly the kind of context an agent needs before calling.

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 tight sentences: the capability and return fields are front-loaded, then the quota/pricing line. Every clause carries information — no filler, no restatement of the 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 output schema, the description compensates by listing the returned fields (event, market, outcome prices, volume, liquidity, end date, link) and the sort order. Combined with full schema coverage on the three parameters, an agent has everything needed to call and interpret this 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 description coverage is 100%, so the baseline is 3; the description adds modest value by clarifying that prices are implied probabilities on a 0-1 scale and that results are volume-ranked, which helps interpret the output. It still does not explain how 'all' source merging behaves or how query matching works, so it stays just above baseline.

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 and resource ('Search open prediction markets on Polymarket and Kalshi') and enumerates the fields returned, so the agent knows exactly what comes back. No sibling tool covers this ground, and the description makes that distinct scope self-evident.

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 gives clear operational context for invocation: a single call covers both venues, results are sorted by volume, and there is a free tier of 25 calls/day per IP with a paid x402 fallback at $0.005/call. It stops short of naming exclusions or pointing to an alternative tool for adjacent needs such as historical or closed markets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld and idempotent, so the safety profile is covered; the description goes well beyond by disclosing that boilerplate is stripped, that robots.txt is respected, the ~1-3 s latency, the 25 calls/day free ceiling per IP, and the $0.002 paid path with its x402 endpoint. Rate limits and cost are exactly the operational facts an agent needs before retrying or looping.

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?

Five short sentences, front-loaded with what the tool returns before operational constraints. Every clause carries distinct information — output shape, cleanup behavior, compliance, latency, cost — with no restatement of the title or name.

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, yet the description enumerates the fields an agent will receive (main content, title, author, date, language) and the cleanup that has been applied, so return values are predictable. Combined with latency, quota and pricing, a caller has everything needed to invoke and budget calls correctly.

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 description coverage is 100%, so the schema already documents url, format (with enum and default) and maxChars (with bounds and default). The description restates the Markdown/plain-text choice but adds nothing about truncation behavior or how maxChars interacts with the returned metadata. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb and resource ("Fetch any public web page") plus the transformation applied ("return its main content as clean Markdown (or plain text)") and the metadata returned (title, author, date, language). No sibling tool in the list performs web retrieval, so the tool is unambiguous on its own terms.

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?

Gives a clear context for use — any public page, with robots.txt compliance and a stated latency window — which tells an agent this is a general-purpose retrieval tool rather than a site-specific one. It stops short of explicit exclusions (paywalled, JS-rendered, authenticated pages) and names no alternative tool, so it is clear but not fully routing-grade.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.