Mediora Lab Catalog

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

Annotations already establish that this is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral detail by enumerating what the explainer includes, which is valuable because there is no output schema. It does not describe not-found behavior, but the annotation coverage lowers the bar.

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, front-loaded with the core action and followed by the returned content. There is no filler or redundancy.

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 lookup with a fully described two-parameter schema, the description covers the purpose and the returned content well enough. The main gaps are not-found behavior and explicit sibling differentiation, which are minor but real.

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 both the slug and lang parameters are already documented. The description adds only that the lookup is 'by slug' and that the result is a full explainer; it does not add syntax, format, or semantic detail 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: returns the full explainer for a clinical condition by slug. The resource is clear enough to separate it from explain_marker, explain_panel, and explain_symptom, but it does not explicitly name those siblings or clarify 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 used when an agent has a condition slug and needs the explainer, but it gives no explicit when-to-use guidance, no when-not-to-use guidance, and no alternatives. The schema mentions list_conditions for slug discovery, but that guidance is not in the description 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that by describing the returned sections and the non-obvious conditional: action fields are empty when the value follows an underlying cause. It does not cover language fallback or unknown-slug 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?

Front-loaded with the purpose, then a single dense but purposeful sentence enumerating returned content. The clause about empty action fields is slightly convoluted but earns its place by preventing a misread of an empty result.

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 carries the burden of explaining return content and even an edge case in the payload. Minor gaps remain: no mention of the lang default's effect on output or error behavior for an unknown slug.

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 both slug and lang fully documented including the canonical slug examples and enum values, so baseline is 3. The description mentions the slug input but adds no new semantics such as slug normalization or what 'lang' affects in the response.

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 ('Return the full explainer for a single blood-test marker by slug') and enumerates the content, so the agent knows exactly what it gets. It does not explicitly distinguish itself from nearby siblings like mediora__lookup_marker or mediora__get_test_details, which likely also take a slug.

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: 'by slug' hints this is the deep-detail call, but there is no statement of when to prefer it over lookup_marker or get_test_details, nor any exclusion. Slug discovery guidance lives in the schema, not the description, so the routing logic is left 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 readOnly, idempotent, non-destructive, closed-world behavior, so the burden is light. The description still adds useful substance: the response is a shallow projection (slug + name + one-line summary, not full marker detail), and it discloses the alias field that the schema doesn't mention. No return shape or edge-case (unknown slug) behavior is stated, keeping it below a 5.

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 tightly packed sentences, front-loaded with the return contract, then the user question it answers, then the follow-up route. The alias parenthetical is dense but earns its place as illustrative input examples.

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 compensates by enumerating the returned fields and the alias list. Combined with the schema's own slug-discovery pointer to mediora__list_panels, an agent has everything needed to call this correctly.

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 100%, so a 3 is the floor. The description goes beyond it by making explicit what the slug resolves to and that names/summaries are the localized payload, which implicitly explains the purpose of the 'lang' parameter; concrete panel-slug examples reinforce the expected format.

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 ('Return the markers that make up a lab panel by slug') and names what is returned (marker slug, name, one-line summary, plus panel aliases). It is clearly distinct from sibling mediora__explain_marker, which it explicitly positions as the deeper-detail 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?

