Infermedica MCP by usefulapi

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

Annotations only declare readOnlyHint=true; the description reinforces this with 'Non-mutating computation' and resolves the ambiguity of a POST endpoint that does not mutate state. It also discloses exactly what the call returns, which the annotations do not cover. It stops short of mentioning auth requirements, rate limits, or model/version behavior.

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?

Two front-loaded sentences with no filler; the return payload is stated before the endpoint note. The trailing 'Engine API: POST /diagnosis' is marginally redundant but does usefully reinforce that a POST can still be non-mutating.

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?

With no output schema, the description correctly takes on the burden of describing return values (next question, ranked conditions with probabilities, should_stop flag), and the 100%-covered input schema handles the nested evidence objects. The main remaining gap is the multi-step loop and its relationship to sibling tools, which an agent must infer.

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 100%, so the schema already documents all six parameters including evidence items, model_id, dev_mode, and extras. The description adds no parameter-level detail such as evidence shape, header mapping, or how extras flags affect engine behavior, so baseline 3 is appropriate.

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 resource ('Run the diagnostic engine over the collected evidence') and enumerates the three outputs an agent receives: next question, ranked candidate conditions with probabilities, and a should_stop flag. It does not explicitly distinguish itself from closely related siblings such as infermedica_triage, infermedica_rationale, or infermedica_explain, which also operate over the same evidence, so an agent must infer the boundary.

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 phrase 'over the collected evidence' plus the schema note that evidence 'may be empty for the first call' implies the iterative diagnose loop, but there is no explicit when-to-use or when-not-to-use guidance relative to infermedica_suggest, infermedica_triage, or infermedica_rationale. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Non-mutating computation' plus the engine endpoint (POST /explain). It adds minor value but discloses nothing about auth needs, rate limits, or what the computation requires beyond the structured schema.

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?

Two tight sentences that front-load the purpose, followed by a safety note and endpoint. No filler or redundancy; slightly under-developed rather than verbose.

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?

There is no output schema, yet the description never explains what the explanation returns (supporting vs conflicting evidence format, weights, etc.), which matters for an explain tool. Combined with no sibling differentiation, it is adequate but leaves real gaps for a 7-parameter nested tool.

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 86%, so the schema already documents age, sex, evidence, target, dev_mode, and model_id in detail. The description only restates 'target condition' and 'collected evidence' at a high level without adding syntax or format meaning beyond the schema.

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 (explain) and resource (which evidence supports/conflicts with a target condition), which is clear and actionable. However, it does not distinguish itself from the closely related sibling infermedica_rationale, which likely also explains reasoning around a condition.

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 phrase 'for the collected evidence' implies this runs after evidence has been gathered, giving implied usage. But there is no explicit when-to-use/when-not, no prerequisites stated, and the overlapping infermedica_rationale sibling is never mentioned as an alternative.

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

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

The readOnlyHint annotation already declares this a safe read, and the description adds the concrete endpoint (GET /conditions/{id}), reinforcing it. It omits any auth, rate-limit, or 404/error behavior, so value beyond annotations is modest.

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?

Two short sentences, zero waste, with the core operation front-loaded and the endpoint mapping as secondary support. Nothing needs trimming.

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?

A simple single-entity read tool with full schema coverage and a readOnlyHint; the description plus annotations are enough to call it correctly. The only minor gap is that no output schema exists and the description doesn't hint at the returned condition shape, though that is not essential for 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 description coverage is 100%, so id, age, dev_mode, and model_id are all documented in the schema itself. The description only reiterates the id lookup and adds nothing about the optional age context or header-mapping parameters, so baseline 3 applies.

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 resource ('Get a single condition by its id') plus the underlying endpoint, which cleanly separates it from sibling list_conditions. It stops short of naming the sibling or contrasting scopes, so it's clear but not maximally differentiated.

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?

There is no explicit when-to-use, when-not-to-use, or alternative routing. The agent must infer from 'single condition by id' that this is the lookup path versus infermedica_list_conditions or infermedica_search_concepts, with no supporting guidance.

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

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

