repowise

get_health

Retrieve stored code-health scores and findings, rank files or findings to fix first, and filter by biomarkers, refactoring, coverage, or trends. Does not recompute health; run repowise update first.

Instructions

Code-health scores and findings from stored analysis.

No ``targets``: a dashboard led by ``fix_first``, what to fix first;
targets rank files and findings.
Never recomputes health: commit, then run ``repowise update``.
Every block and accepted value: docs/agent/MCP_TOOLS.md.

Args:
    targets: file paths or ``module:<name>``; misses land in ``unresolved``.
    include: ``biomarkers``|``refactoring``|``trend``|``coverage``|
        ``accuracy``|``signals``|``churn_complexity``|``doc_drift``|
        ``semantics``, or a dimension incl. ``advisory``; ``performance`` and
        ``refactoring`` add queues.
    only: keys to keep; identity, totals, recovery survive.
        ``biomarkers``/``accuracy``/``refactoring`` alias their block key;
        ``performance``/``defect``/``maintainability``/``advisory``
        do not: they filter rows into ``unknown_only_keys``.
    repo: usually omitted.
    limit: max rows per ranked list, ``0`` for none.
    cursor: zero-based offset into a ranked list.
    fix_id/finding_id/plan_id: stable ``id`` of an item, finding or plan.
    opportunity_id: ``perf...``/``refop...``: the unit, its steps or
        plan, evidence paged by ``only=["*_evidence"]``.
    refactoring_view: ``diversified`` (default)|``canonical``|
        ``file_spread``; _type/_confidence/_effort/_scope filter.
    performance_view/_context/_boundary/_confidence/_actionability/_sort:
        queue filters.
    scope / counts: default ``all``/``everything``. ``production`` drops
        test files; ``code_shape`` drops git-derived score and findings.

Input Schema

TableJSON Schema

Name	Required	Default
`only`	No
`repo`	No
`limit`	No
`scope`	No	all
`counts`	No	everything
`cursor`	No
`fix_id`	No
`include`	No
`plan_id`	No
`targets`	No
`finding_id`	No
`opportunity_id`	No
`performance_sort`	No
`performance_view`	No
`refactoring_type`	No
`refactoring_view`	No	diversified
`refactoring_scope`	No
`refactoring_effort`	No
`performance_context`	No
`performance_boundary`	No
`performance_confidence`	No
`refactoring_confidence`	No
`performance_actionability`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.55.0Oct 5, 2026

addedInput schema / properties / fix_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Fix Id"
+}

addedInput schema / properties / refactoring_scope

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Refactoring Scope"
+}

Changed1 schema field changedv0.53.0Sep 24, 2026

addedInput schema / properties / performance_actionability

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance Actionability"
+}

Changed2 schema fields changedv0.50.0Sep 11, 2026

addedInput schema / properties / counts

Added value: +{
+  "default": "everything",
+  "title": "Counts",
+  "type": "string"
+}

addedInput schema / properties / scope

Added value: +{
+  "default": "all",
+  "title": "Scope",
+  "type": "string"
+}

Changed13 schema fields changedv0.48.0Sep 3, 2026

addedInput schema / properties / cursor

Added value: +{
+  "default": 0,
+  "title": "Cursor",
+  "type": "integer"
+}

addedInput schema / properties / finding_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Finding Id"
+}

addedInput schema / properties / opportunity_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Opportunity Id"
+}

addedInput schema / properties / performance_boundary

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance Boundary"
+}

addedInput schema / properties / performance_confidence

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance Confidence"
+}

addedInput schema / properties / performance_context

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance Context"
+}

addedInput schema / properties / performance_sort

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance Sort"
+}

addedInput schema / properties / performance_view

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Performance View"
+}

addedInput schema / properties / plan_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Plan Id"
+}

addedInput schema / properties / refactoring_confidence

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Refactoring Confidence"
+}

addedInput schema / properties / refactoring_effort

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Refactoring Effort"
+}

addedInput schema / properties / refactoring_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Refactoring Type"
+}

changedInput schema / properties / refactoring_view / default
```
Previous value: -"canonical"New value: +"diversified"
```

Changed1 schema field changedv0.45.0Aug 22, 2026

addedInput schema / properties / refactoring_view

Added value: +{
+  "default": "canonical",
+  "title": "Refactoring View",
+  "type": "string"
+}

Changed1 schema field changedv0.39.0Aug 5, 2026

addedInput schema / properties / only

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Only"
+}

First observedv0.1.0Jul 12, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations the description carries the full burden and does add real behavior: it never recomputes health, misses land in `unresolved`, and identity/totals/recovery survive `only` filtering. Auth/rate-limit/return-shape details are absent (return shape is covered by the output schema), keeping this below 5.

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?

Purpose and the key 'never recomputes' warning are front-loaded before the arg list, and the arg-style layout is compact for 23 params. It is dense and cryptic in places, but every block largely earns its place given the parameter count.

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?

For a 23-param tool with an output schema, the description supplies the usage modes, the recompute caveat, and most parameter semantics. Remaining gaps are the cryptic enum-like filter values for the performance/refactoring queues, but nothing essential to calling it correctly 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 0% across 23 params, so the description must compensate and largely does, documenting targets/include/only/limit/cursor/id params and the aliasing behavior of `only` keys. Some queue-filter params (performance_*/refactoring_*) are covered only by a terse lumped line with no acceptable values, so it falls short of 5.

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?

States a specific verb+resource ('Code-health scores and findings from stored analysis') and clarifies it is read-only against stored data. It does not explicitly differentiate from siblings like get_risk or get_overview, 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?

Gives clear context for two modes: without `targets` a fix_first dashboard, with `targets` ranked files/findings, plus the critical 'commit then run repowise update' prerequisite. It does not name alternatives (e.g. get_risk/get_dead_code) to route between, so 4 is appropriate.

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

Deploy Server