EdgeScreen x402 Security Screening

by dev.workers.asostudio.aso-x402-screen

screen_diff

Read-onlyIdempotent

Deterministic pre-merge git diff & PR patch auditor detecting leaked secrets in added lines, destructive shell/SQL commands, GitHub Actions/CI workflow injection, malicious package lifecycle hooks, SSRF & cloud metadata endpoints, auth/TLS verification bypasses, Trojan Source BiDi Unicode smuggling, and corrupt hunk counts. Requires $0.002 (2000 atomic) Base USDC on eip155:8453 via x402 PAYMENT-SIGNATURE header.

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

Input Schema

Name	Required	Description
`diff`	No	Single unified git diff or PR patch shorthand (up to 16384 chars) to audit for leaked secrets, destructive shell/SQL, CI injection, malicious lifecycle hooks, SSRF/private IPs, auth/TLS bypass, Trojan Source Unicode, and corrupt hunk counts.
`diffs`	No	Unified git diffs or PR patches (up to 16384 chars each) to pre-screen before git apply / PR merge.
`patch`	No	Alias for `diff`: single unified git diff or patch snippet (up to 16384 chars) to audit.
`patches`	No	Alias for `diffs`: array of unified git diffs or patch snippets (up to 16384 chars each) to audit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely non-obvious behavior: determinism and a paid x402 flow requiring 0.002 USDC on eip155:8453 via a PAYMENT-SIGNATURE header. That payment/auth requirement is exactly the kind of context annotations cannot convey. It does not describe the response shape, which matters since no output schema exists.

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?

A single front-loaded sentence that leads with the core purpose before the detection list and the payment terms. It is dense and slightly run-on, but every clause carries information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Detection scope, input limits, and the payment precondition are all covered, but with no output schema the description never says what a result looks like — findings list, severity, pass/fail verdict, or how multiple diffs are reported. For an auditor whose whole value is its verdict, that is a meaningful omission.

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% and each of the four parameters is documented in-schema, including the alias relationships (patch→diff, patches→diffs) and size caps. The description adds no parameter-level meaning beyond that, 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 specific verb (audit) and resource (git diff / PR patch) and enumerates the exact classes of problems detected, from leaked secrets to Trojan Source Unicode and corrupt hunk counts. An agent can tell this apart from the screen_* 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 Guidelines3/5

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

The phrase 'pre-merge' and the schema's 'pre-screen before git apply / PR merge' imply the usage context, but the description itself gives no explicit when-to-use/when-not guidance and never names an alternative or complementary tool. Usage is inferable rather than stated.

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

All EdgeScreen x402 Security Screening 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?