The readOnlyHint annotation already tells the agent this is a safe read. The description adds useful context beyond that: it identifies the underlying endpoint (GET /info) and the shape of the returned metadata, which matters because there is no output schema. It does not explain how the optional context parameters (model_id, dev_mode, age) affect the response.

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?

Two short sentences, with the purpose and the returned fields front-loaded. The trailing 'Engine API: GET /info.' is arguably redundant but cheap and useful for endpoint-oriented users.

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 simple read-only metadata tool this is largely complete: it says what comes back and which endpoint is hit, compensating for the absent output schema, and the optional parameters are fully covered by the schema. Only the absence of when-to-use guidance keeps it short of a 5.

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 100%, so all three optional parameters are already documented with their header mappings and defaults. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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 resource ('Get metadata about the current Infermedica medical model') and enumerates the payload (version, last update, concept counts). It is clearly distinct from the get_*/list_* concept siblings, though it never names an alternative the way a 5 would.

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?

There is no explicit statement of when to call this versus the sibling metadata/entity tools, nor any prerequisites or exclusions. Usage is only implied by the word 'current' and the fact that it describes a model-level resource.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds the underlying Engine API mapping (GET /lab_tests/{id}), which is mildly useful, but says nothing about the response shape, behavior on an unknown id, or how the optional age/model context alters results.

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?

Two short sentences, zero filler, with the core purpose front-loaded before the endpoint detail. Nothing here is redundant or padding.

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?

There is no output schema, so the burden of describing what comes back falls on the description, and it does not address return values at all. For a simple by-id fetch alongside a fully documented schema this is adequate but leaves the result shape and the effect of the optional age/model context unexplained.

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 100%, so id, age.value, age.unit, dev_mode, and model_id are all documented in the schema. The description adds no additional parameter meaning, so the baseline of 3 applies.

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 ('Get') and resource ('a single lab test') and keys it to the identifier, which implicitly separates it from the list_lab_tests sibling. It stops short of naming that sibling explicitly, so differentiation is inferred rather than stated.

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?

'by its id' implies this is the lookup path when an id is already known, versus listing or searching. There is no explicit when-to-use statement, no mention of alternatives like infermedica_list_lab_tests or infermedica_search_concepts, and no exclusions.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the underlying REST endpoint but says nothing about how the optional age, model_id, or dev_mode parameters alter behavior or what the response contains.

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?

Two sentences, zero filler, and the primary action is front-loaded before the endpoint detail. Nothing could be removed without losing 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?

For a read-only single-entity fetcher with full schema coverage and no output schema, the description covers what an agent needs to invoke it. It could still note that age/model_id are optional context modifiers, but the omission is minor.

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 100%, with id, age, dev_mode, and model_id all documented in the schema, so the baseline is 3. The description's 'by its id' adds no syntax or format information beyond what the schema already provides.

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 resource ('Get a single risk factor by its id'), which cleanly separates it from the sibling infermedica_list_risk_factors by implying singular retrieval. The Engine API endpoint reinforces exactly what it does, though no sibling is named 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?

Usage is implied by 'by its id' — call it when you already hold a risk factor id — but there is no explicit when-to-use vs. list/search guidance or statement of prerequisites. Adequate minimum, with the list/single distinction left for the agent to infer.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the burden is lower. The description adds the raw endpoint (GET /symptoms/{id}), which confirms read semantics but nothing about authentication, rate limits, or error behavior for an invalid id.

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?

Two short sentences with zero waste. The core action is front-loaded, and the endpoint reference is a compact, useful piece of context rather than padding.

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?

Low-complexity single-resource fetch where annotations cover safety and the schema fully covers inputs. No output schema exists, so the shape of the returned symptom is undocumented anywhere, but the tool's simplicity keeps this a minor gap.

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 100%, so all four parameters (id, age, dev_mode, model_id) are already documented in the schema with examples and header mapping. The description adds no syntax or meaning beyond that, so the baseline 3 applies.

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: 'Get a single symptom by its id', which lets an agent distinguish it from infermedica_list_symptoms without opening either schema. It stops short of naming the sibling it contrasts with, so 4 rather than 5.

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?

