Neutral verification registry for femtech (women's health) information sources. It indexes sources by provenance, authority tier, jurisdiction, and machine-readable compensation disclosure. No diagnosis, no efficacy claims, no referral fees.
Scored across 9 tools
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.
気になる健康情報のURLまたは発信元の名前を渡すと、その出どころが当レジストリで検証済みか（誰が・権威の格・管轄・利益相反の開示）を返す。未収録なら「信用できない」ではなく「未検証」として、自分で確かめる観点と検証済みの一次情報源を案内する。内容の医学的真偽・製品の良し悪しは一切判定しない。症状入力は受け取らない。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| topic | No | ||
| publisher | No |
Does 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.
フェムテック製品の種類の中立解説。銘柄比較・効能断定はしない。
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds genuine behavioral context beyond this: the neutrality guarantee and the explicit exclusion of brand comparison and efficacy determination, which tells an agent what to expect in the response content. No contradiction with annotations.
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 a tight, single front-loaded sentence with no filler. Every clause carries meaning — the purpose, the neutrality, and the two explicit exclusions. It is appropriately brief for a simple tool, though it could add a short parameter note without becoming verbose.
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 itself is simple (one string param, no output schema, readOnly annotations), so the burden is low. But the undocumented category_id is a real gap: an agent has no way to know what value to pass or what formats are valid. The purpose and scope are covered; the parameter semantics are not, leaving completeness partial.
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% and the sole parameter category_id is a bare string with no format, example, or accepted values. The description does not compensate — it never mentions the parameter at all. With zero schema documentation, the description needed to explain what category_id represents and what valid inputs look like, and it fails to do so.
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 clear verb (explain) and resource (femtech product types) with a neutral-scope qualifier, and explicitly states what it does not do (no brand comparisons, no efficacy claims). However, it does not differentiate from the sibling 'get_femtech_topic', which may overlap in purpose, so the boundary between the two is left ambiguous.
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 neutrality constraint ('neutral explanation', 'does not make brand comparisons') implies the intended use case — a balanced, non-recommendation overview — but no alternatives are named and no when-not-to-use conditions are given. The guidance is implied rather than explicit, and the sibling set (get_femtech_topic, verify_source) is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A2Aエージェントカード。compensation(送客料ゼロ)を機械可読で開示し、自らが中立の検証層であることを宣言。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful transparency by explaining that the card contains machine-readable compensation disclosure and a neutrality declaration.
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 concise and front-loaded, consisting of a single short sentence that names the resource and its key contents. Every phrase contributes meaning without redundancy.
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 simple, parameterless, read-only tool with no output schema, the description sufficiently conveys what the tool provides. It could mention the output format or more explicit use cases, but none are essential given the tool's simplicity.
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 tool has zero parameters, so the schema coverage is trivially complete and no parameter descriptions are needed. The baseline is 4 for zero-parameter tools, and the description adds no conflicting or missing parameter information.
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 identifies the resource as an 'A2A agent card' and states that it discloses compensation and declares neutrality, making the tool's purpose reasonably clear. It lacks an explicit verb like 'returns' or 'fetches,' but the noun phrase is specific enough.
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?
No guidance is provided about when to use this tool versus sibling tools such as get_registry_entry, verify_source, or check_source. The description does not include any conditional context or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
出典に紐づく中立の要約情報を、sources と管轄と免責つきで返す。診断・断定はしない。論点=月経/PMS/更年期。
| Name | Required | Description | Default |
|---|---|---|---|
| topic_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only/non-destructive, and the description adds valuable behavior constraints: it does not diagnose or make assertions, and it returns sources, jurisdiction, and disclaimer. No contradictions with annotations.
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 a single concise sentence that front-loads the core purpose and includes essential constraints without extraneous detail.
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 adequately conveys the tool's purpose, output components (sources, jurisdiction, disclaimer), and non-diagnostic nature. For a simple single-parameter lookup, it is sufficiently complete, though it could clarify topic_id semantics further.
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 only parameter topic_id is described in schema only as a required string, with no description. The main description mentions topic scope but does not explain topic_id format, possible values, or how it maps to the returned summary. Schema coverage is minimal and the description does not compensate.
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 specifies a clear verb ('返す' = returns) and resource ('中立の要約情報' for femtech topics), and differentiates from siblings by focusing on source-linked neutral summaries rather than verification, registry, or product category functions.
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?
No explicit guidance is given on when to use this tool versus alternatives. The description implies applicability to menstruation/PMS/menopause topics, but does not state when-not-to-use or reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entry_id で情報源の出典・権威・管轄・報酬開示・検証状態・provenanceを返す。
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses '返す' (returns), implying a read operation, and the annotations readOnlyHint=true and destructiveHint=false already indicate safety. However, the description itself does not explicitly state that no side effects occur or that it is read-only.
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 a single concise sentence that directly states the tool's function and key parameter. No irrelevant information or verbose elaboration is present.
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 simple retrieval tool, the description covers the main purpose and parameter. However, since there is no output schema, the description does not clarify the exact shape of the returned data or potential failure modes, leaving some ambiguity for an agent.
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 only parameter entry_id is mentioned in the description as the lookup key, but no format, type constraints, or example values are given. The schema lacks a description, so the tool description carries the full burden; it only says 'by entry_id' without further clarification.
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 that the tool returns source, authority, jurisdiction, compensation disclosure, verification status, and provenance for a given entry_id. It does not explicitly contrast with related tools like list_registry or verify_source, but the core purpose is unambiguous.
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?
No guidance is provided on when to use this tool versus sibling tools such as list_registry or verify_source. The description does not mention prerequisites, expected context, or scenarios where this tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
エントリのハッシュを第三者が再計算する手順。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it is a procedure and aligns with readOnlyHint, but does not explain expected behavior (e.g., what it returns or how the result is presented), and no output schema is provided.
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 a single, focused sentence that efficiently conveys the core purpose without unnecessary fluff.
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 lacks context about what constitutes an 'entry' and what the procedure entails, making it insufficient for an agent to fully understand the tool's operation and expected output.
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 zero parameters, so there is nothing to elaborate on; the description adds no conflicting or missing parameter details.
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 action (recompute hash) and the actor (third party), but uses the undefined term 'entry' without context, which slightly reduces clarity.
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?
No explicit guidance on when to use this tool versus sibling verification tools like verify_source or check_source, leaving selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
管轄・言語・トピック・権威の格・状態でレジストリを絞って一覧。seed と保存済みをマージ。
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| topic | No | ||
| status | No | ||
| jurisdiction | No | ||
| authority_tier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It reveals the behavioral detail of merging seed and saved entries. Annotations indicate read-only and non-destructive, which is consistent. No hidden side effects are mentioned, but the annotations cover the safety profile.
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 a single concise sentence that conveys the core purpose without unnecessary detail.
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?
It does not specify the output format or explain what 'merge seed and saved' means in practice. There is no output schema, and the expected return type (e.g., array of entries) is not stated, though it is implied by 'list.'
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 lists the filter criteria in Japanese (jurisdiction, language, topic, authority level, status) but does not explicitly map them to the English parameter names (lang, topic, status, jurisdiction, authority_tier). Schema has no parameter descriptions, so the description partially compensates but leaves room for 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 lists the registry with optional filters and mentions merging seed and saved data. It is distinct from get_registry_entry, which likely returns a single entry, though it does not explicitly contrast them.
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 this is for listing/filtering registries but does not explicitly state when to prefer it over sibling tools like get_registry_entry. The sibling names provide context but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
フェム情報源を申請し、登録の5条件(実在する出典/権威の格/管轄/報酬開示/決定論)を機械検証。KVと公開書き込みが有効なら verified を保存。内容の医学的真偽は審査しない。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| lang | No | ||
| topic | No | ||
| entry_id | No | ||
| publisher | No | ||
| compensation | Yes | ||
| evidence_url | Yes | ||
| jurisdiction | Yes | ||
| authority_tier | Yes | ||
| check_reachability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool saves as 'verified' and does not review medical truthfulness, which is good. However, it does not explain failure modes (e.g., what happens if KV or public write are invalid) or side effects on existing entries (e.g., whether duplicates are overwritten). The annotations indicate readOnlyHint false, aligning with the write action, but the description lacks details on potential outcomes.
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 a single, clear sentence that efficiently conveys the core function and its limitations. It contains no redundant information and is well-structured for quick understanding.
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 tool with 10 parameters and no output schema, the description gives a solid high-level context: what it does, what conditions it verifies, and what it deliberately avoids. It lacks detailed parameter semantics and error scenarios, but the overview is enough to understand the tool's role. Given the complexity, the missing parameter details prevent a perfect score.
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 0%, and the description does not explain any of the 10 parameters individually. While the five conditions (real source, authority level, jurisdiction, compensation disclosure, determinism) map partially to parameters like authority_tier, jurisdiction, and compensation, other parameters like kind, lang, topic, entry_id, publisher, and check_reachability are left entirely unexplained. The description does not compensate for the lack of schema documentation.
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 purpose: to apply for a femtech information source, machine-verify five registration conditions, and save it as verified when KV and public write are valid. It also explicitly notes what it does not do (review medical truthfulness), which adds precision. The action verb 'register' distinguishes it from sibling tools like verify_source or check_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 implies use for registering new sources but does not explicitly state when to choose this over sibling tools like verify_source or check_source. No scenarios or prerequisites are given. The verification conditions are mentioned, but not the context for when registration is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
エントリの第三者検証。canonical と SHA-256、保存済み provenance との一致を返す。fail-closed。医学的真偽の判定ではない。
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and non-destructive annotations, the description adds behavioral details: it is fail-closed and explicitly disclaims medical truth evaluation. This gives extra insight into how the tool behaves and its limitations.
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 concise, direct, and well-structured. It conveys all key points in a few sentences without unnecessary verbosity or tangential details.
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 simplicity (one parameter, no output schema), the description provides a solid overview of purpose and behavior. It could clarify output format or error handling, but the fail-closed statement and scope limitation cover the most critical context.
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 schema provides no description for entry_id and the tool description does not explicitly explain what entry_id represents or how it should be formatted. With 0% schema coverage, the description fails to compensate adequately for parameter meaning.
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 that the tool performs third-party verification of an entry by checking canonical, SHA-256, and stored provenance. It also explicitly scopes that it is not a medical truth judgment, making its purpose unambiguous and distinct from general check 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 usage for verifying entry integrity, but does not explicitly name alternatives like check_source or how_to_verify. The note about not being a medical truth judgment provides some exclusion, but lacks clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_sourceexplain_product_categoryget_agent_cardget_femtech_topicget_registry_entryhow_to_verifylist_registryregister_sourceverify_source
Add one secure layer between your agents and this server.