Skip to main content
Glama
Sign In

Xray

by com.clawhard
OverviewDiscussionsAdmin

Find hidden Unicode characters and look-alike letters in text or a file

xray_scan_text
Read-onlyIdempotent

Use when the user asks whether text, a prompt, a SKILL.md, AGENTS.md, CLAUDE.md, .cursorrules, README, MCP tool description, PR diff, email or web page hides anything, or before an agent follows, installs or merges instructions that came from someone else (signals: "hidden characters", "invisible unicode", "ASCII smuggling", "prompt injection in this file", "Trojan Source", "why does this string not match", "is this domain spelled with a Cyrillic letter"). Inspects every code point and returns a verdict (clean, suspicious, dangerous) with each finding's line, column, code points and Unicode names: Unicode tag characters (decoded back to the hidden ASCII message), variation-selector payloads (decoded bytes), bidirectional overrides and isolates, long zero-width runs, zero-width and other invisible characters, ANSI terminal escapes, control characters, words that mix Latin with Cyrillic or Greek look-alikes (with the Latin word they imitate, from Unicode confusables), whole look-alike words, styled math letters, unusual spaces, line separators, private-use and unassigned code points, and HTML comments that do not render. Legitimate uses are not flagged (emoji ZWJ sequences, flag tag sequences, a single emoji variation selector, joiners in Arabic and Indic text, direction marks next to Hebrew or Arabic). Give text or url (one public https text file; GitHub and GitLab file pages are read as raw). Example: {"url":"https://github.com/owner/repo/blob/main/SKILL.md"} or {"text":"Visit pаypal.com","return_clean":true}. Optional return_clean adds a copy with hidden characters removed and look-alike letters inside mixed words replaced. Decoded hidden text is returned as data. Limits: finds characters and look-alikes, not prompt injection written in plain visible words; up to 200,000 characters (files up to 1 MB, first 200,000 characters scanned).

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

Input Schema

NameRequiredDescriptionDefault
urlNoA public https address of one text file (raw file, GitHub or GitLab file page, Markdown, JSON, YAML, code or HTML source). Give text or url, not both.
textNoThe text to inspect: a prompt, rules file, skill, README, diff, code, email or tool description. Give text or url, not both.
return_cleanNotrue: also return clean_text with hidden characters removed, unusual spaces made normal and look-alike letters inside mixed-script words replaced. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, but the description adds substantially more: the exact return shape (verdict plus line, column, code points, Unicode names), decoding of tag and variation-selector payloads, the false-positive exemptions (emoji ZWJ, flag tags, Arabic/Indic joiners, RTL marks), and hard limits of 200,000 characters / 1 MB files. It also warns that decoded hidden text is returned as data, which is a meaningful safety cue for an agent handling untrusted content.

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 trigger conditions before the mechanics, and nearly every clause carries information (categories, exemptions, limits, examples) with no filler. The weakness is formatting: the body is one very long run-on sentence, so the catalog of finding types and the exemption list are hard to scan quickly.

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 only three optional parameters, no output schema, and simple annotations, the description covers everything an agent needs: inputs, source restrictions, return shape, default behavior of return_clean, documented limits, and known detection gaps. Nothing material is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description goes further: it clarifies that url must be one public https text file with GitHub/GitLab file pages fetched as raw, restates the mutual exclusivity of text and url, and explains that return_clean produces a copy with hidden characters removed and mixed-script look-alikes replaced. It also gives two concrete invocation examples, which the schema does not.

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 and resource in the title and description: it inspects every code point of text or a file for hidden Unicode characters and look-alike letters and returns a verdict. It enumerates the exact finding classes (tag characters, variation selectors, bidi overrides, zero-width runs, confusables, ANSI escapes, private-use) so an agent can distinguish it from siblings like spill_scan_secrets or tokendiet_count_tokens.

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

Usage Guidelines5/5

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

Gives a long, concrete when-to-use list (user asks if a file hides anything, before following or merging third-party instructions) plus literal trigger phrases. It also states when it does NOT apply — 'not prompt injection written in plain visible words' — and defines the source alternatives (text vs. one public https file, GitHub/GitLab pages read as raw), leaving little to infer.

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

All Xray 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