find_phenotypically_similarDoenças com perfil de fenótipos HPO semelhante (simGIC pré-computado, explicável: nº de fenótipos em comum). Complementa find_similar_diseases (semântico).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| orphaCode | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | ||
| results | Yes | ||
| orphaCode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and closed-world, and the description adds meaningful context about the underlying algorithm (precomputed simGIC) and how similarity is explainable (number of shared phenotypes). This goes beyond what annotations provide and helps set expectations about the kind of results, though it does not mention any rate limits, pagination, or result ordering.
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 long, front-loaded with the core purpose, and every word earns its place. The first sentence delivers the essential function, and the second provides a crisp comparison with a sibling tool, with no redundant content.
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 presence of an output schema and read-only annotations, the description covers the main behavioral context well, including the similarity metric and how it differs from a sibling tool. It is slightly incomplete because it does not specify that the input is a disease's Orpha code or clarify how the limit parameter behaves, but the schema partially covers these details.
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 0% description coverage, and the description does not explain the meaning of orphaCode or limit beyond what the schema already shows. The description's mention of shared phenotypes hints at the similarity calculation, but it does not compensate for the lack of parameter explanation, leaving the agent to infer that orphaCode is a disease identifier and limit caps results.
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 identifies the tool as finding diseases with similar HPO phenotype profiles, using a precomputed simGIC metric and an explainable count of shared phenotypes. It explicitly distinguishes itself from the sibling tool find_similar_diseases, which is semantic-based, so the purpose is specific and non-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 description states that this tool complements find_similar_diseases (semantic), giving the agent a clear clue about when to choose this phenotypic/explainable approach over the semantic one. It stops short of explicitly stating 'use this when you need precomputed phenotypic similarity' or 'do not use when semantic similarity is needed', but the alternative is named and the distinction is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear, distinct purposes, but there is a cluster of 'find' tools (find_similar_diseases, find_phenotypically_similar, find_diseases_by_phenotypes) that could be confused; descriptions differentiate them (semantic vs HPO similarity vs exact match), and the paper search tools also differ by input type. Overall, ambiguous pairs are explicitly disambiguated, leaving only a few close calls.
All tools consistently follow a snake_case verb_noun pattern, using a limited set of verbs (analyze, explain, find, get, search) that map predictably to tool functionality. No mixed conventions or vague names are present, making the naming highly systematic.
At 20 tools, the server is slightly above the ideal range of 3-15, but each tool serves a distinct function within the rare disease knowledge platform. The breadth of features—search, similarity, detail, evidence, literature, hypotheses, graph exploration—justifies the count without feeling bloated or redundant.
The tool surface comprehensively covers the rare disease domain: search, differential diagnosis, disease detail, evidence, SUS/trials, reference centers, literature, hypotheses, and graph analytics. Write operations are not expected for a read-only knowledge base, and the inclusion of research log and recent updates closes all apparent gaps.