repowise

get_context

Get a triage card for files, modules, or symbols with summaries, signatures, line numbers, and decision records. Batch targets in one call to understand relationships without reading source bytes.

Instructions

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

Returns title, summary, signatures with line numbers, hotspot bit, and
decision_record titles. fix_history appears only on files with counted bug
fixes (count, age, bug_magnet); hotspot is churn. Either one is a cue to
call get_risk. episodes counts the dated records bound to a target — what
happened here and why — and appears only when there is at least one;
get_why serves the bodies. A symbol target is counted as its file, and a
module aggregates everything beneath it.
Batch targets in one call. No source bytes by default: pass
include=["skeleton"] for the whole file body-elided and line-verified in
ONE call, or Read it. Do not call get_symbol per signature.

Default responses fit 24,000 serialized chars; nonempty ``include`` uses
32,000. Reductions carry counts and ``_meta.omitted`` recovery refs;
``_meta.recovery_unavailable`` names a storage failure.
Include-gated blocks are projections, not omissions.

Args:
    targets: file paths, module paths, or "path::Symbol" ids.
    include: opt-in blocks: full_doc | ownership | last_change | callers
        | callees | metrics | community | decisions | skeleton | health
        | doc_drift (documents naming this file).
        An unrecognised key is named in ignored_arguments.
    compact: default True; False adds structure+imports+docstrings.
    repo: usually omitted.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 12, 2026

TDQS

A5/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses 'No source bytes by default', response size limits ('Default responses fit 24,000 serialized chars; nonempty include uses 32,000'), conditional fields ('fix_history appears only...', 'episodes... appears only when there is at least one'), and error recovery ('_meta.omitted recovery refs', '_meta.recovery_unavailable names a storage failure').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear purpose, then structured into return-field semantics, usage guidance, size constraints, and an Args section. Each sentence adds a distinct operational fact; 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?

Given the tool's complexity (4 params, many include options) and that an output schema is present, the description covers input semantics, conditional outputs, size limits, and guidance to alternatives. An agent can invoke it correctly without further documentation.

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 description must add meaning. It explains each arg: targets are 'file paths, module paths, or path::Symbol ids', include lists allowed blocks, compact toggles extra structure, and repo is 'usually omitted'. It also notes unknown include keys are named in ignored_arguments.

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 description opens with 'Triage card for files / modules / symbols — relationships, not source bytes' and then enumerates returned fields. It explicitly names sibling tools: 'call get_risk', 'get_why serves the bodies', and warns 'Do not call get_symbol per signature', distinguishing it from related tools.

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 states 'Either one is a cue to call get_risk' and 'get_why serves the bodies' to route to alternatives. It tells the agent to 'Batch targets in one call' and not to call get_symbol per signature. It also advises passing include=['skeleton'] for body instead of separate read.

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

Deploy Server