Skip to main content
Glama

Check a GitHub repository for security issues

scan_repo
DestructiveIdempotent

Use this when the person wants a public GitHub repository checked for leaked secrets, vulnerable or malicious dependencies and risky code. No code is run. 3 free checks a day per account, then $1 when the check finishes; a failed check costs nothing. Do not use for websites (use scan_url) or private repositories.

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_url": "<repo_url>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "scan_repo"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNoOptional branch name. Default: the repository's default branch.
languageNoThe language the person is writing in, as a BCP 47 tag such as "ru".
repo_urlYesA public GitHub repository, for example https://github.com/owner/repo
idempotency_keyYesA unique string naming this check. Reuse it to collect the result or to retry; the same key is never charged twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "The language the person is writing in, as a BCP 47 tag such as \"ru\".",
      +  "maxLength": 35,
      +  "pattern": "^[a-z]{2,3}(-[A-Za-z0-9]{2,8})?$",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Adds context the annotations cannot express: no code is executed, 3 free checks per day per account, $1 charged only when a check finishes, failed checks are free. This complements destructiveHint/idempotentHint rather than restating them. It stops short of saying the check is asynchronous and that results are collected via job_status, which is the main behavioral gap.

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?

Four short sentences, each carrying distinct information: trigger, scope, safety, cost, exclusions. Exclusions are placed last where they act as a final routing guard, and nothing is padded.

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?

Covers trigger, scope, cost model, and non-goals for a paid, open-world scan. The one missing piece is how a result is retrieved (the idempotency key plus job_status sibling imply an async collect step the description never mentions), which matters for correct multi-call use.

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 carries branch, language tag, URL format, and idempotency semantics. The description adds nothing parameter-specific beyond pricing implications, so the baseline 3 applies.

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 concrete verb and resource (check a public GitHub repository) plus the exact scope of the check (leaked secrets, vulnerable/malicious dependencies, risky code). It explicitly distinguishes itself from scan_url, so an agent can route without opening either 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?

Opens with a direct trigger ('Use this when the person wants...') and names two exclusions with the alternative for one of them (websites → scan_url) and a hard limit for the other (no private repositories). Little is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources