Cash-pay lab tests: catalog search, all-in quotes by state, draw sites by ZIP, reviewed ranges.
Calculate free and bioavailable testosterone from total testosterone, SHBG and albumin using the Vermeulen (1999) mass-action equation — the method behind lab-reported 'calculated free testosterone'. Educational; not a diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| shbg | Yes | SHBG in nmol/L | |
| totalT | Yes | Total testosterone | |
| albuminGdL | No | Albumin in g/dL (default 4.3) | |
| totalTUnit | No | Default ng/dL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, idempotent, and non-destructive, lowerng the bar. The description adds valuable behavioral context by exposing the underlying formula, noting it produces both free and bioavailable testosterone, and clarifying that it is educational rather than diagnostic.
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 a tight single statement that front-loads the action, inputs, and method. The 'Educational; not a diagnosis' clause adds important scope without waste, and every part of the description earns its place.
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 calculator with strong schema coverage and helpful annotations, the description states inputs, method, and outputs at a conceptual level. It does not describe output units in prose, but the schema already documents units and defaults, so the remaining gap is minor.
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 parameters, including units and the default for albumin. The description confirms how total testosterone, SHBG, and albumin feed into the equation, but does not add meaning beyond what the schema provides.
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 ('calculate'), an unambiguous resource (free and bioavailable testosterone), and the exact method (Vermeulen 1999 mass-action equation). It also distinguishes itself from interpretive siblings by stating it is educational and not a diagnosis.
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 clearly implies a calculation use case, but it does not explicitly state when to use this tool versus alternatives such as interpret_results or lookup_reference_range. The 'not a diagnosis' caveat hints at exclusion but does not provide firm routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For one blood test, the all-in single-test price (sticker + per-order fees) at TestWell and at every tracked direct-to-consumer provider with a verified equivalent — JustLabs, Quest, Labcorp OnDemand, Ulta Lab Tests, Walk-In Lab, HealthLabs and more — each with the date it was verified, plus typical hospital self-pay and Quest Direct reference prices. States the multi-test caveat (fees are paid once per order). Source: the TestWell Blood Test Price Index (CC BY 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | Test slug or name, e.g. 'tsh', 'lipid panel', 'vitamin-d' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, and the description adds valuable behavioral context: it returns verified dates, includes reference prices, states the multi-test fee caveat, and cites the data source. This goes well beyond the structured 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 dense but well-organized, leading with the core purpose and then adding caveats and source attribution. The provider list is somewhat long, but it is substantive for an agent deciding whether this tool covers a given provider.
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 single-parameter read-only tool, the description fully covers what data is returned, the scope of comparison, a relevant caveat, and the data source. Nothing essential for selecting or invoking the tool 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?
The input schema already documents the single 'test' parameter with examples and 100% coverage. The description adds minimal new parameter-level meaning beyond emphasizing 'one blood test,' so the 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?
The description names a specific verb ('compare'), a clear resource (all-in single-test prices across providers for one blood test), and enumerates exactly which providers and reference prices are included. It also distinguishes this from siblings by narrowing scope to price comparison for a single test.
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 opening phrase 'For one blood test' clearly signals the intended use case, and the multi-test caveat explains a key limitation. It does not explicitly name alternative sibling tools or state when not to use it, but the usage context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Honest side-by-side of TestWell and another direct-to-consumer lab service (Quest Direct, Labcorp OnDemand, Function Health, JustLabs, Ulta Lab Tests, …): pricing model, per-order fees, labs, turnaround, where each wins, spot prices on common tests as sticker AND all-in, with verification dates and sources. Call with no argument to list the providers covered.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Competitor slug or name, e.g. 'quest-direct', 'Function Health', 'justlabs' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, so the description's job is lighter. It adds useful behavioral context: the response includes verification dates and sources, and calling with no argument lists covered providers rather than producing an error. This gives the agent an accurate model of the tool's output expectations without contradicting the 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 key purpose is front-loaded in the first phrase and the final sentence provides an essential behavioral instruction. The description is information-dense without repetition, but the long parenthetical provider list and the word 'Honest' add minor noise that could 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?
With no output schema, the description carries the burden of explaining what the agent will receive, and it does so thoroughly: pricing model, per-order fees, labs, turnaround, competitive strengths, sticker vs. all-in spot prices, verification dates, and sources. It also covers the no-argument edge case. Nothing material is missing for this tool's complexity.
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 schema already documents the optional provider parameter with examples at 100% coverage, so the baseline is 3. The description goes beyond the schema by listing a broader set of acceptable providers and, more importantly, by defining the no-argument call as the way to enumerate providers. It does not specify normalization rules, but that is not necessary here.
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 is specific: it compares TestWell with another named category of direct-to-consumer lab service, and enumerates the dimensions compared (pricing model, fees, labs, turnaround, where each wins, sticker vs. all-in spot prices). This clearly distinguishes it from the sibling compare_prices, which is price-focused, by signaling a broader side-by-side provider comparison.
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 makes the usage context clear: call this tool when a side-by-side comparison of TestWell against another direct-to-consumer lab service is needed. It also gives an explicit no-argument invocation behavior to list covered providers. However, it never addresses when not to use it or points to alternatives such as compare_prices, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a lab value between US conventional and SI units for 30 common analytes (glucose, cholesterol, testosterone, vitamin D, …) using published factors; hemoglobin A1c uses the NGSP↔IFCC master equation and also returns estimated average glucose.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The numeric value to convert | |
| analyte | Yes | Analyte slug or name, e.g. 'glucose', 'total-cholesterol', 'testosterone', 'vitamin-d', 'a1c' | |
| direction | No | Default toSI (US → SI) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it uses published factors, A1c follows the NGSP↔IFCC master equation, and A1c also returns estimated average glucose. It does not describe the full output shape, but this is minor for a simple read-only conversion.
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 a single, front-loaded sentence with no filler. Every part earns its place: the action, the scope, the examples, the method, and the A1c exception.
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 low-complexity, read-only conversion tool, the description combined with the schema gives an agent enough to select and invoke it correctly: required parameters, direction default, analyte examples, and special A1c behavior. A full analyte list or explicit return-shape statement would be a minor enhancement, but the essential guidance 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 100%, so the schema already documents all three parameters well. The description reinforces analyte semantics with examples and the 30-analyte limitation, but it does not substantially elaborate on the value or direction parameters beyond what the schema already provides. 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?
The description states a specific verb ('Convert'), a clear resource ('a lab value between US conventional and SI units'), and a concrete scope ('30 common analytes' with examples). It inherently distinguishes itself from all siblings, none of which perform unit conversion.
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 when to use the tool: whenever a lab value needs US↔SI conversion for one of the 30 common analytes, with special A1c behavior. However, it does not explicitly mention alternatives or state when not to use it, such as when needing free testosterone calculation or reference range lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Quest Diagnostics, Labcorp and BioReference patient service centers near a US ZIP code, with address, distance, phone and hours. Walk-ins are accepted at most sites; the requisition arrives by email after physician authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| lab | No | Limit to one lab | |
| zip | Yes | 5-digit US ZIP code | |
| limit | No | Max sites (default 10) | |
| radiusMiles | No | Search radius in miles (snapped to 10/20/25/50/100; default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful real-world context: walk-ins are generally accepted, and the requisition is delivered by email once physician authorization exists. This tells an agent about expected workflow and caveats without contradicting the 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 sentences, front-loaded with the core action and result fields, followed by relevant caveats. Every clause earns its place with no redundant filler.
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 required parameter and full schema documentation, the description covers the purpose, returned fields, and key process caveats (walk-ins, authorization email). Nothing essential for selecting or invoking the tool 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 coverage is 100%, and the description does not need to restate parameter details; the schema already explains zip format, defaults, and radius snapping. The description adds only a general link between labs and the enum values, so it stays at the baseline for fully documented schemas.
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 ('Find') plus a precise resource (Quest Diagnostics, Labcorp and BioReference patient service centers), a location qualifier (near a US ZIP code), and expected result fields (address, distance, phone, hours). This clearly distinguishes it from the sibling tools, none of which target draw-site location lookup.
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 makes the invocation context obvious: whenever a patient needs draw sites near a ZIP code, this is the tool. It does not explicitly name when-not-to-use or a competing sibling, but none of the listed siblings perform this function, so the absence is not a material gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one of TestWell's educational pages as Markdown: guides (/guides/), condition workups (/conditions/), test decision guides (/answers/), biomarker pages (/biomarkers/), state pages (/lab-locations/) or comparisons (/compare/). Call with no path to list the available guides and conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Spanish version when one exists (default en) | |
| path | No | Site path, e.g. '/guides/annual-blood-work' or 'conditions/anemia' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context: the output format is Markdown, the accepted path categories are given, and the empty-path listing behavior is disclosed. This goes beyond the annotations without contradiction.
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 one tightly written sentence plus one short behavioral instruction. The primary purpose is front-loaded and every clause carries useful information 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?
For a read-only, idempotent, non-destructive tool with two optional parameters and no output schema, this description is complete: it covers all supported page types, provides URL templates, notes language availability, and describes the default no-path behavior.
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 100% description coverage for both parameters, so the baseline is 3. The description adds extra semantics by stating that omitting path yields the list of guides/conditions and by listing the valid path prefixes beyond the schema's two examples.
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 the action ('Return') and resource ('TestWell's educational pages as Markdown') and enumerates six specific page types with URL patterns. This clearly distinguishes it from siblings like get_test and search_tests.
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 makes the tool's purpose clear and even specifies the no-path invocation to list available guides. However, it does not explicitly mention when to prefer a sibling tool or provide when-not guidance, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full public detail for one TestWell test or panel by slug or id: description, biomarkers, CPT, per-lab prices, labs, fasting/prep, turnaround, included tests (panels), FAQ, related conditions, order URL and a Markdown page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Spanish prose where a translation exists (default en) | |
| slug | Yes | Catalog slug (from search_tests) or id, e.g. 'tsh', 'general-wellness-panel' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), lowering the burden. The description adds value by disclosing that the data is 'public' (no auth or user-specific context) and by specifying the breadth of the return payload, including URLs for ordering and Markdown pages, which an agent would otherwise not know without an output schema. 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?
One dense sentence front-loads the core function and then uses a colon-led list to enumerate return contents efficiently. Every element earns its place, and the enumeration is especially justified given the absence of an output schema.
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 carries the burden of explaining return value composition, and it does so thoroughly across pricing, labs, prep, panels, FAQ, conditions, and URLs. Combined with strong annotations and fully documented parameters, an agent has everything needed to select and invoke this 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?
Schema description coverage is 100%, so both slug and lang are already documented, including the example values 'tsh' and 'general-wellness-panel'. The description confirms that the slug accepts an id and mentions the language option only indirectly through 'Spanish prose' context; it does not add material parameter meaning beyond the schema, 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?
The description opens with a specific verb and resource ('Full public detail for one TestWell test or panel') and names the lookup key ('by slug or id'). The enumerated content fields (biomarkers, CPT, per-lab prices, labs, fasting/prep, turnaround, FAQ, related conditions) make the scope unmistakable and clearly distinguish it from siblings like search_tests, list_panels, and compare_prices.
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 usage context is implied: this is the tool for full detail on a single test/panel, contrasted with list_panels for browsing or compare_prices for pricing comparisons. However, the description never explicitly names an alternative or states when not to use it; the routing hint that slugs come from search_tests lives in the input schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag each pasted lab value as low / normal / high against TestWell's physician-reviewed reference catalog (130+ markers; sex- and age-specific bands where they exist), with the reviewed 'what high/low suggests' copy, retest guidance, cited sources and links to the marker's page and, where one exists, its high/low interpretation page. Stateless — values are not stored or logged. Educational, not a diagnosis; the user's own report range takes precedence.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| sex | No | ||
| values | Yes | Results to explain, e.g. [{marker:'TSH', value:5.2, unit:'mIU/L'}, {marker:'ferritin', value:12}] | |
| pregnancy | No | ||
| postmenopausal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: values are not stored or logged, it is educational not diagnostic, and the user's own report range takes precedence. This exceeds the annotation-only information without contradicting it.
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 with the core action, followed by output details and caveats. It is slightly dense but every clause adds information; 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?
Given there is no output schema, the description does a good job enumerating what the user receives: flags, interpretation copy, retest guidance, citations, and links. It omits edge-case behavior like missing markers or ambiguous units, but these are not critical for a safe, stateless interpretation 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 only 20%, and the description does not adequately compensate. It mentions 'sex- and age-specific bands,' which hints at the age and sex parameters, but pregnancy and postmenopausal are not explained anywhere. The values parameter is only minimally described via the schema example.
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 a specific action ('Flag each pasted lab value as low / normal / high') and a specific resource (TestWell's physician-reviewed reference catalog). It also distinguishes itself from siblings like lookup_reference_range by focusing on interpretation and flagging rather than just returning ranges.
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 when to use it — when a user has lab values to interpret — but does not explicitly contrast it with alternatives such as lookup_reference_range or convert_units. It gives a clear context but no exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TestWell's bundled panels (multi-test packages priced below the sum of their tests), optionally filtered by category or maximum price. Sorted by price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| category | No | Catalog category, e.g. 'Hormones', 'General Health' | |
| maxPrice | No | Only panels at or under this sticker price (USD) |
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 useful behavioral context beyond annotations: results are sorted by price and panels are priced below the sum of their individual tests. No contradictions 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?
The description is a single efficient sentence that front-loads the resource, defines it, notes the optional filters, and states the sort order. Every part earns its place with no redundant or vague filler.
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 three optional parameters and no output schema, the description covers the domain meaning, filter options, and sort behavior. It could be slightly more complete by noting the default result limit or the shape of returned items, but the schema handles the limit default and the intent is clear.
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 input schema fully documents limit, category, and maxPrice. The description mentions filtering by category or maximum price but does not add significant semantic detail beyond what the schema already provides. This matches the baseline for complete schema 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 uses a specific verb ('List') and resource ('TestWell's bundled panels'), and adds a parenthetical definition that clarifies exactly what a panel is. The optional filters and sort order make the tool's scope unambiguous and distinguish it from sibling tools like search_tests or get_test.
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 for browsing catalog panels and supports filtering by category or max price, but it does not explicitly state when to choose this over sibling tools such as search_tests or recommend_tests. There are no exclusions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Physician-reviewed reference range for a blood test marker (130+ markers), filtered by sex and age when they matter, with what high and low values suggest, retest cadence, how to get tested, cited sources and the review date. Educational; the user's own report range takes precedence.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| sex | No | ||
| marker | Yes | Marker name or alias, e.g. 'TSH', 'ferritin', 'HbA1c', 'LDL' | |
| pregnancy | No | ||
| postmenopausal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: filtering by sex/age when relevant, the contents returned (high/low implications, retest cadence, testing instructions), cited sources, review date, and the educational precedence caveat. 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?
The description is one information-dense sentence with no filler, repetition, or vague wording. It front-loads the core purpose and then adds distinct facts: marker count, filtering behavior, output contents, source/review information, and the educational caveat.
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 does well by explaining what the agent can expect: reference range, high/low interpretations, retest cadence, how to get tested, cited sources, and review date. It is slightly incomplete in not addressing how to handle unknown markers or clarifying the optional pregnancy/postmenopausal inputs, but it is still sufficient for a simple read-only lookup 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 only 20%, so the description must compensate. It does add meaning for age and sex ('filtered by sex and age when they matter'), but it does not explain pregnancy or postmenopausal parameters, which are likely relevant optional filters. The marker parameter is already described in the schema, so the description only partially fills the coverage gap.
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 names the verb and resource: lookup of a physician-reviewed reference range for a blood test marker. It adds scope (130+ markers), the filtering dimensions (sex and age), and the content categories returned, making it easy to distinguish from siblings like interpret_results or recommend_tests.
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 no explicit when-to-use or when-not-to-use guidance and does not name alternative tools. It implies an educational use case and notes that the user's report range takes precedence, but it leaves tool selection among siblings to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a set of tests/panels exactly as TestWell's checkout would: per-lab prices for the user's state (New York and New Jersey route to BioReference; Rhode Island is not served), the single $6 lab processing fee, the total, items that can't be ordered and why, and a prefilled cart URL. Use this before quoting any total to a user.
| Name | Required | Description | Default |
|---|---|---|---|
| lab | No | Preferred lab outside NY/NJ (default quest) | |
| items | Yes | Catalog slugs or ids, e.g. ['tsh', 'vitamin-d'] | |
| state | No | US state code or name where the user will be drawn, e.g. 'FL' or 'Florida' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the non-destructive/read-only annotations, the description discloses important behaviors: NY/NJ route to BioReference, Rhode Island is not served, the flat $6 fee, unorderable-item reasons, and the prefilled cart URL. This is substantive behavioral context that annotations alone do not provide.
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 dense but well-organized, front-loading the core action before listing the expected outputs and the usage mandate. Every clause adds value; there is no filler or redundant restatement of the tool name.
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 present, the description fully compensates by enumerating the return contents: per-lab prices, state routing, the fee, total, non-orderable items with reasons, and the prefilled cart URL. It also covers key edge cases such as NY/NJ routing and Rhode Island exclusion, making it complete for a quoting operation.
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 the baseline is 3. The description adds meaning beyond the schema by clarifying how `state` affects lab routing and that `lab` is the preferred lab outside NY/NJ. This helps the agent choose parameter values correctly without restating schema definitions.
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: 'Price a set of tests/panels exactly as TestWell's checkout would'. It then enumerates the concrete outputs (per-lab prices, fee, total, unorderable items, cart URL), making the tool's role unmistakable and clearly distinct from siblings like compare_prices or search_tests.
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 an explicit usage instruction: 'Use this before quoting any total to a user.' This clearly tells the agent when to invoke the tool. It does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest TestWell panels and tests for stated health goals (e.g. 'annual checkup', 'heart health', 'TRT monitoring') and/or symptoms (e.g. 'fatigue', 'hair loss'). Prefers a curated pre-built panel when one fits; otherwise assembles individual tests within a budget. Educational matching, not a diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| goals | No | Health goals, e.g. ['energy', 'thyroid'] | |
| budget | No | Budget band: low ≈ $80, medium ≈ $200, high ≈ $400 | |
| symptoms | No | Symptoms, e.g. ['always cold', 'weight gain'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is safe and non-destructive. The description adds meaningful behavior: the tool prefers a curated pre-built panel when one fits, otherwise assembles individual tests within a budget. This goes beyond the annotations and helps set 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?
Three focused sentences, with the primary purpose stated first, followed by behavioral preference and a safety/boundary note. Every sentence earns its place; there is no filler or repetition of schema details.
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 tool's moderate complexity, no required parameters, and no output schema, the description covers the key invocation details: input types, decision logic, budget constraint, and educational intent. A small gap is that it does not describe what kind of result the agent should expect, but this is not critical for selection and 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 description coverage is 100%, so the parameters are already well documented in the schema. The description reinforces the meaning of goals, symptoms, and budget with examples and context, but does not add significant new parameter semantics beyond what the schema already provides.
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 ('Suggest'), names the resource ('TestWell panels and tests'), and identifies the exact trigger inputs (health goals and symptoms). It also distinguishes its matching behavior from the sibling tools by describing the preference for pre-built panels and an educational, non-diagnostic nature.
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 clear usage context: call this when the user states goals and/or symptoms and wants test recommendations. It also adds an important boundary ('Educational matching, not a diagnosis'). It does not explicitly name alternative sibling tools like search_tests or list_panels, so it misses the opportunity to rule them out directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TestWell's public catalog of cash-pay lab tests and panels by keyword, biomarker, CPT code, or category. Returns name, slug, per-lab prices, sample, fasting, turnaround and order URL. Prices are stickers; every order adds one $6 lab processing fee (see quote_order for all-in totals).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Return Spanish names/descriptions where a translation exists (default en) | |
| type | No | Restrict to individual tests or bundled panels | |
| limit | No | Max results (default 10) | |
| query | Yes | Keyword, biomarker, CPT code or health goal, e.g. 'vitamin d', 'TSH', '80053', 'cholesterol' | |
| category | No | Catalog category, e.g. 'Thyroid', 'Heart Health' | |
| orderableOnly | No | Exclude items listed as coming soon (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds useful behavioral context: the search covers a public cash-pay catalog, prices are sticker prices, and every order incurs a $6 processing fee. This helps the agent interpret results and avoid misquoting totals.
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 sentences: scope, return fields, and caveat with a pointer to quote_order. Every sentence carries information, and the most important scoping facts are front-loaded.
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 still enumerates the key returned fields (name, slug, per-lab prices, sample, fasting, turnaround, order URL). It covers pricing caveats and routes to the appropriate sibling for all-in totals, so an agent has enough to invoke 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 description coverage is 100%, so the parameters are already documented. The description restates search dimensions already present in the query and category parameter descriptions and adds no new parameter-level semantics 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?
Description uses a specific verb ('Search') and resource ('TestWell's public catalog of cash-pay lab tests and panels'), and names the search dimensions (keyword, biomarker, CPT code, category) plus return fields. This clearly distinguishes it from siblings like quote_order and list_panels.
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 that this tool returns sticker prices and explicitly directs agents to quote_order for all-in totals, giving a concrete when-to-use-this-other-tool condition. The 'public catalog' qualifier also implies this is not for find_draw_sites, lookup_reference_range, or other specialized tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
calculate_free_testosteronecompare_pricescompare_providerconvert_unitsfind_draw_sitesget_guideget_testinterpret_resultslist_panelslookup_reference_rangequote_orderrecommend_testssearch_testsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Find public biomarker education, available blood tests, panels, and budget-aware starting points.
Search source-labeled hospital prices, CPT codes, providers, and healthcare cost estimates.
Add one secure layer between your agents and this server.
Each tool has a distinct primary purpose, but compare_prices and compare_provider have overlapping comparison themes that could lead to misselection if an agent is not careful. The descriptions provide enough context to differentiate them, but the boundary between searching for a test and getting its full detail could also cause minor confusion.
All tool names follow a clear verb_noun pattern with consistent snake_case formatting (e.g., calculate_free_testosterone, compare_prices, get_test, list_panels). The naming style is uniform and predictable across the entire set.
13 tools is a well-scoped count for a lab test service covering search, details, pricing, reference ranges, interpretation, comparisons, and educational guides. Each tool earns its place without feeling redundant or bloated.
The tool set covers the full user journey: searching and viewing tests, panels, pricing and ordering quotes, reference ranges, interpretation, unit conversion, and finding draw sites. There are no obvious dead ends or significant missing operations for the stated purpose of a consumer-facing lab test information and ordering service.
