Skip to main content
Glama

Check a public GitHub repo's install steps

check_repo
Read-onlyIdempotent

Scans a public GitHub repo's README install instructions before you clone or run setup, returning a safety verdict and flagged lines without cloning or executing anything.

Instructions

Fetches a public GitHub repo's README (raw.githubusercontent.com, up to 300 KB) and scans its install instructions before you clone it or follow them. Use it when a user or agent is told to 'clone this repo and run the setup' or is evaluating a starter kit, trading bot, wallet tool or MCP server from GitHub. Free and read-only: one unauthenticated HTTPS request to GitHub; nothing is cloned or executed. Only the README is checked here. The optional paid hosted check (https://repo-run-check.nextill-pos.workers.dev/v1/check, 0.005 USDC via x402 on Base) also reads package.json install scripts, dependencies, setup files and repo metadata such as age and fake-star signals. This tool does not pay for it; it only returns its URL. Returns verdict: no_red_flags (nothing matched; not proof of safety), review_before_running (at least one warning: read the flagged lines first) or dangerous (download-and-execute, encoded payloads, known malware hosts and similar: do not run), plus repo, url, advice, files_checked, findings, install_commands, tier, full_report (URL of the paid check) and full_report_price_usdc. Errors if the repo is private, renamed or missing. If the repo is already cloned, check_local_repo covers more files at no cost.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>"
    },
    "name": "check_repo"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoYesPublic GitHub repository as owner/repo or https://github.com/owner/repo (a trailing .git or path is fine). Other hosts are not supported.

Output Schema

NameRequiredDescriptionDefault
urlYes
repoYes
tierYes
adviceYes
verdictYes
findingsYes
full_reportYes
files_checkedYes
install_commandsYes
full_report_price_usdcYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.1.0
    • changedInput schema / properties / repo / description
      Previous value: -"github.com/owner/repo or owner/repo"New value: +"Public GitHub repository as owner/repo or https://github.com/owner/repo (a trailing .git or path is fine). Other hosts are not supported."
    • addedInput schema / properties / repo / maxLength
      Added value: +300
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "advice": {
      +      "type": "string"
      +    },
      +    "files_checked": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "findings": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "code": {
      +            "description": "machine-readable rule id, e.g. pipe_to_shell",
      +            "type": "string"
      +          },
      +          "evidence": {
      +            "description": "the matching text, clipped",
      +            "type": "string"
      +          },
      +          "file": {
      +            "type": "string"
      +          },
      +          "level": {
      +            "enum": [
      +              "info",
      +              "warn",
      +              "danger"
      +            ],
      +            "type": "string"
      +          },
      +          "line": {
      +            "type": "number"
      +          },
      +          "message": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "level",
      +          "code",
      +          "message"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "full_report": {
      +      "type": "string"
      +    },
      +    "full_report_price_usdc": {
      +      "type": "number"
      +    },
      +    "install_commands": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "repo": {
      +      "type": "string"
      +    },
      +    "tier": {
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    },
      +    "verdict": {
      +      "enum": [
      +        "no_red_flags",
      +        "review_before_running",
      +        "dangerous"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "repo",
      +    "url",
      +    "verdict",
      +    "advice",
      +    "files_checked",
      +    "findings",
      +    "install_commands",
      +    "tier",
      +    "full_report",
      +    "full_report_price_usdc"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantial context beyond them: one unauthenticated HTTPS request, nothing cloned or executed, README-only scope, and explicit error behavior for private, renamed or missing repos. The verdict taxonomy (no_red_flags / review_before_running / dangerous) with the caveat that no_red_flags is not proof of safety is exactly the kind of behavioral nuance annotations cannot convey.

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?

Front-loaded with purpose and the safety framing, then scope limits, then return shape, then the sibling pointer — a sensible order. It is somewhat long, with several sentences devoted to the paid hosted check, but that content is load-bearing since the tool returns its URL and price.

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 call mechanics (one unauthenticated request, size cap), scope limits (README only), error conditions, and verdict meanings, and routes to check_local_repo for the broader case. With an output schema present, the description need not enumerate return fields, and it still summarizes the key ones.

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 coverage is 100% and the single 'repo' parameter is fully documented in the schema, including accepted formats and the note that other hosts are unsupported. The description adds no format or edge-case detail beyond that, so the baseline of 3 is appropriate.

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: fetches a public GitHub repo's README from raw.githubusercontent.com and scans its install instructions, with an explicit 300 KB cap. It also distinguishes itself from check_local_repo at the end, so an agent can separate it from siblings without opening any schema.

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 concrete triggering situations ('clone this repo and run the setup', evaluating a starter kit, trading bot, wallet tool or MCP server) and names the alternative for the already-cloned case: check_local_repo. It also clarifies the boundary against the paid hosted check, which this tool only links to rather than invokes.

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