Skip to main content
Glama

check_compliance

Scan x402 files or directories for hardcoded chain IDs, decimals, decimal scaling, float amounts, and literal token addresses; get file:line severity findings for compliance review.

Instructions

Heuristically scan x402 code (a file or directory) for the high-severity classes: hardcoded chain id, hardcoded decimals, magic-number decimal scaling (10**N, 1eN, *1_000_000), human-decimal/float amounts, and literal asset/token addresses. Returns findings with file:line and severity. Heuristic — a documented default may be a false positive; every finding cites a location for human judgement. No network.

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": {
      "path": "<path>"
    },
    "name": "check_compliance"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesA file or directory to scan.
maxFilesNoCap on files scanned (default 2000).
maxFindingsNoCap on findings returned (default 300).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of the work: it discloses that the analysis is heuristic rather than definitive, that findings are location-anchored for human review, and that no network access occurs. It does not explicitly state that the tool only reads and never mutates the target code, which a careful agent might still want confirmed.

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 the verb and target, then the defect list, then the return shape, then the heuristic caveat — a logical progression with no filler. The enumerations of decimal idioms are dense but each item is informative, not redundant.

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?

There is no output schema, and the description compensates by stating findings carry file:line and severity, which is enough for an agent to plan tool use and report results. Minor gap: the severity vocabulary and finding object shape are not specified, so the agent must inspect actual output to learn them.

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 path, maxFiles and maxFindings are already documented with defaults. The description adds nothing about the caps (e.g. what happens when maxFiles/maxFindings are hit or whether truncation is signaled), so it lands at the baseline for a fully-described 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 (heuristically scan) and resource (x402 code, file or directory) and then enumerates the exact defect classes targeted: hardcoded chain id, hardcoded decimals, magic-number scaling, float amounts, literal addresses. An agent can distinguish this from siblings like lint_scheme_spec or run_conformance without reading 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 Guidelines4/5

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

Clear operational context is given: a single path is scanned, findings come back with file:line and severity, and 'No network' bounds the environment. It also sets expectations about interpreting results ('a documented default may be a false positive; every finding cites a location for human judgement'). What is missing is explicit routing against the sibling tools — it never says when to prefer this over lint_scheme_spec or run_conformance.

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