Skip to main content
Glama
Sign In

QuickBuild token-saver tools + x402

by dev.workers.quynguyenbac.quickbuild
OverviewDiscussionsAdmin

Prompt-injection check (rule/pattern filter, no LLM) for text or a page

injection_check
Read-onlyIdempotent

[PAID $0.003 USDC per call via x402 on Base; errors are free] For developers of AI agents that read untrusted web pages, emails or tool outputs. A RULE/PATTERN filter (regex heuristics, no LLM, no model-quality promise): flags instruction overrides ("ignore previous instructions"), role/system impersonation (<|im_start|>, [INST], "system:"), exfiltration requests (send keys/secrets to a URL), hidden text (zero-width/bidi/Unicode-tag chars, HTML comments, display:none / white text, base64 blobs that decode to instructions), tool-call / shell command injection, markdown image/link exfil, and overrides in EN/ES/FR/DE/ZH/JA/RU. POST JSON {"text"} (max 32 KB) or GET ?text= for short text, or {"url"} to fetch one public https page (port 443, public hosts only, max 2 redirects, 64 KB read, 4 s timeout). Returns verdict, score 0-100, findings (category, snippet <= 80 chars with secrets redacted, position) and an honest limits note. Paraphrased or novel attacks can be missed; not a guarantee. Missing/oversized input = 400/413, unreachable page = 502/504, never charged.

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

Input Schema

NameRequiredDescriptionDefault
urlNoOptional instead of text: public https page to fetch and scan (64 KB read).
textNoContent to scan (max 32768 chars). Use POST for long text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Even accounting for the annotations (readOnly/idempotent/non-destructive/openWorld), the description adds substantial operational context: pricing and that errors are free, exact input limits (32 KB text, 64 KB page read, 2 redirects, 4 s timeout, port 443 public hosts only), and an explicit honesty clause that paraphrased or novel attacks can be missed. It also documents failure modes (400/413/502/504, never charged), which the annotations cannot convey.

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?

Dense but front-loaded: billing and audience first, then method, then capabilities, then request shapes and failure codes. The long enumeration of attack categories is justified since it defines scope, though the single paragraph is heavy and could be split for faster scanning.

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?

With no output schema, the description still summarizes the return shape (verdict, 0-100 score, findings with redacted snippets and positions, plus a limits note) and covers limits, pricing, input constraints and error behavior. For a two-optional-parameter read-only scanner, an agent has everything needed to call it and interpret results correctly.

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 coverage is 100%, so the baseline is 3; the description goes further by explaining the POST-vs-GET delivery choice for text and the exact fetch constraints for the url path (public https, port 443, redirect and size caps). It does not explain how the two optional params interact if both are supplied, which is the only remaining gap.

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 names a specific verb and resource (flag prompt-injection patterns in text or a fetched page) and immediately delimits the method: 'A RULE/PATTERN filter (regex heuristics, no LLM, no model-quality promise)'. It also enumerates the concrete attack categories flagged, so an agent can distinguish it from siblings like url_to_markdown or website_audit without opening the 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?

The audience and trigger are stated ('for developers of AI agents that read untrusted web pages, emails or tool outputs'), and it clarifies this is a pre-check filter rather than a guarantee. It does not name a sibling alternative or state when NOT to use it, which keeps it at 4 rather than 5.

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

All QuickBuild token-saver tools + x402 toolsInspect
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