気になる健康情報のURLまたは発信元の名前を渡すと、その出どころが当レジストリで検証済みか（誰が・権威の格・管轄・利益相反の開示）を返す。未収録なら「信用できない」ではなく「未検証」として、自分で確かめる観点と検証済みの一次情報源を案内する。内容の医学的真偽・製品の良し悪しは一切判定しない。症状入力は受け取らない。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| topic | No | ||
| publisher | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds significant behavioral context beyond that: it explains the 'unverified' vs 'not trusted' distinction, notes it does not judge medical truth or product quality, and clarifies the input constraints. This gives the agent a clear behavioral model, though it could mention the read-only nature explicitly.
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 somewhat long but well-structured: the opening sentence states the primary action, followed by the unrecorded-case behavior and explicit exclusions. It front-loads the core purpose and avoids redundancy, though it could be tightened without losing information.
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?
Given the tool's complexity and lack of output schema, the description covers most necessary context: what it returns, what it does not do, and how it handles unrecorded sources. The main gap is the unexplained 'topic' parameter, which could leave an agent uncertain about its role. Overall, it is fairly complete for a read-only registry lookup 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 0%, so the description must compensate by explaining each parameter. It mentions that a URL or source name can be passed, which maps to url and publisher, but it never explains the 'topic' parameter. The description does not provide formats, examples, or which parameters are mutually exclusive. This leaves a significant gap for an agent deciding how to invoke the tool.
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 the tool checks whether a given URL or publisher is verified in the registry and what attributes are returned (who, authority level, jurisdiction, conflict-of-interest). It explicitly distinguishes itself from judging medical truth or product quality, and from accepting symptom input, which differentiates it from sibling tools like verify_source.
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 provides clear context on when to use it: when you have a URL or source name to check against the registry. It also states exclusions (does not accept symptom input, does not judge truth). However, it does not explicitly name alternatives or say when to use a sibling tool like verify_source instead, leaving some routing implicit.
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 target clearly different operations: checking a source name or URL, listing registry entries, registering a source, computing summaries, and explaining product categories. The main ambiguity is between check_source and verify_source, since both sound like verification but one checks registry status and the other performs cryptographic hash verification; get_registry_entry also partially overlaps with check_source for detailed metadata.
Eight of nine tools follow a clean verb_noun convention: check_source, explain_product_category, get_agent_card, get_femtech_topic, get_registry_entry, list_registry, register_source, and verify_source. how_to_verify breaks the pattern as a noun phrase, but it is readable and does not cause real confusion.
Nine tools is well-scoped for a niche registry: it covers external queries, registry listing and detail retrieval, source registration, cryptographic verification, topic summaries, and agent metadata. Each tool has a distinct role and none feel redundant or like padding.
The surface covers the main workflows of a verification registry: register, list, retrieve, check a source, cryptographically verify an entry, and obtain topic-level neutral summaries. The main gap is the absence of update/delete operations for registry entries, though this may be intentional for an append-only or immutable provenance registry.