Skip to main content
Glama
MykytaStel

repopilot

by MykytaStel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

repopilot_context

Read-onlyIdempotent

Generate a token-budgeted Markdown brief of a repository to orient before editing unfamiliar code, covering risks, hotspots, and structure without uploading source.

Instructions

Generate a budgeted Markdown brief of the repository (risks, hotspots, structure) to read before editing, especially in an unfamiliar codebase. Use it for orientation. For the full findings as JSON, use repopilot_scan; to review a change, use repopilot_review_change. Pass analysis_handle to make sure the brief still matches an earlier scan or review. Built locally from a scan; no AI service is called and nothing is uploaded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoRepository path. Defaults to the current working directory.
focusNoOptional focus: security, architecture (or arch), quality, framework, or all.
budgetNoOptional approximate token budget for the brief. Defaults to the standard budget.
configNoOptional repopilot.toml path. Defaults to the one discovered in the repository.
profileNo"default" hides low-signal suggestions; "strict" includes all findings.default
analysis_handleNoOptional `analysisHandle` from an earlier repopilot_scan or repopilot_review_change call. The call fails if the workspace changed since that analysis.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
decisionNoCanonical primary review decision and next action from the referenced review handle, when selected.
evidenceNoCanonical evidence class, coverage, and provenance from the referenced review handle, when selected.
markdownYes
change_proofNoCanonical ChangeProof from the referenced review handle, when selected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.24.2
    • changedInput schema / properties / analysis_handle / description
      Previous value: -"Optional scan/review handle whose workspace revision must still match before context is generated."New value: +"Optional `analysisHandle` from an earlier repopilot_scan or repopilot_review_change call. The call fails if the workspace changed since that analysis."
    • changedInput schema / properties / config / description
      Previous value: -"Optional repopilot.toml path."New value: +"Optional repopilot.toml path. Defaults to the one discovered in the repository."
    • addedInput schema / properties / profile / description
      Added value: +"\"default\" hides low-signal suggestions; \"strict\" includes all findings."
  2. First observedv0.24.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing that the brief is built locally from a scan, no AI service is called, nothing is uploaded, and that passing analysis_handle will cause the call to fail if the workspace changed since that analysis. The failure condition in particular is non-obvious behavioral context an agent needs.

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-loaded with the deliverable and its use case, then sibling routing, then the handle-matching caveat, then the local-execution guarantee. Every sentence carries distinct information and nothing is repeated from the schema.

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?

An output schema exists so return values need no explanation in prose. With usage context, sibling routing, parameter linkage, and execution/safety notes all covered, an agent has everything needed to select and invoke this tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters including defaults and the enum meaning for profile. The description only reinforces the purpose of analysis_handle ('make sure the brief still matches an earlier scan or review') without adding syntax or format detail beyond the 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?

States a specific verb and resource ('Generate a budgeted Markdown brief of the repository') and names what the brief contains (risks, hotspots, structure) plus its intended purpose (read before editing). This clearly distinguishes it from repopilot_scan's JSON findings and repopilot_review_change's change review.

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?

Explicitly says when to use it ('especially in an unfamiliar codebase. Use it for orientation') and routes the agent to alternatives by name: repopilot_scan for full JSON findings, repopilot_review_change for reviewing a change. Both the when and the when-not are stated.

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

Deploy Server

Other Tools