DokiTab Clinical MCP Server

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose the underlying billing rule (90/10 split on EML, FFS secondary tariff), but omits how results are returned, whether co-payments are rounded or capped, and whether any authorization/plan rules affect the computation.

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?

A single front-loaded sentence that packs in domain, rule, and currency without filler. It is dense but every clause (NHIA, split percentages, EML, FFS, Naira) contributes information.

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 annotations and no output schema, the definition should hint at what the calculation returns (patient total, HMO portion, per-bucket breakdown). It explains the inputs' billing treatment but not the result shape, leaving an agent unsure what to expect back.

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% and each of the three parameters is already documented with full semantics (EML tariff, non-covered out-of-pocket, secondary FFS). The description adds the governing formula but no parameter-level detail beyond the schema, 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?

States a specific verb (calculate) plus a precisely scoped resource (NHIA / State & Private HMO split-billing) and even names the core rule (10% patient vs 90% HMO on EML items, FFS pre-authorization, Naira). Nothing about the purpose is left ambiguous, and no sibling covers billing splits.

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 usage context (NHIA/HMO split-billing on EML items and FFS), but never says explicitly when to call it versus alternatives or what preconditions apply. Since the sibling set contains no comparable billing tool, the missing routing guidance is a minor rather than critical gap.

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

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

With no annotations, the description must carry the behavioral burden; it does disclose that results come back in both mg and mL, which is useful output context. It does not say whether the calculation applies maximum-dose caps, whether frequency/interval is returned, or that it is a pure non-mutating computation — meaningful gaps for a clinical dosing tool.

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?

A single front-loaded sentence that spends its words on scope and formulation coverage with no filler. The parenthetical list makes it slightly dense but nothing is wasted.

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?

Two fully documented parameters and no output schema mean the definition is usable as-is, and the description supplies the output units. It still leaves the agent unsure what exactly is returned (single dose vs daily total, frequency, max-dose handling), which matters for a dosage tool with no annotations.

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%: the drug enum lists all formulation IDs and weight_kg documents the 2–60 kg range. The description names the drug families but does not map them to the enum identifiers (e.g. amox_clav_228 vs amox_clav_457) or clarify concentration assumptions, so it adds little beyond the 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?

States a specific verb and resource (calculate weight-based paediatric drug dosage in mg and mL) and scopes it to named Nigerian EML/WHO formulations, which clearly separates it from the finance/state-SHIS siblings. The only blemish is the stated count of '7 formulations' against 6 names listed, which is a minor inaccuracy rather than a purpose ambiguity.

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 paediatric weight-based framing implies when to use it, and the sibling tools are unrelated enough that mis-selection is unlikely. However, there is no explicit when/when-not guidance, no statement about non-paediatric or out-of-range weights (beyond the schema bound), and no mention of alternatives.

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

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 discloses that the tool returns reference ranges, panic escalation rules, and DokiTab LIMS/PACS capabilities, and the verb 'evaluate' implies a read-only calculation, but it does not explicitly state that it is non-mutating or describe any side effects or permissions.

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. The closing phrase about DokiTab LIMS/PACS capabilities is broader than the threshold-evaluation purpose and slightly dilutes focus, but overall it is efficient.

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 two-parameter evaluation tool with no output schema, the description is largely complete: it names the tests covered, states the evaluation purpose, and explains the kinds of results returned. It could be stronger by clarifying that the operation is a pure calculation and by describing the output structure, but nothing essential 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 description coverage is 100%, so the schema already documents both parameters and the enum values. The description adds a mapping from enum tokens to clinical test names such as Serum Potassium K+ and Hemoglobin Hb, but it does not add unit semantics or per-test interpretation 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?

States a specific verb and resource: evaluate Nigerian MLSCN/LOINC laboratory critical panic thresholds. It also names the covered tests and the return categories, so an agent can tell exactly what this tool does and that it is unrelated to sibling tools like calculate_nhia_copay or lookup_nigeria_state_shis.

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 is implied by the input schema: provide a test_code and measured_value to evaluate a panic threshold. However, the description gives no explicit when-to-use or when-not-to-use guidance, no alternatives, and no stated prerequisites.

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

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

