Exepal

Agent rules-file scanner

scan_rules

Read-onlyIdempotent

Rules-file scanner: checks CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules, copilot-instructions.md, GEMINI.md, .windsurfrules, .clinerules, .mcp.json and .claude/settings.json for hidden Unicode instructions (the rules-file backdoor), hidden comments, remote-code and data-leak commands, safety bypasses, planted scripts, risky URLs and leaked secrets; up to 20 files per call. Use before trusting or committing an agent instruction or config file you did not write: a cloned repo's CLAUDE.md or AGENTS.md, a .cursorrules from a template site, a shared .mcp.json or .claude/settings.json, or a pull request that edits one. Pass text (+ path) for one file, files[] {path, text} for up to 20, or url for a raw file. Ordinary rules-file content is expected and not flagged; only hidden text, data leaks, curl|sh, skip-permission flags, credential access, planted tags, silent changes, risky URLs (webhook collectors, tunnels, paste sites, shorteners, raw IPs) and secrets are. Returns verdict (clean, review, dangerous), score 0-100 (higher is riskier), files[] {path, fileType, verdict, score, findings[] {rule, severity, message, evidence, line, location}, hidden, urls[], secrets, clean (the text with invisible characters removed)} and summary. Nothing is stored. Price: $0.002 per call from Exepal credit; not charged if the call fails. Includes free daily calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_rules"
  }
}

Input Schema

Name	Required	Description
`url`	No	Instead of text: a public raw file URL, e.g. https://raw.githubusercontent.com/owner/repo/main/CLAUDE.md
`path`	No	Its file name or path, e.g. CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/style.mdc, .github/copilot-instructions.md, .mcp.json or .claude/settings.json; picks the file type
`text`	No	Content of one rules or agent-config file (up to 500,000 characters)
`files`	No	Instead of text: up to 20 files {path, text}, e.g. every agent file in a repo (2,000,000 characters in total)

Output Schema

Name	Required	Description
`url`	No	Present when a url was fetched
`files`	No	One entry per file, in input order
`score`	No	Highest file score, 0-100, higher is riskier
`summary`	No
`verdict`	No	Worst verdict across files: clean, review or dangerous
`finalUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior, but the description adds substantial operational context: nothing is stored, up to 20 files per call, pricing and failure charging, free daily calls, and expected ordinary content is not flagged. It also discloses the verdict/score/findings return shape and what constitutes a finding.

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 and front-loaded with purpose, then usage, input modes, detection scope, return shape, and billing. It is appropriately sized for a complex multi-file scanner, though the long semicolon-delimited sentence could be more scannable.

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?

The tool is complex: ten file types, three input modes, nested findings, verdicts, scores, and billing. The description covers all of that, and even though an output schema exists, it helpfully explains the return shape. Nothing an agent needs in order to call it correctly appears to be missing.

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 100%, so the schema already documents each parameter. The description still adds useful mode-selection semantics beyond the schema: pass text plus path for one file, files[] for up to 20 files, or url for a raw file, and path is used to pick the file type. This meaningfully reduces invocation ambiguity.

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 specific verb and resource: a rules-file scanner that checks named agent instruction and config files for hidden Unicode instructions, hidden comments, remote-code commands, bypasses, planted scripts, risky URLs, and secrets. It is immediately distinguishable from generic scanners by its file-type focus and the explicit list of inspected artifacts.

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?

It gives strong when-to-use guidance: before trusting or committing an agent instruction or config file you did not write, with concrete examples such as a cloned repo's CLAUDE.md, a template .cursorrules, a shared .mcp.json, or a PR editing one. It also explains the three input modes. However, it does not explicitly route the agent against overlapping siblings like scan_injection, scan_mcp, or scan_secrets.

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

All Exepal 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?