Usage is implied by 'by its id' — an agent infers this is the tool for a known symptom identifier, not for discovery. No explicit when-to-use, when-not-to-use, or pointer to infermedica_list_symptoms or infermedica_search_concepts for lookup by name.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the raw endpoint mapping (GET /conditions) and confirms the scope is the full medical model; it says nothing about pagination, result size, or error behavior. With annotations carrying the heavy lifting, a minimum-viable 3 is fair.

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?

Two short sentences with the core purpose front-loaded and no preamble. The trailing 'Engine API: GET /conditions' is marginally useful plumbing rather than something an invoking agent strictly needs.

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 read-only list tool with a 100%-covered schema and safety annotations, the description covers the essentials. However, with no output schema the agent gets no hint about the shape or volume of the returned condition list, and the optional age filter goes unmentioned in prose.

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 100%, so the documentation burden sits with the schema. The description mentions no parameters at all, including the non-obvious nested 'age' filter and the dev_mode/model_id headers, so it adds no meaning beyond the schema baseline.

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 resource ('List all conditions (diseases)') and scopes it to the Infermedica medical model. It distinguishes itself from the singular sibling get_condition via 'all', but never explicitly differentiates from list_symptoms / list_lab_tests / list_risk_factors.

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?

No statement of when to use this tool versus get_condition, search_concepts, or the other list_* siblings, and no prerequisites or exclusions. The agent must infer that this is the bulk-enumeration route from the name alone.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results are bundled with each test and maps to the underlying GET /lab_tests endpoint, but says nothing about pagination, result size, or auth requirements, so it adds only modest value.

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?

Two short sentences, front-loaded with the resource and scope; nothing is wasted. The endpoint reference is arguably redundant but does anchor the tool to the API.

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?

There is no output schema, and the description does mention that results accompany the tests, which partially compensates. It omits any note on volume/pagination for a list endpoint, but with readOnly annotations and fully documented optional params the definition is adequate for correct 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 description coverage is 100% and all three parameters (age, model_id, dev_mode) are documented in the schema itself. The description adds no format or behavioral detail beyond the schema, so the baseline 3 applies.

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+resource ('List all lab tests') and even notes the payload includes results, which is useful. However it never distinguishes itself from the sibling infermedica_get_lab_test (singular) or from the other list_* tools, so an agent must infer the difference.

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?

No guidance on when to use this versus infermedica_get_lab_test or the other list_* siblings, and no prerequisites or filtering conditions are stated. Usage is only implied by the verb 'List'.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds only the underlying endpoint (GET /risk_factors); it says nothing about pagination, result size, or whether model_id changes the returned set.

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?

Two short sentences, purpose front-loaded, no filler. The endpoint sentence is marginal value but costs almost nothing.

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 simple read-only list tool this is close to adequate, but with no output schema the description never sketches the shape of a returned risk factor or the effect of the age filter, which is the one behavior an agent would need to interpret 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?

Schema description coverage is 100%, including the nested age object and the dev_mode/model_id headers, so the schema carries the parameter burden. The description adds no filtering semantics (e.g., how age narrows the list) beyond what the schema already states.

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+resource ('List all risk factors') plus the API surface it maps to ('GET /risk_factors'). An agent can distinguish it from the singular infermedica_get_risk_factor sibling, though the description never explicitly names that contrast.

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?

No when-to-use, when-not-to-use, or alternative is given. The word 'all' weakly implies bulk enumeration versus the singular get_risk_factor, but the agent must infer that routing decision itself.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds that the call maps to GET /symptoms and that results can be narrowed by age, but says nothing about result size, pagination, or lookup semantics — which matters for a 'list all' endpoint. Some added value over annotations, but thin.

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?

Two short sentences, with the purpose and scope front-loaded before the API note. No filler; the endpoint clause is marginal but short enough not to hurt readability.

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?

