infermedica

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

Annotations only declare readOnlyHint=true, and the description reinforces this with 'Non-mutating computation' while also disclosing the return shape (next question, ranked conditions, should_stop flag) and the underlying call (POST /diagnosis). With no output schema, describing the response contents adds real value. It stops short of covering auth/rate limits.

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?

Front-loaded with the core action and return contents in one dense sentence, followed by two short clarifying fragments. Minimal waste, though 'Non-mutating computation' partly restates the readOnlyHint annotation.

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-parameter, nested-object tool with no output schema, the description covers purpose, return contents, and safety reasonably well, and the rich schema descriptions handle parameter details. It lacks explicit sibling routing, which would make it fully complete.

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 six parameters (including nested age/evidence objects and extras) are already documented in the schema. The description only loosely references 'collected evidence' and adds no format or header details beyond what the schema provides, which is the expected 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?

The description uses a specific verb and resource ('Run the diagnostic engine over the collected evidence') and enumerates what it returns (next question, ranked conditions with probabilities, should_stop flag). This lets an agent distinguish it from siblings like infermedica_suggest, infermedica_rationale, and infermedica_triage, though it never explicitly contrasts itself with them.

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?

'Over the collected evidence' implies the tool is called iteratively during a diagnostic session, giving implied usage. However, there is no explicit guidance on when to prefer this over triage/suggest/rationale, no mention of prerequisites like required evidence, 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?

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Non-mutating computation' plus a useful API detail ('POST /explain'). However it discloses nothing about return format, latency, or auth beyond what the annotation implies, so it adds only modest value over the structured fields.

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 sentences, front-loaded with the core purpose, followed by the safety trait and API endpoint. Little waste; the 'POST /explain' clause is marginally agent-relevant but not distracting.

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 7-parameter tool with nested objects and no output schema, the description only loosely sketches the output ('which evidence supports or conflicts'). The schema carries parameter burdens well, but return-value shape is left thin, so it is adequate rather than complete.

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% (high), so parameters like target, evidence, sex, age, and dev_mode are already well documented in the schema (e.g. 'c_49', 's_21'). The description adds no additional parameter syntax or constraints beyond that 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 ('explain') and resource ('which evidence supports or conflicts with a given target condition'), so the agent knows exactly what computation is performed. It is clear but does not differentiate from the close sibling infermedica_rationale, which likely offers overlapping evidence-based explanation.

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 says the explanation is 'for the collected evidence' but gives no explicit when-to-use, when-not, or alternative-selection guidance. With siblings like infermedica_diagnosis and infermedica_rationale, the routing decision is left entirely to inference.

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 the underlying API endpoint (GET /conditions/{id}) but says nothing about the optional age/model_id/dev_mode context, auth requirements, or what the returned condition 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 short sentences, front-loaded with the action and resource. The second sentence (API path) is marginally useful for documentation matching but is largely redundant with the name and title.

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 getter with annotations covering safety and a fully documented schema, the description is nearly sufficient. The main gap is the absence of an output schema combined with no description of what a condition object returns.

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 four parameters, including the nested age object and the header-mapping params. The description adds no parameter syntax or meaning beyond what the schema provides, 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'), and the word 'single' implicitly differentiates it from the sibling infermedica_list_conditions. It is clear but does not explicitly name the sibling it complements.

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 or when-not-to-use guidance, and no alternatives named. The phrase 'by its id' hints that an id must be obtained elsewhere, but the agent is left to infer this, and no sibling like infermedica_search_concepts or infermedica_list_conditions is referenced.

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 by citing the underlying GET /info endpoint, confirming a read-only, side-effect-free call. It adds no auth requirements, rate-limit behavior, or caching/freshness semantics for the returned metadata, so it goes only modestly beyond the annotation.

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?

One front-loaded sentence stating the resource and the metadata returned, plus the endpoint reference. Zero filler; every clause carries 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 read-only metadata lookup with fully documented parameters and no output schema, the description adequately covers what the tool returns. It could note that the result is scoped to the currently configured model unless model_id is supplied, but nothing critical is missing.

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 age, dev_mode, and model_id are already fully documented in the schema. The description mentions 'the current model' but never explains that model_id overrides which model's info is returned, adding no real meaning beyond the structured fields; 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 names a specific verb and resource ('Get metadata about the current Infermedica medical model') and enumerates the returned fields (version, last update, concept counts), which clearly separates it from the concept/diagnosis siblings. It does not explicitly say how it differs from other 'get_' siblings, but the resource is distinct enough that an agent can disambiguate.

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 guidance on when to call this versus alternatives such as infermedica_get_condition or the list_* tools, and no prerequisites or exclusions are stated. The word 'current' hints at a version-check use case, but the agent must infer that on its own.

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=true annotation already tells the agent this is a safe read. The description adds the underlying API mapping (GET /lab_tests/{id}), which is marginally useful for tracing but does not disclose return shape, error behavior on a missing id, or the effect of the optional age/model_id/dev_mode context.

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 terse sentences with the purpose front-loaded and zero filler. Every phrase carries information (the id scoping and the endpoint mapping).

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?

