repowise

get_context

Read-only

Retrieve relationships, signatures, hotspots, and decision history for files, modules, or symbols so you can triage code without reading full source. Batch targets and pick includes in one call.

Instructions

Triage card for files / modules / symbols — relationships, not source bytes.

Returns summary, signatures with lines, hotspot, fix_history and
decision titles; either risk cue means get_risk. Batch targets in one
call. Whole file, body-elided and line-verified: include=["skeleton"]
in ONE call, or Read it; do not call get_symbol per signature. Rename:
include=["references"] is the whole edit set when ``complete``. Which
files in a directory lack tests: include=["files"] on it.

Args:
    targets: paths, "path::Symbol", "component:<name>",
        "change:<id>" (pr-123 or a sha), "package:<name>".
    include: callers | callees | references | skeleton | skeleton+
        | files | symbols (all, not top 15) | decisions | full_doc
        | ownership | last_change | metrics | community | health
        | doc_drift | changes | provenance | suspects.
    compact: False adds structure, imports, docstrings.
    symptom: issue text or stack trace to rank ``suspects`` on.
    repo: usually omitted.

Input Schema

Name	Required	Description	Default
`repo`	No
`compact`	No
`include`	No
`symptom`	No
`targets`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.60.1Nov 3, 2026
- removedInput schema / properties / compact / title
```
Removed value: -"Compact"
```
- removedInput schema / properties / include / default
```
Removed value: -null
```
- removedInput schema / properties / include / title
```
Removed value: -"Include"
```
- removedInput schema / properties / repo / default
```
Removed value: -null
```
- removedInput schema / properties / repo / title
```
Removed value: -"Repo"
```
- removedInput schema / properties / symptom / default
```
Removed value: -null
```
- removedInput schema / properties / symptom / title
```
Removed value: -"Symptom"
```
- removedInput schema / properties / targets / title
```
Removed value: -"Targets"
```
- removedInput schema / title
```
Removed value: -"get_contextArguments"
```

Changed1 schema field changedv0.59.0Oct 26, 2026

addedInput schema / properties / symptom

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

First observedv0.1.0Jul 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries most of the load and does add real behavioral context: results are body-elided and line-verified, compact=False adds structure/imports/docstrings, and risk cues imply escalation to get_risk. It stops short of covering pagination, result-size limits, or failure behavior for bad targets, which keeps it below a 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?

It is front-loaded, fragment-dense, and almost every clause carries routing or semantic information. Minor cost: the long pipe-delimited include enumeration is a wall of terms and 'skeleton+' / 'skeleton' distinction is never clarified, which slightly hurts parseability.

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 five-parameter, multi-mode tool with an output schema (so return values need not be explained), the description covers the calling patterns, batching, elision behavior and sibling routing well. Remaining shortfall is per-value meaning for most include modes and no note of defaults, which an agent must infer from the schema.

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?

With schema description coverage at 0%, the description does heavy lifting: it documents target syntax ("path::Symbol", "component:<name>", "change:<id>" as pr/sha, "package:<name>") and explains compact and symptom. The gap is the include list — a long enumeration where only skeleton, references, files and symbols get any meaning, leaving metrics, community, doc_drift, provenance, suspects and 'skeleton+' opaque.

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?

Opens with a concrete role — a triage card for files/modules/symbols that returns relationships rather than source bytes — and enumerates the concrete payload (summary, signatures with lines, hotspot, fix_history, decision titles). It explicitly distinguishes itself from get_symbol and get_risk, so an agent can choose between them without opening a schema.

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?

Gives explicit routing rules: 'either risk cue means get_risk', 'Batch targets in one call', and 'do not call get_symbol per signature' with the skeleton-or-Read alternative. It also supplies scenario recipes — rename via include=["references"], missing tests via include=["files"] — which is the strongest form of when-to-use guidance.

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

Deploy Server