RepoPilot

Inspect repository source evidence or get a decision brief

analyze_repo

Read-onlyIdempotent

CALL to investigate behavior in public source: supply question and relevant path_hints found from actual usages, for up to four files with commit-pinned line citations. checked_sha selects a commit; base_sha adds before/after excerpts; pr selects a public PR and observes its head's GitHub check runs. source_ranges retrieves missing context at pinned revisions, up to 40 lines per range. Selection is bounded, not exhaustive or proof of compatibility. Without question, returns the cached repository decision brief. Pass exactly one of repo or package. Example: {repo:'expressjs/multer',question:'How are file size limits handled?',path_hints:['lib/make-middleware.js']}.

Input Schema

TableJSON Schema

Name	Required	Description
`pr`	No	Public PR number in repo. Requires question. Omit base_sha.
`repo`	No	Public GitHub repository as owner/repo or a github.com URL.
`owner`	No	Repository owner, when repo carries only the bare name. Optional: prefer the single owner/repo form in repo.
`package`	No	npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead.
`base_sha`	No	Compare source at this base commit; omit when using pr.
`question`	No
`path_hints`	No	Scope retrieval to these repository-relative files or directories. Requires question.
`checked_sha`	No	Immutable head revision; required with source_ranges.
`source_ranges`	No	Read only these exact ranges, at most two per file/side and 40 lines per range. Requires question and checked_sha; base side also requires base_sha. Paths must fall within path_hints when supplied. Omit pr for base ranges.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tool`	Yes
`agent`	Yes
`status`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / checked_sha / description

Added value: +"Immutable head revision; required with source_ranges."

addedInput schema / properties / source_ranges

Added value: +{
+  "description": "Read only these exact ranges, at most two per file/side and 40 lines per range. Requires question and checked_sha; base side also requires base_sha. Paths must fall within path_hints when supplied. Omit pr for base ranges.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "end_line": {
+        "description": "Last line, inclusive; from start_line through start_line + 39.",
+        "minimum": 1,
+        "type": "integer"
+      },
+      "path": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      },
+      "side": {
+        "default": "head",
+        "enum": [
+          "head",
+          "base"
+        ],
+        "type": "string"
+      },
+      "start_line": {
+        "description": "First line, inclusive, 1-based.",
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "path",
+      "start_line",
+      "end_line"
+    ],
+    "type": "object"
+  },
+  "maxItems": 4,
+  "type": "array"
+}

Changed5 schema fields changedSep 23, 2026

addedInput schema / properties / base_sha

Added value: +{
+  "description": "Compare source at this base commit; omit when using pr.",
+  "pattern": "^[a-fA-F0-9]{40}$",
+  "type": "string"
+}

addedInput schema / properties / checked_sha

Added value: +{
+  "pattern": "^[a-fA-F0-9]{40}$",
+  "type": "string"
+}

addedInput schema / properties / path_hints

Added value: +{
+  "description": "Scope retrieval to these repository-relative files or directories. Requires question.",
+  "items": {
+    "maxLength": 4096,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 4,
+  "type": "array"
+}

addedInput schema / properties / pr

Added value: +{
+  "description": "Public PR number in repo. Requires question. Omit base_sha.",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / question

Added value: +{
+  "maxLength": 600,
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedSep 17, 2026

addedInput schema / properties / owner

Added value: +{
+  "description": "Repository owner, when repo carries only the bare name. Optional: prefer the single owner/repo form in repo.",
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedAug 23, 2026

changedInput schema / properties / package / description

Previous value: -"npm package name, for example lodash or npm:@scope/pkg."New value: +"npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead."

First observedAug 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: selection is bounded, not exhaustive or proof of compatibility; checked_sha pins an immutable revision; pr observes GitHub check runs; source_ranges retrieves missing context at pinned revisions. It does not contradict annotations. A 4 is appropriate because it adds meaningful behavioral nuance without redundancy.

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 dense but efficient, front-loading the core purpose and then enumerating parameter behaviors in a compact sequence. The example is valuable. It loses one point because the density makes it slightly hard to parse in a single pass, and some information (e.g., 'Requires question') is repeated in the schema. Still, every sentence earns its place.

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?

Given the tool's complexity (9 parameters, multiple modes, output schema present), the description covers the key decision points: repo vs package, question vs no question, pr vs base_sha, and source_ranges constraints. The output schema exists, so return values need not be described. It is not a 5 because the description doesn't explicitly state what happens when both repo and package are omitted or when neither question nor source_ranges is provided, though the schema's oneOf and required constraints partially cover this.

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?

Schema description coverage is 89%, so the schema already documents most parameters well. The description adds semantic value by explaining the relationship between parameters (e.g., checked_sha selects a commit, base_sha adds before/after excerpts, pr observes check runs, source_ranges retrieves missing context) and by giving a concrete example. It doesn't fully explain every parameter interaction, but the schema plus description is strong. Baseline 3 is exceeded because the description clarifies the workflow-level meaning of the parameters.

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 clear verb and resource: 'CALL to investigate behavior in public source' and immediately distinguishes the two modes (evidence retrieval vs. cached decision brief). It names the sibling alternative (evaluate_dependency_change) for package-version judgment, and the example anchors the intended use. This is specific and differentiates from siblings.

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?

The description gives explicit when-to-use guidance: supply question and path_hints for evidence, omit question for the cached brief, pass exactly one of repo or package, and use evaluate_dependency_change for a specific package version. It also states constraints like 'Requires question' and 'Omit base_sha' for pr, which are reinforced in the schema. This is strong routing guidance.

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

All RepoPilot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?