repowise

get_overview

Map an unfamiliar repository by returning its overview summary, key modules, entry points, architecture layers, dependencies, and code/git health, with suggested next actions.

Instructions

Architecture map for an unfamiliar repo — first call when you don't know your way around.

Returns the overview summary, key modules, entry points, architecture
layers and package dependencies, code health, repo-wide git health, and
``next_actions`` (top work for the week and quarter).
Skip this on subsequent calls — once you have the map, jump straight to
``get_context`` / ``get_answer``.

Compact by default: ``content_md`` carries only the overview essay's summary
section, and the outline, onboarding, ownership and graph blocks ship only
on request. The response's ``more`` field names them.

Defaults fit 24,000 chars; nonempty ``include`` uses 32,000. Reductions
carry counts and recovery status in ``_meta``.
Include-gated blocks are projections, not omissions.

In workspace mode:
- Omit ``repo`` for the default repo's overview plus a workspace footer.
- ``repo="all"`` returns the cross-repo topology (co-changes, package deps,
  API contracts) — no single-repo detail.
- ``repo="<alias>"`` targets one specific repo.

Args:
    repo: Repository alias, path, or ID. Use ``"all"`` for workspace overview.
    include: Opt-in extras, any combination of:
        ``"content"`` — the full overview essay instead of its summary.
        ``"outline"`` — the stored wiki page tree, two rungs deep.
        ``"tour"`` — ``guided_tour`` + ``reading_order`` onboarding walks.
        ``"decisions"`` — ``key_decisions``; ``get_why`` is richer.
        ``"graph"`` — ``community_summary``, code-community clusters.
        ``"ownership"`` — ``knowledge_map``: top 3 owners by files owned.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo`	No
`include`	No

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 exist, so the description carries the full burden and does so well: it discloses that output is compact by default, exactly which blocks are include-gated, that the `more` field names them, the 24,000/32,000-char budgets, and that reductions are reported with counts and recovery status in `_meta`. This is real behavioral context an agent cannot get from the schema.

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?

Front-loads purpose and the skip-rule before the detail, then layers defaults, workspace modes, and args. Despite the length, every block is load-bearing for a two-mode tool with six include flags; nothing is padding.

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?

Covers default behavior, opt-in blocks, size limits, workspace vs single-repo modes, and recovery metadata. With an output schema present it goes beyond the minimum by explaining the `more`/`_meta` contract, so an agent needs nothing else to call it correctly.

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 coverage is 0% and neither parameter has a type-level description, yet the description fully specifies both: `repo` accepts alias/path/ID or the sentinel "all" (with the semantics of each mode), and `include` enumerates all six accepted string values with what each one adds.

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 metaphor-plus-verb ("Architecture map for an unfamiliar repo") and explicitly positions itself as "first call when you don't know your way around," which separates it from get_context, get_answer and get_why by name.

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 both when-to-use ("first call when you don't know your way around") and when-not ("Skip this on subsequent calls — once you have the map, jump straight to get_context / get_answer"), and routes the three repo modes to their distinct situations.

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

Deploy Server