io.github.lorkorblaq/labloop-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| labloop_list_testsA | List every test in the LabLoop catalog with its id, name, abbreviation, and category. Use to browse what is available, or when labloop_find_test cannot find what the user means. Returns {status, count, tests: [{id, name, abbrev, category}]}. |
| labloop_find_testA | Look up a medical test by name or abbreviation to get its id and details. Details include description, eligible gender, turnaround time (hours), preparation advice, and sample type. Returns one of:
|
| labloop_get_test_providersA | Get the test centers offering a test and their prices, cheapest first. Returns {status, testId, testName, currency, providers: [{provider, price}]}, or {status: "invalid_test_id"} if the id is unknown. |
| labloop_quote_or_book_collectionA | Order one or more tests as a single home sample-collection booking. This takes two steps.
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). |
| labloop_get_user_profileA | Fetch the demo user's saved contact details (name, phone, address, email). Useful before booking, to avoid asking for details already on file. Profiles live in server memory only. Returns {status: "successful", profile} or {status: "not_found"}. |
| labloop_update_user_profileA | Save new or corrected contact details so future bookings can reuse them. Only the fields provided are changed. Returns {status, updated_fields, profile}. |
| labloop_escalate_to_humanA | Hand the conversation to a human support agent (SIMULATED in this demo). 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. Logs a ticket in memory and returns {status, simulated: true, ticketId, message}. No real message is sent. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct resource or action: catalog listing, test lookup, provider pricing, booking, profile get/update, and human escalation. The list/find pair is explicitly differentiated by description, and no two tools appear interchangeable.
All tool names consistently use the labloop_ prefix with snake_case verb_noun patterns like list_tests, find_test, get_test_providers, and update_user_profile. The compound quote_or_book_collection is longer but still follows the same predictable convention.
Seven tools is well-scoped for this domain: catalog discovery, pricing, booking, profile management, and escalation. Each tool earns its place with no redundant or filler tools.
Core workflows are covered: browse/find tests, get providers, quote and confirm a booking, and manage user profile. However, there is no way to look up past bookings or cancel a collection, leaving a minor dead end after a successful booking.