Resolve full entity names to source candidates for human or mouse regulatory datasets, preserving ambiguous and incomplete matches and returning IDs for follow-up queries.
按完整名称查询来源实体候选；保留歧义和不完整结果，返回的 ID 可用于后续查询。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | ||
| refresh | No | ||
| species | Yes | ||
| symbols | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| error | No | ||
| status | Yes | ||
| coverage | Yes | ||
| warnings | No | ||
| provenance | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world. The description adds a genuinely non-obvious behavioral trait: ambiguous and incomplete candidates are kept rather than resolved away, so the agent knows to handle multiple/no hits. It does not explain what the 'refresh' flag does, which is the main remaining gap.
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?
A single compact sentence that front-loads the lookup and matching rule, then the result-handling caveat and the downstream-ID note. No 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?
An output schema exists, so return values need no explanation, and the ambiguity caveat covers result handling. However, for a four-parameter tool with no schema descriptions, the meaning of 'dataset' and 'refresh' is missing, so the definition is only just sufficient.
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% across four parameters, so the description must carry the load, yet it only implies that 'symbols' are matched by full name. The 'dataset' enum ('core' vs 'complete'), 'species', the 'refresh' flag and the 50-item cap are left entirely unexplained.
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 specific verb and resource: query source entity candidates by full name, and notes the returned IDs feed later queries. It is clear enough to contrast with the interaction/network siblings, though it never names an alternative tool or states the identity-resolution role explicitly.
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 workflow hint ('returned IDs can be used in subsequent queries') implies this is a first step before other lookups, and 'preserve ambiguity and incomplete results' implies it shouldn't be treated as authoritative filtering. There is no explicit when/when-not guidance or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.