Skip to main content
Every firewall rule starts by answering which tool calls do I apply to? The first half of that answer is a tool name glob — the tool_name_glob field on a rule. It’s a deliberately small, case-sensitive grammar (no regex, no backtracking) so a rule reads the same way you’d type a tool name from the Discovered tools tab, and matching stays linear-time on the relay hot path. This page is the focused grammar reference for that one field. For where a glob sits inside a full rule — the surface, argument clauses, egress lists, verdict — see Rule schema and the deep engine reference in Firewall Rules.

​
1. Why a tool name glob instead of regex

Tools are conventionally namespaced server.tool or category.action (shell.exec, db.query, community.http_fetch). A glob lets one rule catch a whole family — shell.* for every shell verb, *.delete for a verb across servers — without the foot-guns of a regex on a path that runs on every tool call.
The grammar is intentionally tiny. Matching is case-sensitive — MCP tool names are conventionally lowercase-with-dots, so a case-fold would surprise an author who copy-pastes a name straight from the Discovered tools view. There’s no catastrophic backtracking because there’s no regex engine behind it; every pattern below is a handful of string operations.

​
2. The five pattern shapes

A tool name glob is exactly one of these shapes. Anything that doesn’t fit the wildcard forms is treated as a literal, exact match.
PatternShapeMatches
"" or *anyEvery tool call.
foo.*prefixfoo.bar, foo.exec — not bare foo.
*.execsuffixshell.exec, db.exec, and bare exec.
*.shell.*infixlocal.shell.exec, byo.shell.run.
shell.execexactOnly the literal string shell.exec.
Read the next sections for the one edge in each shape that trips people up.

​
3. Prefix — foo.*

Matches any tool whose name starts with foo. and has at least one more character after the dot.

Matches

shell.exec, shell.run, shell.rm for the pattern shell.*

Does not match

bare shell (the prefix requires the trailing dot and something after it)
Use a prefix glob to govern an entire server or category at once — one shell.* deny covers every shell verb a server might add later.

​
4. Suffix — *.exec

Matches any tool whose name ends with .exec, anchored at a dot — and also matches the bare, un-namespaced verb exec on its own.
The bare-verb match is deliberate. Provider-native function calls and MCP servers that don’t namespace expose a tool under its bare verb (just exec, not shell.exec). A *.exec rule covers both shapes so a non-namespacing tool isn’t silently missed.
The suffix stays anchored — it won’t match a partial word:
Patternshell.execbare execshell.execute
*.execmatchesmatchesno match
*.execute would be needed for shell.execute; the suffix only fires at a dot boundary or the start of the string, never mid-word.

​
5. Infix — *.shell.*

Matches any tool name that contains .shell. as an infix, with at least one character on each side. This is how one rule covers a verb wherever a BYO-MCP server happens to namespace it. 
{
  "label": "gate every shell tool, any server",
  "tool_name_glob": "*.shell.*",
  "verdict": "deny"
}
That rule matches local.shell.exec, byo.shell.run, and any other <server>.shell.<verb> shape. It does not match bare shell or a bare .shell. with nothing around it — the character-on-each-side requirement keeps the infix honest.
The infix form is only the symmetric *.X.* shape. A pattern with a star in the middle — foo.*.bar — is not an infix glob; it falls through to an exact string match (it only matches a tool literally named foo.*.bar, which won’t exist). To match “starts with foo., ends with .bar” you need two rules or an argument clause, not one glob.

​
6. Exact — shell.exec

Anything that isn’t one of the wildcard shapes above is a literal string match. shell.exec matches shell.exec and nothing else. This is the right choice when you want to name one specific tool — pair it with an argument clause to narrow further (“block shell.exec only when the command is rm -rf”).

​
7. One concrete example

Say you want to deny every destructive shell verb regardless of how an MCP server namespaces it, while letting everything else audit. In the console rule editor (writes require Developer+), the match half of the rule is a single infix glob: 
{
  "label": "deny shell across servers",
  "stage": "response",
  "tool_name_glob": "*.shell.*",
  "verdict": "deny"
}
Attach a key to the policy (firewall_policy_id on the key), and the rule now catches local.shell.exec, byo.shell.run, and acme.shell.rm — three servers, one glob. Want to confirm it fires on what you expect before you depend on it? Use Test rules — it returns the verdict, the matched rule, and the reason without dispatching anything.
A glob narrows which tool. To narrow with what arguments, AND an argument clause onto the same rule; to govern a tool only when a particular skill owns it, add a skill name glob (same grammar, matched against the owning skill). Both are covered in Firewall Rules.

​
8. Quick reference

Yes. *.exec matches shell.exec, db.exec, and the bare, un-namespaced exec. Prefix globs (foo.*) do not match the bare namespace foo — only names with something after the dot.
No. The only wildcard-in-the-middle shape the engine understands is the symmetric infix *.X.*. foo.*.bar falls through to an exact literal match. Use two rules or an argument clause instead.
Yes. Shell.Exec and shell.exec are different tools. Copy names verbatim from the Discovered tools tab.
Any shape that isn’t one of the five above is treated as an exact match — it simply won’t match a real tool name, so the rule never fires rather than matching something unexpected. The console validates rules on save.

Tool allow-listing

Use globs to allow a known set and deny the rest.

Validate arguments

AND a JSONPath argument clause onto a glob.

Rule schema

Every field of a rule, in one place.
For the full matching language — verdicts, surfaces, egress lists, and sequences — see Firewall Rules. New to the plane? Start at the Firewall overview.