With no output schema, the description does not hint at the return shape (whether ids, names, or full records come back) nor at result limits for an unbounded 'list all'. Annotations cover safety, so the gap is moderate rather than severe, but the definition stops short of being fully self-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 100%, so the four parameters (age.value/age.unit, dev_mode, model_id, enable_triage_5) are fully self-documented and the baseline is 3. The description only restates the age filter and adds no semantics beyond the schema.

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 resource ('List all symptoms in the Infermedica medical model') with a scope qualifier, which cleanly contrasts with the singular sibling infermedica_get_symptom. It does not, however, explicitly name that sibling or distinguish itself from the other list_* tools.

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 parenthetical '(optionally age-filtered)' implies when the age parameter matters, but there is no explicit when-to-use/when-not guidance and no pointer to infermedica_get_symptom for per-symptom detail. Usage is only inferable from the name and scope.

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

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

Annotations already declare readOnlyHint=true, so the 'Non-mutating computation' sentence is largely redundant. It does add useful context (NLP engine, POST /parse endpoint) but omits return-shape expectations, latency/rate behavior, and what happens to unmapped mentions. With annotations covering the safety profile, a 3 is appropriate.

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, front-loaded sentences: purpose first, then safety, then API detail. No filler or repetition; each sentence carries distinct information.

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 9-parameter tool with a nested age object and no output schema, the description covers the core purpose but leaves the return format entirely implicit and never explains how optional params like context or model_id affect parsing. Adequate but with clear gaps given the complexity.

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 100%, so every parameter (age, sex, text, context, dev_mode, model_id, concept_types, include_tokens, correct_spelling) is already documented in-schema. The description only gestures at concept_types (symptoms/risk factors) and states, adding little beyond the structured fields. Baseline 3.

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 (extract/parse) and resource (clinical mentions of symptoms/risk factors and their states from free text), plus the mapping to Infermedica evidence ids. This lets an agent distinguish it from the get_*/list_* lookups, though it never names the closest sibling (search_concepts) to sharpen the boundary.

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 the tool is for parsing free-text complaints but offers no explicit when-to-use, when-not-to-use, or alternative routing against infermedica_search_concepts or infermedica_suggest. No prerequisites (e.g., need for patient age/sex context) are stated.

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

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

readOnlyHint=true already declares the safety profile; 'Non-mutating computation' restates it, though it usefully clarifies that a POST endpoint does not mutate state. The Engine API endpoint (POST /rationale) is genuine added context. No return-shape, pagination, or auth detail is provided.

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 tight sentences, front-loaded with the core purpose before the implementation detail. Every sentence earns its place with 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?

For a 6-param tool with nested evidence objects and no output schema, the description is thin: it conveys the intent of the return ('explain WHY') but not the shape of the response or the evidence payload expectations. Adequate but leaves gaps an agent must resolve elsewhere.

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 83%, so the schema already documents age, sex, evidence, model_id, dev_mode, and extras. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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+resource: explaining why the engine wants its next question, scoped to given evidence. This is distinguishable from diagnosis/triage at a glance. However it never names which sibling it differs from (e.g. infermedica_explain or infermedica_suggest), so the differentiation is inferred rather than stated.

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?

Implies the precondition 'given the evidence' but gives no explicit when-to-use, when-not-to-use, or alternative tool. With 17 siblings including explain/suggest/diagnosis, an agent gets no routing guidance on why to pick this over those.

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

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

Annotations already declare readOnlyHint=true, so 'Non-mutating computation' largely restates structured data. The description does add the API surface (POST /recommend_specialist) and the fact that the request body mirrors diagnosis/triage, which is genuinely helpful. It omits any note on auth, rate limits, or error behavior.

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 tight sentences: purpose first, behavioral note second, API endpoint last. No filler, and the most important fact (what it recommends) is front-loaded.

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?