This is a simple read-only fetch with full schema coverage, so the core is adequate. With no output schema and no description of the returned lab test object, an agent gets no sense of what fields come back or how the optional age/model_id parameters alter the response.

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, including the enum and header mappings. The description adds no parameter-level information beyond that, 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 lab test by its id'), and the word 'single' distinguishes it from the sibling infermedica_list_lab_tests. It does not name that sibling explicitly, so the differentiation is implied 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?

The 'by its id' phrasing implies usage when a lab test id is already known, which is the natural contrast with a list/search tool. However, no explicit when-to-use, when-not-to-use, or named alternative is given.

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 the underlying endpoint mapping (GET /risk_factors/{id}), which is modest extra context, but says nothing about error behavior (e.g. invalid id), authentication, or response shape. Against an annotation-covered read tool, this is adequate 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, front-loaded with the purpose and followed by traceability to the underlying endpoint. Nothing is wasted, though the endpoint restatement is arguably redundant.

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 single-resource lookup with full schema coverage and a read-only annotation, the description is sufficient to invoke the tool correctly. A sentence pointing to the list/search sibling for id discovery would have completed it.

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 id, age, dev_mode, and model_id, including the Dev-Mode header behavior and example id format. The description adds no parameter 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 risk factor by its id') and the singular scope naturally contrasts with the sibling list_risk_factors. It does not explicitly name that sibling, so the differentiation is implicit rather than spelled out.

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 guidance on when to use this tool versus infermedica_list_risk_factors or infermedica_search_concepts to obtain an id first. The only usable signal is the required 'id' parameter, which the schema already enforces.

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 the underlying endpoint (GET /symptoms/{id}), which is mild context, but says nothing about error behavior for unknown ids, rate limits, or whether the optional age/model_id headers alter the response — a meaningful gap for a lookup tool with conditional context parameters.

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 operation front-loaded and the endpoint mapping as supporting detail. No filler, nothing redundant.

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 schema is fully documented and annotations carry the read-only safety profile, so an agent can invoke the tool correctly. However, with four parameters including a nested age object and no output schema, the description never explains what a symptom record contains or how the optional age/model_id context affects results, leaving usage guidance thin.

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, including the header mappings. The description contributes nothing 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 with scope narrowed to a single item ('Get a single symptom by its id'), which contrasts implicitly with the sibling infermedica_list_symptoms. It stops short of explicitly differentiating itself from siblings or naming the identifier scheme beyond the schema's 's_21' example.

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 guidance on when to use this rather than infermedica_list_symptoms or infermedica_search_concepts, nor any mention of prerequisites such as needing a valid symptom id. The only context is the implicit 'by its id' phrasing.

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 REST endpoint (GET /conditions) and the 'all conditions' scope, but says nothing about pagination, result size, how the age/model_id filters change the output, or return shape.

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 with the API endpoint trailing as supporting detail. Nothing 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?

For a simple read-only list tool with fully documented params and no output schema, the description is minimally adequate. It omits any note on pagination or result size, which for a full-catalog listing would help the agent reason about usage.

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, dev_mode, and model_id thoroughly. The description adds no additional meaning about these parameters, 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 conditions (diseases)') and scopes it to the Infermedica medical model, so the agent knows it enumerates the full catalog. It does not explicitly distinguish itself from siblings like infermedica_get_condition or the other list_* tools, but the list-vs-get distinction is inferable.

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 guidance, no exclusions, and no alternatives named among the many siblings (get_condition, list_symptoms, list_lab_tests, search_concepts). The agent is left to infer that this is for enumerating all conditions versus fetching one.

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 description's only added context is the underlying Engine API endpoint (GET /lab_tests) and that results accompany the tests. It does not disclose pagination, result size, or what an empty model returns, which is the main behavioral gap for a list tool.

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 front-loaded sentence with the resource and scope stated first. The trailing 'Engine API: GET /lab_tests' is marginally redundant but does anchor the definition to the upstream contract, so no significant waste.

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, zero-required-parameter listing tool with full schema coverage and annotations carrying the safety profile, only modest context is needed and the description supplies it. The remaining gap is return shape, which matters slightly more here because no output schema exists.

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 age, dev_mode, and model_id are each fully documented in the schema itself. The description adds nothing about how these filters narrow the listing, 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 clear verb (List) and resource (lab tests), plus the scope note that results are included, which separates it from the singular get_lab_test. It does not explicitly name the sibling it differs from, so an agent must infer the bulk-vs-single distinction.

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 only implied: 'List all lab tests' suggests bulk enumeration versus infermedica_get_lab_test for a single entry, but no when-to-use, when-not-to-use, or alternative is stated. The optional age/model_id filters are never framed as selection criteria.

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 without the description. The description adds the underlying endpoint (GET /risk_factors), which is mildly useful for debugging, but says nothing about pagination, result volume, rate limits, or how the optional filters behave.

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 compact sentences with the purpose front-loaded and no filler. The endpoint line is arguably redundant for an agent but not wasteful enough to hurt.

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 with 100% schema coverage and no output schema, the essentials are present. However, the description's 'list all' framing doesn't acknowledge the optional age/model_id filtering that the schema exposes, leaving the filtering behavior slightly unclear.

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 age, dev_mode, and model_id are already fully documented in the schema, including the nested age.unit enum. The description adds no parameter meaning beyond that, 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?