With no annotations, the description does carry some behavioral context: it is a read-style fetch of public content returning token-efficient Markdown. However, it does not disclose error behavior, truncation/pagination, rate limits, or authentication expectations beyond 'public'.

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?

A single front-loaded sentence that clearly names the action, the content scope, and the output format. There is no filler or redundant text.

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 one-parameter fetch tool with full schema coverage, the description is mostly complete: it establishes the public-page scope and Markdown return format. Minor gaps remain around error cases and large-page behavior, but no output schema is present and the key call semantics are 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?

The single path parameter is fully documented in the schema, including canonical URL path examples, so the schema already handles parameter semantics. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline 3 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?

States a specific verb, resource, and return format: fetching a clean Markdown representation of public DokiTab pages. It enumerates page types (hub, calculator, blog guide), making the tool's role distinct from calculation siblings.

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 scope 'any public DokiTab page' implies when this tool is appropriate, but there is no explicit when-to-use/when-not-to-use guidance or direct comparison to sibling calculator and lookup tools. Selection is therefore inferable rather than clearly guided.

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

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

With no annotations, the description carries the burden and does add real context: the AI/telemedicine plan is a flat ₦30,000/month and the Free Hospital Suite is ₦0, and the comparison baseline is legacy per-seat/per-bed EMRs. However, it never states what the result looks like (savings figure, breakdown, assumptions like currency/period) or that the tool is read-only/non-mutating, which matters given zero annotation coverage.

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?

A single front-loaded sentence that leads with the verb and keeps the price anchors in parentheses. Slightly dense with promotional framing ('Free Hospital Suite'), but every clause carries selection-relevant information.

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 two-parameter, entirely optional-parameter tool with no output schema and no annotations, the description should say what is returned (TCO breakdown vs single savings number) and any assumptions. It conveys the pricing inputs but leaves the output and assumptions undefined.

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 are already documented, including the ₦30,000/month flat-fee implication of include_ai_telemedicine. The description largely restates those figures rather than adding new semantics (e.g., how staff_seats feeds the TCO math), so the 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?

States two specific verbs (retrieve pricing, calculate 3-year TCO) on a named resource (DokiTab Naira subscription tiers) and contrasts them with per-seat/per-bed legacy EMRs. This is clearly distinguishable from sibling calculators like calculate_nhia_copay or calculate_pediatric_dosage.

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 scope implies the use case (facility cost comparison over a 3-year horizon), but there is no explicit statement of when to pick this over the other cost/calc siblings, and no exclusions or prerequisites. The agent must infer selection from the tool name and description alone.

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

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

No annotations, so the description carries the full burden — and 'look up' plus the enumerated return fields do establish this as a read-only reference retrieval with no side effects. It describes the shape of the payload (agency, regulator, medical cities, EMR requirements) rather than just naming the tool, though it says nothing about behavior on an unrecognized state (error vs. empty result).

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 sentence, front-loaded with the verb and scope, with the concrete deliverables packed into a parenthetical rather than spread across filler sentences. Every clause contributes information.

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?

There is no output schema, so the description must — and does — enumerate the returned fields, which is the main completeness risk here. Minor gap: no mention of output format or behavior for invalid/unknown state values, which matters slightly more given the free-text string parameter.

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 schema already gives slug/name examples, so the description adds little param-level meaning beyond the '36 states + FCT' framing that implicitly defines the valid input domain. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Specific verb+resource ('Look up ... Nigeria's 36 states + FCT') scoped to a bounded domain, and it enumerates exactly what comes back (SHIS agency, regulatory authority, medical cities, EMR compliance). An agent knows precisely what this returns without opening the schema, and the sibling tools (calculators, page markdown) are clearly unrelated so no differentiation burden exists.

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 triggering condition is clear: any time a Nigerian state's health-insurance context is needed, pass the state. No exclusions or alternative routing are stated, but with unrelated siblings and a single required param there is nothing to disambiguate against.

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