With annotations covering the safety profile and no output schema, the description does name what is returned (specialist and consultation channel), which is adequate for the tool's job. A brief note on response shape or required evidence could improve it, but nothing critical is missing for correct 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 description coverage is 100%, so the schema already documents age, sex, evidence, extras, dev_mode, and model_id in detail. The description adds only the framing that the whole body matches diagnosis/triage, which provides no new per-parameter meaning beyond the schema baseline.

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 resource: 'Recommend the most appropriate medical specialist and consultation channel.' It is clearly distinct from siblings like diagnosis/triage, which it references only for body compatibility rather than as competing alternatives. The one missing element is an explicit statement of when this tool is preferred over infermedica_diagnosis.

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 parenthetical 'accepts the same body as diagnosis/triage' implies this tool is a downstream/companion computation invoked with collected evidence, which is a useful usage hint. However, there is no explicit when-to-use, when-not-to-use, or alternative routing guidance against infermedica_diagnosis or infermedica_triage.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. Beyond that, the description contributes only the underlying endpoint (GET /search), which does not inform agent behavior — no result format, ranking/truncation behavior, or rate limits are described.

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?

Two short sentences, front-loaded with the core purpose. The trailing 'Engine API: GET /search' is arguably low-value for an agent selecting a tool, but it costs little space.

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?

With seven parameters (including a nested object), no output schema, and no explanation of what a returned concept looks like or how results are meant to be used downstream, the description is thin for the tool's complexity. An agent gets no sense of the return payload despite the absence of an output schema.

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 100%, so all seven parameters (age, sex, types, phrase, dev_mode, model_id, max_results) are documented in the schema itself. The description adds nothing about parameter semantics, which is acceptable at the 3 baseline when the schema does the heavy lifting.

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 resource — search the medical concept database for observations matching a phrase — and frames it as autocomplete, which tells the agent what kind of lookup this is. It does not, however, distinguish itself from the many sibling lookups (list_symptoms, get_symptom, parse, suggest), leaving the agent to infer the boundary.

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 parenthetical '(autocomplete)' implies a partial-phrase lookup scenario, but there is no explicit when-to-use guidance, no statement of when to prefer this over list_* / get_* siblings, and no mention of prerequisites or follow-up steps.

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

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

Annotations already declare readOnlyHint=true, and 'Non-mutating computation' largely restates that rather than adding new behavioral detail. The Engine API endpoint mapping (POST /suggest) is modest added context, but nothing about return shape, rate limits, or auth is disclosed.

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, front-loaded sentences with the purpose stated first. Slightly marred by 'Non-mutating computation,' which duplicates the readOnlyHint annotation instead of contributing new information.

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 tool with 8 parameters (including nested evidence objects) and no output schema, the description says nothing about what the suggestions look like (observation IDs, likelihood, source flags) that an agent would need to consume the result. Adequate on the request side, incomplete on the response side.

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 88%, so the schema itself documents nearly every parameter (age, sex, evidence, suggest_method, etc.) in detail. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 resource ('suggest additional symptoms/observations the patient is likely to have') plus the goal ('speed up the interview'). This clearly separates it from siblings like infermedica_diagnosis or get_symptom, though no sibling is named 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?

'To speed up the interview' implies the workflow context where this tool fits, but there is no explicit when-to-use/when-not or named alternative among the many sibling tools. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, but the description usefully adds that this is a non-mutating POST operation, which prevents an agent from mistaking POST /triage for a write. It also names the returned triage levels and observations, though it omits auth, error, or rate-limit behavior.

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 concise sentences, front-loaded with the main action and output categories, then the non-mutating clarification and API endpoint. No sentence is wasted.

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?

With no output schema, the description appropriately names the return categories: triage level and serious/emergency observations. The nested input schema covers parameter details, but the description could do slightly more to explain required inputs or evidence expectations.

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 high at 83%, so the baseline is 3. The description only mentions 'given the evidence' and does not add syntax or format guidance beyond what the schema already provides for sex, age, evidence, extras, dev_mode, and model_id.

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 resource: recommend a triage level, with the full set of possible triage outputs enumerated. This clearly separates it from diagnosis or explanation siblings by output type, though it does not explicitly name an alternative tool.

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 phrase 'given the evidence' implies the tool should be used after evidence is collected, and 'Non-mutating computation' clarifies the operation type. However, there are no explicit when-to-use/when-not-to-use rules and no named alternatives such as infermedica_diagnosis.

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