Names a specific verb (list) and resource (risk factors) and scopes it to the Infermedica medical model. The word 'all' implicitly distinguishes it from the singular infermedica_get_risk_factor sibling, though that sibling is not 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 only implied: 'List all risk factors' suggests bulk enumeration rather than single-concept lookup, which indirectly contrasts with get_risk_factor. There is no explicit when-to-use statement, no mention of when to prefer search_concepts or the singular getter.

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 safety is covered. The description adds the backing endpoint ('Engine API: GET /symptoms'), which confirms a read operation, but discloses nothing about result size, pagination, or model-scoping behavior beyond what the annotations and schema already imply.

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 compact sentences, front-loaded with the core purpose and the endpoint tacked on at the end. No waste, though the trailing API note is marginal value.

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 100% schema coverage and no output schema, the essentials are present and annotations carry the safety profile. It falls short of complete because there is no guidance on result shape or the relationship to the many sibling list/get tools.

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 nested age object, dev_mode, model_id, and enable_triage_5 are all fully documented in the schema. The description's only parameter reference, the age filter, repeats what the schema already says, adding no new syntax or semantics. 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 ('List all symptoms in the Infermedica medical model') and scopes it with the age-filter note. The singular sibling get_symptom is implicitly distinguished by the plural/naming convention, but the description never names an alternative to differentiate 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?

Only a parenthetical hint ('optionally age-filtered') gestures at usage. There is no statement of when to call this versus infermedica_get_symptom for one symptom or infermedica_search_concepts for a query, and no conditions or exclusions are given.

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's 'Non-mutating computation' largely restates that. What it does add is the NLP nature and that mentions carry 'states', but it omits any disclosure of return shape, latency, or auth needs. With annotations covering the safety profile, this is adequate but not rich.

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 with the core action front-loaded. 'Engine API: POST /parse' is mildly meta/redundant but does confirm the endpoint, and nothing pads the text.

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 non-mutating parse tool with 100% schema coverage and no output schema, the description covers purpose and output nature (mentions, states, evidence ids). It would be stronger with a note on the relationship between `context` and results, but nothing essential to correct invocation is missing.

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 nine parameters are documented in the schema itself. The description adds nothing parameter-specific (e.g., how context ids interact with parsing), 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?

Specific verb+resource: 'Extract clinical mentions (symptoms / risk factors) and their states from free-text' and states the output form (mapped to Infermedica evidence ids via NLP). This is clearly distinguishable from listing/getter siblings, though it never explicitly contrasts with infermedica_search_concepts, which also maps text to ids.

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 'free-text describing complaints' and 'Engine API: POST /parse', giving context of the parsing step, but there is no when-to-use/when-not guidance and no routing against alternatives like search_concepts or suggest. The agent must infer when parsing is appropriate.

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 safe read profile, so the bar is lower. The description reinforces this with 'Non-mutating computation' and adds the useful detail that the Engine API call is POST /rationale (relevant given the counterintuitive POST for a read). No disclosure of rate limits, auth, or return shape.

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 sentences, zero waste, with the core purpose front-loaded before the mutability note and endpoint. Nothing extraneous.

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?

No output schema exists, yet the description does not indicate what the rationale response contains, and gives no usage context relative to siblings. For a computation tool with nested inputs, this leaves the agent with adequate but incomplete information.

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%, above the 80% threshold, so the schema already documents age, sex, evidence, and dev_mode. The description adds no parameter syntax or format detail beyond casually referencing 'the evidence'. 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+resource: 'Explain WHY the diagnostic engine wants to ask its next question, given the evidence.' An agent can tell it computes a rationale for the next question. However, it does not explicitly differentiate itself from the similarly-named sibling infermedica_explain, so it falls short of a 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?

