io.github.lorkorblaq/labloop-mcp

Overview Schema Source Related Servers Discussions Admin

Quote or book a home sample collection

labloop_quote_or_book_collection

Quote and book home sample collection for one or more lab tests in two steps: first receive a combined price quote, then confirm to schedule the collection.

Instructions

Order one or more tests as a single home sample-collection booking. This takes two steps.

Call with confirm=false (default) to get ONE combined quote: each test's center and price, a logistics fee, and the grand total. Nothing is booked.
After the user explicitly approves, call again with the same arguments and confirm=true.

Address, phone, and email fall back to the user's saved profile, and new details are saved back after booking. Status values: needs_info (ask the user for 'missing'), invalid_test_id, needs_confirmation (show the quote), successful (simulated booking with collectionId and schedulingId).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	No
`notes`	No
`address`	No
`confirm`	No	Leave false (the default) to get a quote only: each test's price and center, the logistics fee, and the grand total. Nothing is booked. Set true ONLY in a later call, after the user has seen the quote and explicitly agreed.
`user_id`	Yes	Identifier for the demo user, e.g. 'demo-user-1'. Any stable string works; reuse the same value across calls so saved details are remembered.
`test_ids`	Yes	Ids of ALL tests to include in this order. Pass every requested test in ONE call to get one combined quote and one booking. Each item must be an exact 'id' from a prior labloop_find_test or labloop_list_tests result.
`care_type`	No		one-time
`date_time`	No
`phone_number`	No
`provider_name`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server