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

The annotations only set all hints to false, providing no safety or side-effect information, so the description must carry the full burden. It discloses that the action is simulated, logs a ticket in memory, returns a specific object structure, and that 'No real message is sent.' This is comprehensive and goes beyond what annotations convey.

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

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

The description is three sentences: the first states the core action and simulation, the second gives usage criteria, and the third explains the outcome and return value. It is front-loaded with the primary purpose and every sentence adds value without 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?

The tool has a clear output schema (as indicated by 'Has output schema: true'), and the description explicitly states the return structure ({status, simulated: true, ticketId, message}) and that no real message is sent. For a simple two-parameter tool with a well-defined use case and simulation caveat, nothing an agent needs to invoke it correctly 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%, with both parameters already having clear descriptions ('Brief summary of the conversation so far' and 'The user's request or problem'). The description text does not add additional semantic meaning beyond what the schema already provides, so the baseline score 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?

The description clearly states the action: 'Hand the conversation to a human support agent' with a specific resource (human agent) and explicitly notes it is SIMULATED in this demo. It also differentiates from sibling tools by indicating it is for cases 'beyond the other tools' and for user frustration, giving it a distinct scope.

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 provides explicit conditions for use: 'when the user asks for a real person, has a complaint, is frustrated, keeps hitting errors, or the request is beyond the other tools.' This is precise and actionable, and implies that other tools should be tried first, making it clear when this tool is the appropriate fallback.

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 annotations already establish that this is a read-only, idempotent operation and unambiguously safe to invoke. Beyond that, the description adds meaningful behavioral detail: it enumerates three possible return states (found, ambiguous, not_found) and gives explicit directives for each, such as asking the user to pick one or offering close suggestions. This is valuable behavioral transparency that surpasses what annotations convey.

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

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

The description is four sentences, front-loaded with the primary purpose followed by a compact list of return statuses. Every sentence contributes necessary operational or decision-making information. There is no filler, redundancy, or verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter, a rich schema description, a declared output schema, and comprehensive annotations, the tool description fully equips an agent to invoke it correctly. It explains the three possible outcomes and how to respond to each, leaving no ambiguity about the tool's behavior or subsequent steps.

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

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

The input schema provides a highly detailed description of the 'name' parameter, including substring-match semantics, how to strip filler words, and concrete examples. The tool description merely restates 'name or abbreviation' and does not add meaning beyond the schema. With 100% schema coverage, 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?

The description opens with a specific verb and resource: 'Look up a medical test by name or abbreviation to get its id and details.' This clearly identifies the tool's core function and distinguishes it from siblings like labloop_list_tests (listing all tests) and labloop_get_test_providers (retrieving providers). The scope is unambiguous.

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 provides clear contextual usage guidance, such as 'use test.id in later calls', which implies the tool is a prerequisite step for other operations. It does not explicitly name alternatives or state when not to use this tool, but the return-status handling instructions effectively route the agent's next steps. This is clear context without formal 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, idempotentHint, destructiveHint, and openWorldHint. The description adds useful behavioral detail beyond those annotations: results are sorted cheapest first, and an invalid id returns '{status: "invalid_test_id"}' rather than throwing. This meaningfully informs an agent's expectations.

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

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

The description is compact: one sentence states the core behavior and ordering, and a second sentence gives the exact return shape and error case. No filler or repetition exists.

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 one parameter, an output schema, and rich annotations, the description covers everything needed: the resource, the sort order, the return structure, and the invalid-id behavior. The parameter schema also supplies the prerequisite call guidance.

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 test_id parameter is already well documented with an example, a warning against using test names, and a fallback instruction to call labloop_find_test first. The main description adds no additional parameter semantics beyond what the schema provides, 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?

The description uses a specific verb and resource: 'Get the test centers offering a test and their prices', and explicitly notes ordering ('cheapest first'). This clearly differentiates it from siblings like labloop_find_test and labloop_list_tests, which focus on finding/listing tests rather than providers and pricing.

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 parameter description gives clear usage context: the test_id must be the exact 'id' from a prior labloop_find_test or labloop_list_tests result, and if no id is visible, the agent should call labloop_find_test first. It does not explicitly state when to prefer this tool over quote_or_book_collection, so it stops short of a full when/when-not contrast.

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, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: profiles live only in server memory, and the tool returns either a successful profile or a not_found status. This gives the agent useful expectations about persistence and failure modes.

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

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

The description is compact and front-loaded: purpose, usage context, persistence caveat, and return contract are each covered in a few short sentences. Every sentence earns its place with no filler or repetition.

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 single well-documented parameter, the description covers the purpose, the appropriate timing, the memory-only caveat, and the possible return statuses. There is no meaningful gap an agent would face when deciding whether to call this 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 100%, and the user_id parameter already has a detailed description with an example and guidance to reuse the same value. The tool description does not need to repeat parameter details, so the baseline score 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?

The description begins with a specific verb ('Fetch') and names the exact resource ('demo user's saved contact details') including the fields returned. It is clearly distinguished from sibling labloop_update_user_profile, which writes rather than reads.

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 gives a concrete usage context: 'Useful before booking, to avoid asking for details already on file.' It does not explicitly state when not to use it or name alternative tools, but the read-vs-update contrast with sibling tools makes the intended use reasonably 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the return shape ({status, count, tests}) which is useful behavioral context beyond the annotations. However, it doesn't disclose potential size limits, pagination, or performance characteristics of listing the entire catalog, which would be valuable for a list-all operation.

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

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

The description is compact and front-loaded: the first sentence states the core function and output fields, the second gives usage context, and the third specifies the return shape. Every sentence earns its place with no 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 zero-parameter, read-only list tool with an output schema and full annotation coverage, the description is complete. It tells the agent what the tool does, when to use it, and what it returns. Nothing essential 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?

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds value by explaining what the response contains and the purpose of the list, which is more than the empty schema provides. Baseline 4 for zero-param tools 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?

The description clearly states the tool's function: 'List every test in the LabLoop catalog' with specific fields (id, name, abbreviation, category). It distinguishes itself from siblings by explicitly mentioning labloop_find_test as an alternative when the find tool fails.

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 provides explicit usage guidance: 'Use to browse what is available, or when labloop_find_test cannot find what the user means.' This tells the agent exactly when to use this tool versus the sibling find tool, which is strong 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?

Annotations are all false, but the description compensates by disclosing the two-step confirmation behavior, status values, fallback to saved profile, and saving new details after booking. It also notes that booking is simulated, which is important context beyond 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?

The description is lengthy but well-organized into numbered steps and lists status values. Every sentence adds value for a complex tool; while it could be tightened, the structure and front-loading of the core purpose justify a high score.

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 10-parameter tool with a low schema coverage, the description covers all essential aspects: two-step flow, status values, fallbacks, and provider selection. The output schema exists, so the description need not explain return values. It is complete 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 coverage is only 30%, so the description carries the burden. It thoroughly explains test_ids (must be exact ids, never names), confirm (boolean semantics), provider_name (fallback behavior), and address/phone/email fallback. This adds significant 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?

The description clearly states the verb and resource: 'Order one or more tests as a single home sample-collection booking.' It distinguishes the two-step quote/confirm flow and references sibling tools for test selection and provider lookup, making the purpose unambiguous.

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 instructs when to call with confirm=false to get a quote and when to call with confirm=true after user approval. It also tells the agent to pass all tests in one call and to first call labloop_find_test if IDs are not visible, providing clear usage direction.

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 indicate idempotentHint=true and destructiveHint=false, and the description adds useful behavioral context: it performs a partial update ('Only the fields provided are changed') and returns a specific response shape ({status, updated_fields, profile}). This goes beyond the annotations and helps the agent understand side effects and return 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?

The description is three sentences, front-loads the main purpose, and includes the most important behavioral detail (partial update) and return shape. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover idempotency/safety, the description is fairly complete. It could mention that this is a write operation (though 'Save' implies it) or explicitly contrast with labloop_get_user_profile, but for a simple partial-update tool, the essential context is present.

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 only 20%, but the description adds the key semantic that only provided fields are changed, which is critical for understanding the nullable/default parameters. However, it doesn't elaborate on each parameter beyond what the schema already provides; the schema itself has decent per-field descriptions for name, email, phone, address, and user_id. The description compensates partially but not fully for the low coverage.

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 clear verb ('Save') and resource ('user details' / 'contact details'), and explains the purpose: reuse for future bookings. It is distinguishable from siblings like labloop_get_user_profile, though it doesn't explicitly name that sibling.

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 'Only the fields provided are changed,' which gives clear partial-update semantics and implies when to use it (when you have corrected/new contact details). It doesn't explicitly contrast with labloop_get_user_profile or other siblings, but the context is clear enough for an agent to select it for updating profile fields.

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