repowise

get_health

Retrieve stored code-health scores, findings, and ranked targets to identify refactoring, performance, and coverage issues without recomputing analysis.

Instructions

Code-health scores and findings from stored analysis.

No ``targets`` returns a dashboard; 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>``; unmatched ones land in
        ``unresolved``.
    include: ``biomarkers``|``refactoring``|``trend``|``coverage``|
        ``accuracy``|``signals``|``churn_complexity``|``doc_drift``,
        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.
    finding_id/plan_id: stable ``id`` from a 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 filter.
    performance_view/_context/_boundary/_confidence/_sort: queue
        projection and filters; the facets list them.
    scope / counts: default ``all``/``everything``. ``production`` drops
        test files; ``code_shape`` drops the git-derived half of the
        score and its findings.

Input Schema

TableJSON Schema

Name	Required	Default
`only`	No
`repo`	No
`limit`	No
`scope`	No	all
`counts`	No	everything
`cursor`	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_effort`	No
`performance_context`	No
`performance_boundary`	No
`performance_confidence`	No
`refactoring_confidence`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it invests that space in real behavior: stored analysis only, never recomputes, unmatched targets landing in `unresolved`, `only` aliasing/filtering into `unknown_only_keys`, and scope effects like `production` dropping test files or `code_shape` dropping the git-derived half. No contradiction with annotations exists, and the read-only nature is clearly implied.

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 long, but proportionately so for a 20-parameter tool. It front-loads the core behavior before the argument list, uses compact grouped notation for related parameters, and points to docs for exhaustive accepted values. Some phrases like 'identity, totals, recovery survive' are dense enough to require unpacking, but there is no filler.

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 tool with 20 parameters, no annotations, and no enums in the schema, the description documents every parameter group, special defaults, pagination semantics, and the no-recompute read pattern. The output schema covers return-value shape, so not describing it here is appropriate; the docs pointer covers exhaustive enum-style values without bloating the definition.

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

Parameters5/5

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

Schema description coverage is 0%, so the Args block is the only meaning-bearing documentation for all 20 parameters. It explains target matching, include values, the tricky `only` alias/filter behavior, pagination via limit/cursor, stable IDs, and groups the performance/refactoring filters compactly. This is far more useful than the raw schema.

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 lead sentence names a precise resource ('code-health scores and findings') and its source ('stored analysis'), and the very next sentence clarifies the two invocation modes: no targets gives a dashboard, targets rank files and findings. The code-health focus is distinct enough from siblings like get_risk and get_overview, and the 'stored analysis' framing separates it from computation/recompute flows.

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?

It gives clear context for when this tool applies: no targets means dashboard, targets means ranked files/findings, and 'Never recomputes health' explicitly tells the agent when not to expect recomputation and directs it to `repowise update`. It does not explicitly compare against sibling MCP tools such as get_overview or get_risk, so it misses the full 'alternatives' criterion.

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

Deploy Server