cinii_search_projects_and_products

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds that results come back as a 'unified envelope' and that records are typed from their own dc:type — genuinely useful, but the envelope's shape, pagination and the fact that unrelated record types share one result list are left implicit.

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?

Three short lines, front-loaded with the core purpose before the usage note. The trailing 'Records are typed from their own dc:type.' is a sentence fragment that reads as an afterthought, but nothing is padded.

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?

An output schema exists, so return values need not be described. Still, for a 15-parameter cross-entity search, the description omits pagination, sort scope interactions and what 'unified envelope' yields — an agent knows roughly what it gets but not how to navigate the results.

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?

Top-level coverage is reported at 0%, so the description carries some burden, and it does highlight researcher_id as the key lever for this mode. However it says nothing about sort, count, start, language, data_source or has_fulltext, which are documented only in the nested schema; the description adds one useful hint but does not compensate for the coverage gap.

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?

States a specific verb and a specific resource pairing ('Search KAKEN projects together with their research products ... in one result set'), which is more precise than the sibling cinii_search_kaken or cinii_search_articles alone. It does not name those siblings, leaving the agent to infer that this is the combined-search tool rather than being told so.

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?

One usage hint is given: 'Useful with researcher_id to list a researcher's grants and outputs together.' There is no statement of when to prefer this over cinii_search_kaken, cinii_search_articles, or cinii_search_all, and no exclusions, so the routing decision is only loosely guided.

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