Tool names are ASCII identifier-shaped
Authored by Stanley Hong · AgentReserve (founder).
Every advertised tool name matches `/^[a-zA-Z][a-zA-Z0-9_.-]{0,63}$/` — a length-bounded ASCII identifier. Names with shell metacharacters, whitespace, control characters, or unicode look-alikes can confuse logging, agent argument parsers, and reviewers.
When this rule runs
Requires a successful MCP `initialize` / `tools/list`. Skipped on perimeter-only scans where the server refused or failed the MCP handshake.
Why it matters
Tool names land in agent prompts, logs, and routing tables. A name with shell metacharacters or unicode look-alikes (`сoffee` instead of `coffee`) is a quiet way to confuse log analysis, slip past allow-lists, or impersonate a sibling tool. Constraining names to plain ASCII identifiers forecloses the trick.
Pass condition
Every tool name matches the ASCII identifier shape and is at most 64 characters.
Fail condition
At least one tool name contains whitespace, shell metacharacters, control characters, non-ASCII characters, or exceeds 64 characters.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"unsafeNames": [{"toolName": "list files", "reason": "contains-whitespace"}]}
Remediation
Rename tools to plain ASCII identifiers (`[a-zA-Z][a-zA-Z0-9_.-]{0,63}`). Treat the tool name as a stable machine identifier, not a display label.
Methodology
This rule belongs to the Schema quality dimension. Whether the tool surface is reviewable without invoking it. Tools without input schemas force agents to guess argument shapes; tool names that aren't plain ASCII identifiers confuse logging and allow-listing.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.