Skip to main content
Glama
Sign In
Constat — 483 Risk Radar

Constat — 483 Risk Radar

by thehealthai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

evidence_cohort_stats

Calculate reporting rates of evidence across AI/ML audited devices, showing counts over denominators and predicate age when data coverage exceeds 60%.

Instructions

Reporting-rate stats across the parsed AI/ML corpus (optionally by panel). Each rate is a presence figure with its denominator — 'reported in X of Y audited devices' — never a pooled performance value. Excludes not-yet-parsed devices from every denominator and discloses the parse queue separately. Predicate age (median years between a clearance and its cited predicates) is included when decision-date coverage clears a 60% floor, and withheld otherwise.

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": "evidence_cohort_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
panelNoAdvisory panel, e.g. Radiology; omit for all

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description bears full burden for behavioral disclosure. It explains that rates are reported as 'X of Y audited devices', excludes not-yet-parsed devices, discloses the parse queue separately, and details the condition for including predicate age (60% decision-date coverage). This provides clear insight into how the tool behaves, though auth and error handling are omitted.

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

Conciseness4/5

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

The description is three sentences, each serving a purpose: stating the main function and optionality, clarifying the rate format, and explaining exclusions and predicate age condition. It is front-loaded and efficient, though the third sentence could be slightly more streamlined.

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?

Given the tool has one optional parameter, no output schema, and no annotations, the description covers the essential aspects: what stats are provided, their format, exclusions, and a conditional element. It does not detail return structure or error cases, but for a stats tool this level of completeness is adequate.

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

Parameters3/5

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

The sole parameter 'panel' is described in the input schema as 'Advisory panel, e.g. Radiology; omit for all', and the description reinforces that it's optional and filters results. Since schema description coverage is 100%, the description adds minimal extra meaning beyond clarifying the optionality, but does not introduce new semantics.

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?

The description clearly states the tool provides reporting-rate stats across the parsed AI/ML corpus, optionally filtered by panel. It emphasizes that rates are presence figures with denominators, not pooled performance, which distinguishes it from other stats tools. The mention of predicate age conditional on coverage adds further specificity.

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

Usage Guidelines3/5

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

The description implies the tool is for getting reporting rates on parsed devices, but it does not explicitly say when to use this vs. alternatives like cohort_postmarket_stats. No when-not-to-use guidance or comparisons to siblings are provided, leaving the agent to infer usage from the context.

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

Deploy Server

Other Tools