ImOnFHIR

Evidence for a rule or a requirement

explain_finding

Read-onlyIdempotent

The evidence behind a semantic validator rule, not an explanation of it. Give rule_id (a rule id such as PAS-SEM-PROV-001) and get the rule's id, version, title, description, source, category and default severity as the validator states them, plus, only when the rule's explanation entry declares anchors that all resolve, the HL7 statements for them: package, version, key, conformance word, HL7's statement text verbatim (its markdown) and the sha256 of that text. It abstains, with the reason, when no anchor is committed or one does not resolve. 0 of 17 rule explanations have committed anchors; a rule id abstains until its anchors are committed. Or give requirement ({packageId, version, key}) and get that one HL7 statement the same way. An unknown package, version or key is an error, and so is a package version that has a catalog but no committed statement text. Statement text is committed for hl7.fhir.us.davinci-pas@2.2.1; a package version that has a catalog but no committed text is an error. It also returns an instruction block telling your assistant how to use the evidence. It calls nothing outside this site. Prose your assistant writes around the passages is not controlled by ImOnFHIR.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "explain_finding"
  }
}

Input Schema

Name	Required	Description	Default
`rule_id`	No	A semantic rule id, e.g. PAS-SEM-PROV-001. Give this or requirement, not both.
`requirement`	No	One HL7 statement: its package id, version and statement key, e.g. hl7.fhir.us.davinci-pas, 2.2.1, ainfo-3. Give this or rule_id, not both.

Output Schema

Name	Required	Description	Default
`mode`	Yes
`rule`	No
`notice`	Yes
`abstain`	No
`outcome`	Yes
`passages`	Yes
`instruction_block`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-open-world behavior, yet the description adds substantial context beyond them: abstention with a stated reason, error conditions for unknown package/version/key, the specific committed package version, a returned instruction block, and the guarantee that it calls nothing outside the site. The caveat that surrounding prose is not controlled by ImOnFHIR is a meaningful behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the text repeats itself: the 'catalog but no committed statement text is an error' rule appears twice, and the abstention point about anchors is stated in two adjacent sentences ('0 of 17 rule explanations have committed anchors; a rule id abstains until its anchors are committed'). Dense useful content, but it could be tightened by several sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not enumerate return fields, yet it does so anyway and still covers error cases, abstention, and scope. The only information an agent might still want is guidance against the named sibling tools, which is outside this tool's core contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: a concrete rule_id example (PAS-SEM-PROV-001), a concrete requirement triple (packageId/version/key with 'ainfo-3'), mutual exclusivity, and the fact that unknown values are errors. That exceeds what the schema alone conveys.

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?

States a specific verb and resource ('the evidence behind a semantic validator rule') and immediately disambiguates it from a sibling concept ('not an explanation of it'). The two mutually exclusive input modes (rule_id vs requirement) are named up front so an agent knows exactly what the tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit selection rules for its own inputs ('Give this or rule_id, not both') and clear abstention semantics ('It abstains, with the reason, when no anchor is committed or one does not resolve'). It does not explicitly route against the other listed siblings (compare_igs, validate_bundle, search_digest), but those appear to serve different tasks, so the gap is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ImOnFHIR tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?