Anomaly Tracker MCP

repo_scan

Scan a GitHub repository for anomaly signals like star velocity, fork ratio, overnight spikes, and issue floods, then get a story label and anomaly score.

Instructions

Deep anomaly scan for a single GitHub repository — scores star velocity, fork ratio, overnight explosion signals, and issue flood patterns. Returns a story label (e.g. 'Breakout Signal', 'Viral Activity') and anomaly score. Costs $0.03 USDC on Base mainnet.

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": "repo_scan"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	Yes	GitHub repo in owner/repo format, e.g. vercel/ai or microsoft/vscode

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.2Jun 24, 2026

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description bears the full burden. It discloses the cost ($0.03 USDC) and the nature of the scan (star velocity, fork ratio, etc.), but lacks details on rate limits, authentication needs, or whether it's a read-only operation. The return format is partially described.

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?

The description is two sentences: the first explains the core functionality and signals, the second covers output and cost. No wasted words, front-loaded with key information.

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 only one parameter, no output schema, and no annotations, the description adequately covers the purpose, input format, cost, and output type. It is sufficient for an agent to decide whether and how to invoke the tool.

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?

The single parameter 'repo' is fully covered in the schema with a clear description. The main description reinforces the format with examples, adding value beyond the schema's own description. Baseline is 3 due to 100% coverage, but the extra examples earn a 4.

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 clearly explains that the tool performs a deep anomaly scan on a single GitHub repository, listing specific signals (star velocity, fork ratio, etc.) and stating the return type (story label and anomaly score). This is specific and distinguishes it from siblings like 'github_watch' or 'anomaly_scan'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the tool is for a single GitHub repository, but does not provide explicit guidance on when not to use it or contrast with sibling tools. The purpose is clear, but usage boundaries are implied rather than explicit.

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

Deploy Server