Gives a concrete triggering question ('what's included in a CBC / lipid panel / CMP') and routes the agent onward to mediora__explain_marker for full detail. It does not state an explicit when-not-to-use or point to mediora__list_panels for slug discovery in the description (that lives in the schema), so it falls just short of full coverage.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the returned content (meaning, causes, lab work-up, urgent-evaluation criteria) and the side-car slug arrays that enable graph traversal. Missing: behavior for an unknown slug or translation fallback.

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: the action and scope come first, then the payload contents and the graph-following hint. No filler and no repetition of the 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?

With no output schema, the description usefully enumerates the explainer's sections, which is exactly the burden it must carry. For a two-parameter read tool that is close to sufficient; only error/edge behavior (unknown slug, language fallback) is left unstated.

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 both slug and the lang enum are already documented, including slug discovery guidance. The description only restates 'by slug' and adds no format or normalization detail beyond the schema. There is a minor inconsistency worth noting: the schema points to list_markers/list_conditions for slug discovery, while this is a symptom tool (list_symptoms exists).

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: 'Return the full triage explainer for a single symptom by slug', and enumerates the sections returned. It is clearly a per-symptom detail lookup, distinct from the list_* siblings, though it never names the alternative tools by contrast (only as downstream graph hops).

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 'for a single symptom by slug', and the second sentence gives forward guidance on following related marker/condition arrays into mediora__explain_marker / explain_condition. There is no explicit statement of when to use this instead of mediora__list_symptoms or lookup_marker, and no prerequisites or 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value by stating the returned fields (slug, name, ICD-10 code) and that the list is exhaustive ('every'), implying no pagination. It does not discuss ordering or the language parameter's effect on labels.

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 resource scope front-loaded and the return shape and alternative following in priority order.

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 one-parameter read-only list tool with no output schema, the description supplies the return fields and the sibling routing the agent needs. Ordering and language fallback behavior are the only minor unspecified details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single optional 'lang' parameter is documented with an enum in the schema itself. The description adds no semantics 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 ('List every clinical condition in the Mediora catalog') and immediately declares the return fields. It is clearly distinguishable from the explain_* and list_* siblings without opening any schema.

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 final sentence explicitly routes the agent to mediora__explain_condition when a full explainer is needed, which is the main sibling overlap. There are no explicit exclusions beyond that, but the catalog-vs-detail split is clear.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new information by naming the return shape ('slug + short name per entry'), 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?

Two short sentences, the scope statement first and the alternative second; every clause carries information and nothing is padded.

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 trivial enumeration tool with full annotation coverage, the description supplies the missing return shape and points at the natural next call. Ordering, entry count, or whether markers are grouped by panel are unstated but not critical.

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?

With one optional parameter at 100% schema coverage and an enum plus default documented in the schema, the schema does the heavy lifting. The description never mentions the lang parameter or what happens when a translation is missing, so it adds nothing beyond structured data.

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 every blood-test marker in the Mediora catalog') and pins the scope to the whole catalog, which separates it from lookup_marker and the explain_* siblings. An agent knows exactly what it gets without opening the schema.

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?

Explicitly routes to mediora__explain_marker when the agent needs the full explainer, which is the most likely follow-up. It doesn't address lookup_marker or list_panels, so the discovery-vs-lookup boundary is left implicit, keeping this just short of a 5.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the description adds value by disclosing the return shape (slug, name, marker count). It stops short of noting result size or whether the list is static/paginated, but that's a minor gap for a small fixed catalog.

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, front-loaded with the core action, then the routing hint. The long parenthetical enumeration of panel types is slightly bulky but communicates catalog coverage and is the most informative part of the description.

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 supplies the return fields and the sibling pointer, which is everything an agent needs to call a zero-arg list tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing to disambiguate; baseline is 4. The description correctly avoids inventing filtering options.

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 (List) and resource (lab panels in the Mediora catalog), enumerates representative panel types, and specifies the return payload (slug + name + marker count). It also distinguishes itself from mediora__explain_panel by name.

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?

Explicitly routes marker-level lookups to mediora__explain_panel, making the boundary between the two tools clear. It doesn't state preconditions or when-not to call it, but for a zero-arg catalog listing that context is mostly implicit.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (slug + short name) and the fact that this is a bounded catalog enumeration rather than a filtered query. It does not mention language behavior, which is the one remaining behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both earning their place: the first defines scope and return shape, the second routes to the correct sibling. The core purpose is front-loaded with zero preamble.

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 one-parameter catalog lister with no output schema, the description supplies everything required: what is listed, what comes back, and when to prefer the richer sibling. Annotations cover the safety profile and the schema covers the language option, so no material gap remains.

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 the single lang parameter is fully documented with an enum, so the schema does the heavy lifting and a 3 is the baseline. The description never mentions that output is language-selectable, adding no meaning over the schema, though nothing is misleading.

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 plus resource ("List every patient-side symptom in the Mediora catalog") and grounds it with concrete examples (fatigue, joint pain, headache). It explicitly distinguishes itself from the sibling mediora__explain_symptom, so an agent can choose between the two without opening a schema.

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?

Names the alternative tool explicitly (mediora__explain_symptom) and states the condition that selects it: when the agent needs the full triage-oriented explainer with lab work-up. The implicit inverse — use this tool for a plain enumeration — is also clear from the first sentence.

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/idempotentHint, so those add nothing. The description contributes real behavioral context beyond them: matching is fuzzy over aliases across three languages, and the result is a canonical slug rather than a full record. It doesn't say how many matches come back or how ties are ranked, keeping it off a 5.

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, no filler. The core action and language scope come first, and the motivating use case follows as supporting context.

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 two-parameter lookup with no output schema, the description covers purpose, input expectations, and the shape of the return (a slug). It omits what happens on multiple or zero matches, a minor but real gap for a fuzzy-search 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 coverage is 100%, so baseline is 3. The description adds meaningful semantics the schema doesn't: `query` is matched fuzzily against aliases, not exact names, so partial and transliterated inputs are acceptable. `lang` handling is left entirely to 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 ('fuzzy-search markers by alias'), scopes it to EN/RU/HE, and implies the output ('canonical Mediora slug'), which separates it cleanly from explain_marker and list_markers.

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?

Gives a concrete triggering condition: the caller has a lab-local name rather than a canonical slug, with examples in three scripts. It does not explicitly name an alternative tool or state when not to use it, so it falls short of the top band.

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