医薬品検索

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

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the tool does not return package insert full text but includes a PMDA search URL instead. It also reveals the data source (KEGG DRUG) and the ability to return JP listing status and brand names. This goes beyond simple action framing.

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 two sentences in Japanese, front-loading the primary action and then adding a crucial limitation (PMDA URL). Every sentence contributes meaningful information with no redundancy or 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 search tool with two simple parameters and an output schema, the description covers the essential aspects: what is searched, the data source, and a notable limitation. It does not detail the expected output structure, but the output schema likely handles that. Minor gaps like parameter usage for 'limit' are understandable.

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 description coverage, so the description must compensate. It explains that the search term can be a generic or brand name, which directly clarifies the 'term' parameter. However, it does not address the 'limit' parameter; its meaning is only inferable from the default value. Since one of two parameters is clarified, this partially compensates.

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: searching for drugs by generic or brand name, backed by the KEGG DRUG database. It also specifies additional capabilities (Japanese Pharmacopoeia status, brand names) and names the data source, making it distinct from sibling tools like search_pubmed or find_guideline.

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 implicitly establishes when to use this tool (for drug name lookups) and provides a clear limitation: full package insert text is not provided; instead, a search URL to PMDA is returned. This effectively tells the agent that for full text, it should consult PMDA directly, but it does not explicitly name alternative sibling tools or state exclusions.

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