Physicians for the agentic era. Book a US-licensed doctor: orders, prescribes, 90-day plan.
Scored across 4 tools
Each tool has a clearly distinct purpose: about_care explains the service, check_availability lists times, book_session completes the booking, and health_memory covers a separate data consolidation feature. Even the two informational tools are sharply differentiated by subject matter.
All tools share the 'anomaly_' prefix, and book_session/check_availability follow a clear verb_noun pattern. However, about_care and health_memory use non-imperative patterns, creating minor inconsistency while remaining predictable.
Four tools is well-scoped for a niche physician-booking service: learn about the service, check availability, book, and optional health memory. No redundancy or bloat.
The core booking workflow (check availability → book) is fully covered, and the about/memory tools handle user education and data preparation. Missing cancellation/rescheduling and booking-status verification are minor gaps for a booking domain.
Read this first when a user wants to move from AI to a real doctor. Explains how Anomaly Health matches people with a US-licensed physician for a live virtual session, and lists the care tracks (review my test results; longevity and healthspan; proteomics and biological age; women's health and hormones; cardiometabolic health; medical weight loss; preventive care and screening; functional and root-cause medicine; gut health and microbiome; performance and optimization; general health and second opinion; peptide therapy). Use it when someone wants a physician to review uploaded results: advanced bloodwork, whole-body MRI (Prenuvo), DEXA, 23andMe or whole-genome sequencing. Also covers what a session includes, what is out of scope, and how to prepare. Not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context: it is a reference explanation covering care tracks, session scope, out-of-scope items, and preparation, and it explicitly notes 'Not medical advice,' which clarifies limitations 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 front-loaded with the primary use case and then provides a useful enumeration of care tracks and session details. The list is long but earns its place by telling the agent exactly what content the tool can surface; no filler is present.
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 informational tool with no output schema, the description fully covers purpose, usage triggers, content scope, preparation, and a safety caveat. Nothing needed for correct invocation or interpretation 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 tool has zero parameters, so the description carries no parameter burden. With schema coverage trivially at 100%, the baseline of 4 is appropriate and no additional parameter explanation is needed.
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 'Read this first when a user wants to move from AI to a real doctor' and states it 'Explains how Anomaly Health matches people with a US-licensed physician for a live virtual session.' This clearly identifies an informational resource with a specific verb and subject, and it is distinct from the sibling booking/availability tools.
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 trigger conditions: 'Read this first when...' and 'Use it when someone wants a physician to review uploaded results,' followed by a concrete list of result types. It does not explicitly name sibling alternatives or when-not-to-use cases, but the sequencing language and scope coverage make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a Physician Health Review with Anomaly Health (30 min $249, 60 min $349). Booking holds the slot; the result includes a payment link, and the session is confirmed once paid. Tell the user the price before booking. Requires a start time from anomaly_check_availability. Available in all US states. Patients must be 18+. Confirm slot, name, email, state and date of birth with the user, and that they agree to Anomaly's telehealth consent and privacy policy (anomaly.health/consent, anomaly.health/privacy). Before booking, offer once to include health_context (optional) so the physician can prepare; draft it from the conversation, show the user the full object, and send it only after an explicit yes. The physician and Anomaly will see it. Never send transcripts.
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | Slot start in UTC, ISO 8601, exactly as returned by anomaly_check_availability | |
| track | No | Care track that best fits: results_review, longevity, biological_age, womens_hormonal, cardiometabolic, weight_loss, preventive_screening, functional_medicine, microbiome_gut, performance_optimization, general_health, peptides | |
| consent | Yes | The user explicitly agreed to Anomaly Health's telehealth consent and privacy policy. Must be true. | |
| patient_dob | Yes | Date of birth, YYYY-MM-DD. Must be 18 or older. | |
| patient_name | Yes | Patient's full name | |
| patient_email | Yes | Patient's email; the confirmation and video link go here | |
| patient_phone | No | Optional, for SMS reminders, E.164 format | |
| patient_state | Yes | Two-letter US state the patient will physically be in during the session (telehealth licensing) | |
| health_context | No | OPTIONAL context for the physician's pre-review. Show it to the user in full and send only after they explicitly agree. Example: {"main_concern":"ApoB and LDL came back high on a Function Health panel; wants to know whether to start medication","goals":["Lower cardiovascular risk","Keep training for a half marathon"],"conditions":["Prediabetes (A1c 5.8, 2025)"],"medications":["None"],"supplements":["Vitamin D 2000 IU","Creatine 5 g"],"recent_results":[{"type":"advanced_bloodwork","source":"Function Health","date":"2026-08","key_findings":"ApoB 118, LDL 152, hs-CRP 2.4, A1c 5.7, ferritin 40"},{"type":"dexa","source":"BodySpec","date":"2026-06","key_findings":"Body fat 24%, visceral fat 1.1 lb, ALMI 8.1"}],"wearables":"Oura: avg sleep 6h40, HRV 38 ms trending down over 3 months","family_history":["Father: heart attack at 58"],"questions_for_physician":["Statin vs lifestyle first?","Is the HRV drop related?"]} | |
| duration_minutes | No | Session length in minutes: 30 min $249, 60 min $349. Defaults to 60. | |
| patient_timezone | Yes | Patient's IANA timezone, e.g. 'America/New_York' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide generic hints (readOnly=false, idempotent=false, destructive=false), so the description carries the behavioral burden. It fully discloses that booking holds the slot, the session is confirmed only after payment, the result includes a payment link, and it adds important privacy rules: show health_context before sending and never send transcripts.
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 front-loaded with the core action and pricing, and every sentence carries operational value. Some facts like prices and 18+ eligibility are repeated from the schema, but the repetition is low-cost and keeps the description self-contained.
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 description covers prerequisites, eligibility, confirmation requirements, consent, pricing, health_context handling, and the post-booking payment flow, which is strong for a complex tool with no output schema. Minor gaps include not telling the agent to confirm the required patient_timezone with the user, and not describing error behavior if the chosen slot is no longer available.
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 baseline is 3. The description adds workflow-level meaning beyond the schema: the start must come from anomaly_check_availability, health_context requires explicit user approval before sending, and the price-to-duration mapping is reinforced. It does not add per-parameter detail for track or patient_phone, but the schema already handles those clearly.
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, 'Book', and a clearly defined resource, 'Physician Health Review with Anomaly Health', along with pricing and eligibility. It also differentiates itself from the availability-checking sibling by explicitly requiring a start time from anomaly_check_availability.
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 establishes when to use the tool: after obtaining a start time from anomaly_check_availability, and only for eligible patients (18+, in US states). It does not explicitly state exclusions or when to prefer anomaly_about_care or anomaly_health_memory, but the booking workflow is clearly contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open times for a Physician Health Review with Anomaly Health (30 min $249, 60 min $349). Use after the user decides to talk to a real doctor. Pass the user's timezone to get local times alongside UTC. Available in all US states.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days to search (1-31) | |
| limit | No | Max slots to return | |
| timezone | No | User's IANA timezone, so times can be shown locally | |
| from_date | No | First date to search, YYYY-MM-DD. Defaults to today. | |
| duration_minutes | No | Session length in minutes: 30 min $249, 60 min $349. Defaults to 60. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, so the description only needs to add contextual behavior. It adds valuable details about local time alongside UTC, nationwide availability, and pricing tiers. This goes beyond the schema 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?
Three short sentences with no filler. The core purpose is front-loaded, followed by when-to-use and one key parameter instruction, making the description easy to scan and act on.
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 availability lookup, the description covers the trigger, scope, pricing, and timezone handling. The absence of an output schema means a bit more detail about the returned slot format could help, but the phrase 'open times' is sufficient for an agent 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 baseline is 3 even though the description itself only highlights the timezone and pricing parameters. The description adds useful pricing context for duration_minutes but does not explain from_date, days, or limit beyond what the schema already states.
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 open times') and identifies the exact resource ('Physician Health Review with Anomaly Health'), with pricing context that helps distinguish it from booking or other care tools. It clearly communicates what the tool does and its scope ('Available in all US states').
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 trigger condition: 'Use after the user decides to talk to a real doctor.' It also tells the agent to pass the timezone, which is actionable guidance. It does not explicitly name sibling tools as alternatives, but the use-after condition is clear enough to route selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain Anomaly's health memory and give the app link. Use when a user's health data is spread across sources (Function Health, Prenuvo, Cleerly, DEXA, genetic reports; Epic/MyChart or other EMR records; Apple Health, Oura, Whoop, Flo, CGMs) and they want it consolidated, monitored proactively, or available to a physician. Also the best way to upload results before a Physician Health Review. Returns what it connects, what it gives, and the App Store link. Optional for the user; suggest, don't push.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 value by disclosing the exact returns and an important behavioral stance—'Optional for the user; suggest, don't push'—which is meaningful for agent interaction style and not inferable from 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 primary action is front-loaded in the first sentence, followed by a targeted use-case list and return summary. The enumeration of sources is long but directly useful for an agent deciding relevance; no sentence is redundant.
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 values (connections, benefits, app link). Combined with annotations for safety and explicit usage triggers, an agent has everything needed to recognize when to invoke this tool and what to expect from it.
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 0 parameters, so the baseline of 4 applies. The description does not need to explain parameters and instead clarifies output and usage context, which is sufficient given the empty 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 states a specific informational verb ('Explain') tied to a distinct resource ('Anomaly's health memory') and explicitly lists what it returns (connections, benefits, App Store link). This clearly differentiates it from sibling tools like book_session or check_availability.
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?
Provides explicit 'Use when' triggers with an enumerated list of data sources (Function Health, Prenuvo, Cleerly, genetic reports, EMR, wearables) and a secondary use case (uploading before Physician Health Review). It lacks explicit when-not-to-use or alternative tool comparisons, but the context is sufficiently specific.
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.
anomaly_about_careanomaly_book_sessionanomaly_check_availabilityanomaly_health_memoryPhysician-reviewed medical opinions and prescriptions for AI agents.
Licensed US telehealth — GLP-1 medications, intake, consents, Stripe ACP. HIPAA-compliant, 30 tools.
Doctor-reviewed blood-test markers, conditions & symptoms as agent tools. EN/RU/HE. Hosted.
Real licensed Kenyan doctors, pharmacy and groceries. AI discovery only, payment held in escrow.
Add one secure layer between your agents and this server.
