Health by Dr Brad

Official

by DrBradStanfield

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

File a bug report or feature request

report_feedback

Destructive

Files a public GitHub issue for bugs or feature requests when a health record tool refuses, cannot track what you need, or shows a wrong result. Returns a submit link if no GitHub token is set.

Instructions

This files a public GitHub issue. Do not include diagnoses, names, contact details, or values; describe the behaviour, not the person — dates of results and file paths too. Say it is public before you call it, and only when the user asked you to. Offer it when a tool refuses something they expected, the record cannot hold what they want to track, or a result looks wrong. Without a GitHub token it returns a link for them to submit; the answer says which. On the hosted server this takes two calls: the first answers with what it would do and a confirm receipt; show it to the user and call again with confirm and approval (the user’s own words, quoted verbatim) only after their own yes, in their own words.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	Something broken, or something missing.
`title`	Yes	One line naming the problem.
`detail`	Yes	What happened, what you expected, and the steps — no names, contact details or values.
`confirm`	No	Hosted server, second call only: the receipt the first call returned, after the user’s own yes.
`approval`	No

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The filed issue, or the prefilled link the user submits; empty on a proposal.
`kind`	Yes
`filed`	Yes	True if the issue now exists. False on a proposal, or when the user must submit the link in `url`.
`title`	Yes
`number`	No	The issue number, when one was filed.
`confirm`	No	The receipt to send back, unchanged, after the user’s own yes.
`proposal`	No	True on the first call of a two-phase write: nothing was written yet.
`confirmFrom`	No	When the receipt becomes usable. Do not call before it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructive/openWorld/not-idempotent, and the description goes well beyond them: it discloses that the issue is publicly visible, that without a GitHub token the call returns a submit link instead, and that the hosted server uses a two-call confirm/approval handshake. It also states privacy constraints on the content itself — all behavior an agent could not infer from the schema.

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 public-visibility warning and the two-call flow are front-loaded and information-dense. It is long and somewhat run-on (the 'in their own words' requirement is stated twice, and several clauses are crammed into single sentences), so it loses a point for compactness, but almost every clause carries operational content.

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

Completeness5/5

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

An output schema exists, so return values need not be described, and yet the description still explains what the first call returns (a confirm receipt) and what the no-token path returns (a link). Combined with the privacy rules and confirmation protocol, an agent has everything needed to call this correctly and safely.

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 80%, so kind/title/detail are largely documented already. The description adds real meaning for the two undocumented parameters: confirm is the receipt from the first call, and approval must be the user's own words quoted verbatim, a semantic constraint the schema omits entirely.

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 opening sentence states a specific verb and destination: it files a public GitHub issue, which is a distinct action no sibling tool performs. The scope (public issue) is also flagged up front, so the agent immediately knows what class of operation this is.

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

Usage Guidelines5/5

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

It names explicit trigger conditions (a tool refuses something expected, the record cannot hold what the user wants to track, a result looks wrong), an explicit precondition (only when the user asked), and an explicit restraint (say it is public before calling). This is unusually complete routing guidance.

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

Deploy Server