search_claimsSearch the Claidex failure database for post-mortems matching a drug name, gene target, disease, failure archetype, or sponsor. Returns matching claims with title, slug, drug, target, disease, phase, failure archetype, Open Targets score, and MRS score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | ||
| query | Yes | Search term: drug name, gene symbol, disease, or failure archetype | |
| category | Yes | any | |
| failure_archetype | Yes | any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the search scope and return fields, but does not mention filtering behavior (category, failure_archetype), limits, pagination, or any potential quirks. The description also omits that 'sponsor' is a valid search term while the schema query description does not include it, creating a minor inconsistency.
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, front-loaded with the core purpose and followed by a list of return fields. It avoids fluff and is appropriately sized, though it could be slightly improved by explicitly stating the filter parameters.
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?
The tool has 4 parameters, no output schema, and no annotations. The description explains the search scope and return fields but does not cover parameter semantics for filters, limit behavior, or edge cases. Given the moderate complexity and the lack of structured annotations, the description is incomplete for safe invocation.
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 only 25% (query has a description). The tool description adds meaning for the 'query' parameter by listing acceptable search terms (drug name, gene target, disease, failure archetype, sponsor), but it does not explain the 'category' or 'failure_archetype' filter parameters, nor how they interact with 'query' and 'limit'. This leaves the agent with an incomplete understanding of how to construct a search.
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 a specific verb ('Search') and a specific resource ('Claidex failure database'), and defines the scope of the search ('post-mortems matching a drug name, gene target, disease, failure archetype, or sponsor'). This distinguishes it from sibling tools like search_pubmed or web_search.
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 usage for finding failure post-mortems in the Claidex database, but it does not explicitly state when to use this tool versus alternatives like query_failure_graph or get_claim_content. There is no explicit when-not-to-use guidance, leaving the agent to infer based on the database name.
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.
Several tools have overlapping responsibilities: search, search_claims, search_preprint_flags, and claidex_claim_risk_matrix all query claim/failure data, while rank_documents_by_embedding and rerank_documents both perform relevance ranking. The compatibility-oriented fetch/search tools add further confusion because their names collide with fetch_research_url and search_claims.
Names are grouped by prefixes (claidex_, query_, search_, run_) but the groups use different conventions, and bare verbs like 'fetch' and 'search' sit alongside prefixed forms like 'fetch_research_url' and 'search_claims'. The pattern is readable but not uniform.
24 tools is at the heavy end for an MCP server; while the breadth reflects many biomedical data sources and utilities, the count includes several meta/compatibility tools that could be consolidated. It is borderline but not unreasonable.
The surface covers the core biomedical workflows: searching claims, retrieving full claim content, querying failure graphs, checking preprints, and looking up drugs/trials/targets/adverse events. Minor gaps exist, such as no direct way to fetch a single clinical trial by ID beyond the search function, and no write/update operations for claims, but these are likely outside the read-only research scope.