Vet reviewed pet lab interpretation tool for dogs and cats. Furva reads blood work and urinalysis and explains every result in easy to understand terms, built on a biomarker reference set reviewed by a licensed veterinarian. It explains what markers like BUN and creatinine measure, tracks results over time, suggests when labs should be rechecked, and helps owners prepare questions for their vet. Education only: never diagnoses or prescribes. Connect with OAuth 2.1 sign-in or an fmcp_ API key.
Scored across 3 tools
The three tools target related but distinct tasks: explaining a single biomarker, interpreting a full report, and advising on retest timing. There is some overlap since interpret_lab_report also explains what each biomarker measures, which could make get_biomarker_info feel partially redundant, but the descriptions clarify when each applies.
All three names follow a clean verb_noun snake_case pattern (get_, interpret_, suggest_), which is predictable and unambiguous. No mixing of conventions.
Three tools is on the lean side but each earns its place in a narrow, educational lab-interpretation domain. It is slightly minimal rather than bloated, which suits the focused scope.
The set covers the core loop: understand a biomarker, interpret a report, and plan retesting. A trend/history view across reports is absent, but that is a minor gap for an intentionally educational tool and agents can work around it.
Explains what a lab biomarker measures, why it matters, and its typical reference context for dogs and cats. Educational only.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | Optional. Limits the reference context to one species. | |
| biomarker | Yes | A biomarker code (CREA) or name (Creatinine). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the output is educational and species-scoped rather than diagnostic, but says nothing about whether reference values are static vs. dynamic, pagination, or the shape of the returned explanation.
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 tight sentences with the core action front-loaded and the scope-limiting caveat ('Educational only') closing it. No 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?
With no output schema, the description does explain what the agent can expect back (measurement meaning, importance, reference context). It is nearly complete for a simple read-only lookup tool, missing only return-format detail.
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 parameters (biomarker code/name, optional species) are already documented in the schema. The description adds only that reference context is species-specific for dogs and cats, which is marginal over the schema's enum.
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?
States a specific verb (explains) and resource (lab biomarker), and enumerates what the explanation covers: what it measures, why it matters, and reference context. 'Educational only' partially separates it from interpret_lab_report, but it never names the siblings explicitly.
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 phrase 'Educational only' implies usage (reference/lookup, not diagnosis), which is useful context. However, it never states when to choose this over interpret_lab_report or suggest_retest_timing, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains veterinary lab results for a dog or cat in easy to understand language. Flags each biomarker as Normal, High or Low against the reference range, explains what it measures, and suggests 2-3 questions to ask the vet. Educational only: never diagnoses and never recommends treatment. Provide either results or lab_upload_id (Furva users only).
| Name | Required | Description | Default |
|---|---|---|---|
| results | No | Lab values to interpret. | |
| lab_upload_id | No | A Furva lab upload id. Resolved server-side, and only for the Furva account that matches the API key owner. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the output shape (flagging Normal/High/Low, explaining each biomarker, suggesting questions) and sets a firm educational boundary (never diagnoses or recommends treatment). It stops short of stating read-only/no-side-effect behavior or mentioning the 100-item input cap.
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 tight sentences: purpose first, then output behavior and educational limits, then input constraints. Every sentence adds 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 tool with no annotations and no output schema, the description covers purpose, output behavior, educational boundaries, and input options. It is nearly complete, though it omits the input cap and does not explicitly state that the operation has no side effects.
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 schema already documents both parameters thoroughly, establishing a baseline of 3. The description adds meaningful selection semantics by saying to provide either `results` or `lab_upload_id` and that the upload ID is Furva-only, which is not clearly stated in the schema itself.
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 and resource: it explains veterinary lab results for dogs and cats, flags biomarkers, and suggests vet questions. This is clearly distinct from a biomarker lookup or retest-timing tool, though it does not explicitly name the sibling tools to reinforce the distinction.
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 gives one clear usage condition: provide either `results` or `lab_upload_id`, with the latter restricted to Furva users. However, it does not explain when to use this tool versus `get_biomarker_info` or `suggest_retest_timing`, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given biomarker statuses, says which results are worth raising with the vet about repeat testing and a general timeframe band. Always framed as a conversation to have with the vet, never an instruction.
| Name | Required | Description | Default |
|---|---|---|---|
| biomarkers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds one genuinely useful trait — output is advisory and 'never an instruction' — but says nothing about whether the call is read-only, deterministic, or subject to limits, so it does not fully cover a tool with zero annotation support.
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, zero padding. The functional statement comes first and the advisory framing second, so the most important information is front-loaded and the caveat clearly 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?
With no output schema, the description must convey the shape of the result, and it does: which results to raise plus a general timeframe band. Combined with the advisory framing, this is nearly sufficient, with only minor gaps around input format expectations.
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 0%, so the description should compensate for the single nested array parameter. It confirms the input is 'biomarker statuses', which partially aligns with the {biomarker_code, status} items, but adds no format detail, accepted code values, or note about the 100-item cap.
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 gives a concrete verb and resource: it takes biomarker statuses and returns which results warrant discussion of repeat testing plus a timeframe band. This is clearly distinct from get_biomarker_info (lookup) and interpret_lab_report (interpretation), though it never names those siblings to sharpen the boundary.
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?
Usage context is implied by the framing ('a conversation to have with the vet'), which tells the agent the output is advisory. However, there is no explicit when-to-use guidance relative to interpret_lab_report or get_biomarker_info, and no stated prerequisites or exclusions.
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.
get_biomarker_infointerpret_lab_reportsuggest_retest_timingYour labs, wearables, DNA and notes as one health record your AI agent can read (OAuth 2.1).
Doctor-reviewed blood-test markers, conditions & symptoms as agent tools. EN/RU/HE. Hosted.
Explains lab results for diabetes, kidney, lupus and cancer care, citing guidelines. Free sample.
Find public biomarker education, available blood tests, panels, and budget-aware starting points.
Add one secure layer between your agents and this server.
