Check if a health information source is verified by providing its URL, returning a verdict with suggested self-verification steps.
気になる健康情報のURLまたは発信元の名前を渡すと、その出どころが当レジストリで検証済みか（誰が・権威の格・管轄・利益相反の開示）を返す。未収録なら「信用できない」ではなく「未検証」として、自分で確かめる観点と検証済みの一次情報源を案内する。内容の医学的真偽・製品の良し悪しは一切判定しない。症状入力は受け取らない。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| topic | No | ||
| publisher | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnly annotation by explaining that for unregistered sources it will respond as 'unverified' rather than 'untrustworthy' and will suggest verification points and primary sources. It also explicitly states it does not judge medical truth or product quality, which gives a clear behavioral contract.
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 compact and logically ordered: main action, behavior for unregistered sources, and explicit exclusions. It is a few sentences but each sentence adds value, and the structure makes it easy to scan.
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 tool is relatively simple, and the description covers the core behavior and limitations. However, it does not specify whether url/publisher/topic are required or optional, nor does it hint at the output structure. Since there is no output schema, some information about the return format would improve completeness.
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 description explicitly covers the 'url' and 'publisher' parameters (URL or source name), but the 'topic' parameter is not mentioned at all, and there is no explanation of how topic is used or whether it is optional. With 0% schema description coverage, the missing explanation for one of three parameters leaves significant ambiguity.
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's function: given a URL or source name, it checks whether the source has been verified in the registry and returns relevant details (who, authority, jurisdiction, conflicts of interest). It also explicitly differentiates itself from a medical judgment tool and from a symptom input tool, making its purpose unmistakable.
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 it (for checking source credibility) and gives a clear negative constraint ('does not accept symptom input'), but it does not explicitly compare with sibling tools like verify_source, get_registry_entry, or list_registry. The guidance is present but not fully elaborated with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.