The phrase 'given the evidence' implies that evidence must be supplied, but there is no explicit when-to-use guidance and no mention of alternatives such as infermedica_explain or infermedica_diagnosis. The agent must infer placement in the workflow.

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 the structured safety signal. The useful added context is that it reuses the diagnosis/triage request body and targets the /recommend_specialist endpoint, but nothing is said about return shape, evidence requirements, or model/Dev-Mode header effects.

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 sentences, zero filler, with the core purpose front-loaded before the non-mutation note and the endpoint. Nothing needs to be trimmed.

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 computation tool with rich schema coverage, an existing readOnly annotation, and no output schema, the description conveys purpose, input reuse, and mutability adequately. It stops short of describing the returned specialist/channel payload, which is the one remaining gap given there is no 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 every parameter (age, sex, evidence, extras, dev_mode, model_id) is already documented in the schema. The description only adds that the body matches diagnosis/triage, which is a mild framing hint rather than parameter-level meaning.

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 names a specific verb ('Recommend') and resource ('the most appropriate medical specialist and consultation channel'), which cleanly separates it from siblings like infermedica_diagnosis and infermedica_triage. It also pins the underlying endpoint (POST /recommend_specialist), but it does not explicitly contrast itself against those siblings.

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?

It states the tool operates on 'the collected evidence' and accepts the same body as diagnosis/triage, which implies it is used on the same evidence payload. However it never says when to choose specialist recommendation over diagnosis or triage, or what prerequisites are needed.

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 the safe read profile, so the description's main remaining job is minor. It adds only an implementation note ('Engine API: GET /search') rather than useful behavioral context such as result shape, ordering, or rate limits. No contradiction with annotations.

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 compact sentences with the core purpose front-loaded and no wasted words. The trailing 'Engine API: GET /search' is mildly implementation-detail padding but harmless.

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 7-parameter search tool with a nested age object and no output schema, the description covers the purpose but says nothing about what results look like or how filters interact, which the absent output schema would otherwise need. Adequate but with clear gaps.

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 (phrase, age, sex, types, dev_mode, model_id, max_results) is already fully documented in the schema. The description adds no parameter meaning beyond that, which is the correct 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 ('Search') plus resource ('medical concept database') and scope ('observations matching a phrase'), with '(autocomplete)' clarifying the interaction style. This is clear and distinguishable from the get_/list_ siblings, though it never names them 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 parenthetical '(autocomplete)' implies the intended use (type-ahead lookup of concepts by phrase), but there is no explicit when-to-use/when-not guidance and no alternatives named against siblings like list_symptoms or get_symptom. Usage must be inferred.

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?

'Non-mutating computation' reinforces the readOnlyHint=true annotation and the POST /suggest endpoint mapping adds useful backend context. However, it says nothing about rate limits, model dependencies, or what the suggestion payload looks like, so the added 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?

Three short front-loaded fragments: purpose, safety trait, endpoint. Zero filler and everything an agent needs to triage scanning is first.

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 8 parameters, nested evidence objects, and no output schema, the definition never describes the shape of the returned suggestions or how many/what form they take (max_results caps count but not structure). For a non-trivial engine call this leaves a real gap, though the schema covers most inputs.

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 already documents nearly every parameter (age units, evidence shape, suggest_method enum, dev_mode header). The description adds no parameter-level meaning beyond that, which is the expected 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+resource ('suggest additional symptoms/observations') and the goal ('speed up the interview'), which distinguishes it from infermedica_diagnosis and infermedica_parse. It stops short of explicitly naming the sibling it competes with or the point at which suggest should be preferred.

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 'to speed up the interview' implies the usage context (mid-interview, before diagnosis), but there is no explicit when-to-use/when-not or reference to alternatives like diagnosis or rationale. Usage is inferable 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 give readOnlyHint=true and the description reinforces it with 'Non-mutating computation', clarifying that the POST is a computation rather than a write. It also discloses the return payload (triage level plus serious/emergency observations), which matters because there is no output 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?

Front-loaded with the outcome and its enumerated values, followed by the non-mutation note and a compact engine reference. Every sentence earns its place, though the raw endpoint ('POST /triage') is slightly incidental.

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-parameter nested-object tool with no output schema, the description usefully names the returned triage level and observations. It stops short of clarifying required-parameter interaction (sex/age) or how partial evidence affects 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 coverage is 83%, so the schema already documents age, sex, evidence, extras, dev_mode, and model_id. The description adds no syntax or format detail beyond the schema and only hints that 'evidence' drives the result. 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 ('Recommend a triage level') plus the exact enumeration of possible outputs, and names the resource (triage). It is clearly separable from sibling infermedica_diagnosis and the rest of the get/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 phrase 'given the evidence' implies a precondition (evidence must already exist, e.g. from infermedica_parse/suggest) but never states when to pick triage over diagnosis or recommend_specialist. Usage is only implied.

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