ADHD Progress Hub

Overview Schema Source Related Servers Discussions Admin

report_guidance_health

Destructive

Record locally verified Hub guidance versions and timestamp after inspecting markers or running a doctor check, replacing the prior verification record so stale client guidance is visible.

Instructions

Record versions of Hub guidance a local client actually verified.

Call only after inspecting managed markers or running a local doctor/setup check. The Hub cannot inspect the client's checkout; it replaces the project's last verification record and timestamp with the supplied versions. Null versions mean unavailable, not verified current. Project resolution may create a local registry entry; no guidance files are edited.

Input Schema

Name	Required	Description	Default
`source`	No	Client/check attribution string, such as agent or doctor; defaults to agent. Recorded with a new verification timestamp.	agent
`project_slug`	No	Project identifier for the verified guidance; takes precedence over workspace_path and may create a registry entry.
`workspace_path`	No	Client workspace folder path for project resolution when project_slug is absent; supply a slug or path for correct attribution.
`cursor_rule_version`	No	Integer hub_guidance_version from the locally inspected Cursor rule; null means unavailable.
`session_skill_version`	No	Integer hub_skill_version from the locally inspected session skill; null means unavailable.
`agent_guidance_version`	No	Integer from the managed AGENTS.md guidance-version marker actually inspected locally; null means unavailable, not verified current.

Output Schema

Name	Required	Description
`error`	No
`guidance`	No	Existing JSON-encoded verification record, including verified_at and source.
`recorded`	No
`project_slug`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.22.0Nov 5, 2026

addedInput schema / properties / agent_guidance_version / description

Added value: +"Integer from the managed AGENTS.md guidance-version marker actually inspected locally; null means unavailable, not verified current."

addedInput schema / properties / cursor_rule_version / description

Added value: +"Integer hub_guidance_version from the locally inspected Cursor rule; null means unavailable."

addedInput schema / properties / project_slug / description

Added value: +"Project identifier for the verified guidance; takes precedence over workspace_path and may create a registry entry."

addedInput schema / properties / session_skill_version / description

Added value: +"Integer hub_skill_version from the locally inspected session skill; null means unavailable."

addedInput schema / properties / source / description

Added value: +"Client/check attribution string, such as agent or doctor; defaults to agent. Recorded with a new verification timestamp."

addedInput schema / properties / workspace_path / description

Added value: +"Client workspace folder path for project resolution when project_slug is absent; supply a slug or path for correct attribution."

addedOutput schema / description

Added value: +"Stored client verification record, or error; no client filesystem inspection."

addedOutput schema / properties

Added value: +{
+  "error": {
+    "title": "Error",
+    "type": "string"
+  },
+  "guidance": {
+    "description": "Existing JSON-encoded verification record, including verified_at and source.",
+    "title": "Guidance",
+    "type": "string"
+  },
+  "project_slug": {
+    "title": "Project Slug",
+    "type": "string"
+  },
+  "recorded": {
+    "const": true,
+    "title": "Recorded",
+    "type": "boolean"
+  }
+}

changedOutput schema / title

Previous value: -"report_guidance_healthDictOutput"New value: +"GuidanceHealthResult"

First observedv0.12.0Sep 14, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: it states that the last verification record and timestamp are replaced (consistent with destructiveHint=true), that 'null versions mean unavailable, not verified current', and that project resolution may create a local registry entry. It also bounds the blast radius with 'no guidance files are edited', which is exactly the clarification an agent needs when destructiveHint is true.

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?

Five short sentences, front-loaded with the action, then precondition, then side effects. Dense but every sentence carries information; the trailing note about project resolution could arguably be merged but is not wasteful.

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?

For a 6-parameter mutation with an output schema, the description covers the precondition, what gets overwritten, the null semantics, and the side effect on the local registry. With return values documented by the output schema, nothing an agent needs before calling is missing.

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 already 100%, so the baseline is 3, but the description adds interpretive meaning: the null-vs-verified distinction and the instruction to 'supply a slug or path for correct attribution' explain why these optional fields matter, not just what they are. It reinforces rather than repeats the schema's precedence note for project_slug.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Record versions of Hub guidance a local client actually verified.' That is unambiguous and clearly distinct from the neighboring project/thread tools. It stops short of naming any sibling or contrasting behavior, so it lands at 4 rather than 5.

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?

'Call only after inspecting managed markers or running a local doctor/setup check' gives an explicit precondition and effectively excludes premature calls. It does not name an alternative tool for the case where the precondition is unmet, but no plausible sibling performs this write-back, 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.