register_source

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.