repowise

get_overview

Map an unfamiliar repo by returning architecture overview, key modules, entry points, layers, and code plus git health. Use it first to orient before deeper context calls.

Instructions

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

Returns the synthesised overview summary, key modules, entry points,
architecture layers, code health, and repo-wide git health (hotspot count,
churn trend, bus-factor distribution).
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 owners, knowledge silos.

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

A4.9/5.0

Behavior5/5

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

With no annotations present, the description carries the full disclosure burden and does so thoroughly. It reveals compact-by-default output, the `more` field, char-limit behavior, `_meta` reduction reporting, and the "projections, not omissions" semantics for gated blocks. This gives an agent an accurate mental model of side effects, output shape, and cost implications beyond the raw schema.

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 front-loaded with its core value proposition and then organized into clear sections: returns, when-to-skip, default behavior, workspace modes, and args. It is long, but nearly every detail earns its place; minor redundancy exists between workspace mode bullets and the repo arg line, though this does not meaningfully hurt clarity.

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 an output schema exists and both parameters are thoroughly documented in prose, the description supplies all essentials: what the tool returns, how to request extras, how workspace scoping changes results, and how large payloads are managed. No critical operational information required to invoke or interpret the tool appears to be missing.

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%, but the description fully compensates with an Args section explaining repo as alias/path/ID and "all", and enumerating every include value with the exact block each one activates. The semantic meaning is far richer than the bare schema, which only says two nullable fields with defaults.

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 a crisp job statement — "Architecture map for an unfamiliar repo" — and enumerates the concrete contents: overview summary, key modules, entry points, architecture layers, code health, and git health. It also distances itself from later-stage siblings by naming get_context / get_answer as follow-ups, so the tool's place in a workflow is unmistakable.

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?

Usage is explicit: this is the "first call when you don't know your way around," and it should be skipped once the map exists in favor of get_context / get_answer. Workspace-mode behavior is fully specified for omitted repo, repo="all", and repo="<alias>", leaving no ambiguity about when each call shape 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