{
"answer": "The whats-allowed-mcp server audits and reports on the merged permission configuration in effect for a directory — it analyzes and explains, but never edits or simulates decisions.\n\n- whats_allowed — One-call summary of all permissions in force: which settings files contribute, rule counts by type (allow/ask/deny), the winning defaultMode, blanket allows, hooks wired to tool use, and how many rules don't do what they appear to.\n- permission_sources — Lists every settings file that can contribute rules (managed policy, project, local, user, session) in precedence order, reporting existence, parse status, rule counts, and how a leading / anchors path rules in each.\n- rule_findings — Surfaces rules whose documented behavior differs from apparent intent: inert rules (accepted but never consulted, e.g. Write, NotebookEdit, Glob), /path rules in user settings anchoring to the config directory instead of the project, wildcards without word boundaries, allow rules on command-runners (npx, docker exec, bash -c), and allow rules shadowed by a deny or ask rule that fires first. Filter by kind: inert, misreads, wider, shadowed, duplicate.\n- unattended_surface — Shows what lets a tool call proceed without human approval: the winning defaultMode, blanket allows, extra directories granted, whether bypass/auto modes are disabled, and hook commands wired to agent events.\n\nScope and limitations:\n- Read-only — only node:fs, node:path, node:os; no child processes, network, or writes. Nothing in a settings file is executed.\n- Never reads env values (only names) and never reads or runs apiKeyHelper scripts, avoiding plaintext secret leaks.\n- Does not simulate client decisions (no "would this command be allowed" verdict) — use /permissions in your client for the live view.\n- Command-line flags (--allowedTools, --permission-mode, etc.) are invisible since they're not on disk.\n- Every finding is conservative and links to documented Anthropic behavior — no risk scores or intent judgements.\n- Each tool takes an optional dir argument (absolute path) defaulting to the server's working directory."
}
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@whats-allowed-mcp What permission rules are being silently ignored?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
You wrote a deny rule. Did it do anything? An MCP server that reads every settings file feeding your agent's permissions, shows which one wins, and lists the rules your client accepts and then ignores.
Permission rules for a coding agent are not in one file. They are in up to five at once: a machine-wide managed policy, the project file your team commits, a git-ignored local file, your user file, and whatever a session wrote. They are merged, and then evaluated deny → ask → allow, where the first match wins and specificity does not break the tie.
That merge is hard enough. The part that actually bites is that several rule shapes are accepted and then quietly do nothing:
Write(docs/**) — file permissions are checked against Edit(path) and Read(path) rules only. A Write, NotebookEdit, MultiEdit or Glob path rule is accepted and never consulted.
Bash(command:rm *) — a rule can't match a tool's primary content field with the param:value form. It is ignored, because a compound command would bypass it.
"mcp__*" in allow — an unanchored allow glob is skipped and auto-approves nothing.
Read(/.env) in user settings — a single leading slash anchors at the settings source, so that rule protects ~/.claude/.env, not the .env in each of your projects.
Bash(git push origin main) in allow under a Bash(git push *) in deny — a deny rule cannot carry allowlist exceptions, so the allow rule is unreachable.
Claude Code warns about some of these at startup, in a scrollback you have already lost by the time you care. Nothing collects them, nothing tells the agent itself, and nothing shows you the merged picture across all five files at once. This does.
Related MCP server: AgentWard
Given a project .claude/settings.json:
{
"permissions": {
"deny": ["Bash(git push *)", "Write(.env*)"],
"allow": [
"Bash(npm run test:*)",
"Bash(git push origin main)",
"Bash(npx *)",
"Bash(ls*)"
]
}
}…and a user ~/.claude/settings.json with "deny": ["Read(/.env)"] and "defaultMode": "acceptEdits", whats_allowed returns (paths shortened here):
# Permissions in force
| | |
|---|---|
| Settings files contributing | 2 of 5 possible |
| Permission rules | 3 deny, 0 ask, 4 allow |
| Blanket allow rules (whole tool) | 0 |
| Hook commands wired to agent events | 0 |
| Extra directories granted | 0 |
| Rules that do not do what they look like | 5, of which 1 is ignored outright |
## Default mode
`defaultMode` = **`acceptEdits`**, set in User (`~/.claude/settings.json`).
> Automatically accepts file edits and common filesystem commands (`mkdir`,
> `touch`, `mv`, `cp`) for paths in the working directory or additionalDirectories.
## First things to look at
- **Path rule on Write** — `Write(.env*)` in Project settings
- **Allow rule on a command runner (`npx`)** — `Bash(npx *)` in Project settings
- **Trailing wildcard with no word boundary** — `Bash(ls*)` in Project settingsSeven rules. Five of them do something other than what they read as — and the one everybody would have bet on, Write(.env*), is never consulted at all.
Tool | What it answers |
| The headline: which files contribute, how many deny/ask/allow rules, the winning |
| Which file decides, in precedence order — existence, parse state, rule counts, and what a leading |
| Every rule whose documented behaviour differs from its apparent intent, with the reason and the documented alternative |
| What proceeds with nobody watching: default mode, blanket allows, extra directories, mode guards, and hook commands |
Claude Desktop (one-click, no terminal): download the latest whats-allowed-mcp-<version>.dxt from Releases and open it with Claude Desktop (double-click, or Settings → Extensions → Install Extension…). The server and its dependencies ship inside the bundle — no npm, no Node install.
Register with Claude Code (available in every session):
claude mcp add --scope user whats-allowed -- npx -y whats-allowed-mcpOr in any MCP client config:
{
"mcpServers": {
"whats-allowed": {
"command": "npx",
"args": ["-y", "whats-allowed-mcp"]
}
}
}git clone https://github.com/stcmain/whats-allowed-mcp
cd whats-allowed-mcp && npm install && npm run build
# then point your client at node /path/to/whats-allowed-mcp/dist/index.jsPublished as whats-allowed-mcp on npm and as io.github.stcmain/whats-allowed-mcp in the MCP Registry.
No configuration. No environment variables. Respects CLAUDE_CONFIG_DIR when you have moved your user config.
Every finding corresponds to behaviour Anthropic documents, and every one links to the paragraph it comes from. There is no risk score, no severity ranking and no "suspicious rule" heuristic — those produce confident nonsense on ordinary configurations.
Reported:
Path rules on Write / NotebookEdit / MultiEdit / Glob, which file permission checks never consult
Tool(param:value) rules aimed at a tool's primary content field, which are ignored outright
Unanchored tool-name globs in allow, which auto-approve nothing
:* used anywhere but the end of a shell pattern, where the colon is literal
/path rules in user settings, which anchor at the config directory rather than at your project
Trailing * with no word boundary — Bash(ls*) also matches lsof
Allow rules on commands that run other commands (npx, docker exec, bash -c, xargs, devbox run…), which approve whatever follows them
Bash rules that try to constrain a URL, which the docs themselves call fragile
Allow rules a deny or ask rule reaches first
Rules declared in more than one file
Deliberately not reported:
Whether your rules express what you want. That is a judgement about intent and this server does not have one.
Shadowing that needs a wildcard solver. An allow rule is only called unreachable when the blocking rule is a prefix pattern that provably covers it. Anything subtler is left alone rather than guessed at, so this under-reports on purpose.
A verdict for a hypothetical command. See below.
It does not simulate your client's decision. There is no "would git push be allowed" tool, and that is a design choice: Claude Code's built-in read-only command set, wrapper stripping (timeout, nice, xargs…), compound-command splitting, sandbox state and PreToolUse hook results all participate in the real answer. A static verdict would be confidently wrong often enough to be worth less than no answer. Use /permissions in your client for the live view; use this to understand why it says what it says.
Command-line flags are invisible. --allowedTools, --disallowedTools, --permission-mode and --settings sit between managed policy and local settings, and they are not on disk.
Session rules added through /permissions land in files this server reads, but rules added for one session only do not.
It reports; it does not fix. Nothing is edited, and no finding is ever a recommendation to delete a rule. Where the docs give a corrected form, it is quoted; where they don't, the finding stops at the observation.
~/.claude/settings.local.json is reported but not ranked. It exists and Claude Code writes to it; the published precedence table lists four scopes and does not include it. This server refuses to invent its position.
Claude Code's schema is the model. Other clients with their own permission systems are not parsed.
It never reads git history, and it does not tell you who added a rule or when. git log -p .claude/settings.json does that better.
No child processes. No shell. No network. No writes. The only Node APIs used are node:fs reads, node:path and node:os. There is no child_process import anywhere in the source, so nothing in a settings file can be executed by reading it — including the hook commands and apiKeyHelper scripts it reports on.
env values are never read — only names. Settings files are one of the most common places for a plaintext API key, and a tool that pasted one into a context window would be worse than the problem it solves. The same applies to apiKeyHelper: presence is reported, the script is neither read nor run.
Settings-authored strings are fenced and labelled. Rule text and hook commands have to be shown to be useful. They are emitted inside inline code spans with backticks neutralised, pipes escaped and newlines flattened, so a crafted string cannot break out of the span or out of a markdown table, and each block carries a standing note that the quoted text is data from a file, not instructions.
dir is the one model-controlled path, and it is bounded by construction: resolved, real-pathed, and required to be an existing directory. From there only fixed filenames are read — .claude/settings.json, .claude/settings.local.json, the user config file, the platform's managed-policy path. No globbing, no traversal, no arbitrary file reads.
Bounded work: a 2 MB ceiling per file, a capped walk when looking for the project root, and files that fail to parse are reported as unparsed rather than partially guessed at.
Findings are conservative by construction. Every check is anchored to documented behaviour; anything that would need a judgement call about intent is not reported at all. For a tool people use to decide whether a guard rail is real, under-reporting is the correct failure mode.
Built by Shift The Culture — we run a one-person company on AI agents and ship the tooling we needed ourselves. This server is free and MIT-licensed, no strings.
It has three siblings, all also free and MIT:
whats-running-mcp — what is actually running on the box right now, instead of what an old transcript claims.
whats-loaded-mcp — what is eating your context window before you type: skill descriptions, memory files and their imports.
whats-inherited-mcp — what a checkout you did not write tells your agent to do: instruction files, hooks, and the MCP servers it declares.
The rest of that tooling is paid:
Agent Fleet Ops Kit ($29) — the other failure modes of running three or four agents on one box: two sessions editing the same checkout, a dev server nobody owns (so the agent tests a different app than it edits), and MCP servers leaked from crashed sessions that hold ports and RAM for weeks. Prefer PayPal? Same kit on Payhip.
Agent Reliability Kit ($29) — a Stop hook and two CLIs that block a turn when an agent claims "done" against a repo, URL, or build that was never actually checked. Prefer PayPal? Same kit on Payhip.
The server above stays free and MIT either way — it has no upsell in it, no telemetry, and no dependency on the paid kits.
This server is MIT and stays MIT. There is no pro edition, no telemetry, and nothing held back from the free build. Sponsorship is how the maintenance gets paid for without any of that changing.
No sponsors yet — the first slot is open. Company sponsors get their name or logo in this section, in the three sibling servers, and on the sponsor page. Tiers, exactly what the placement is, and what it explicitly does not buy: https://shifttheculture.media/sponsor
Individuals: https://paypal.me/ShiftTheCultureLLC — any amount, no perks, no tier.
MIT © Zachary Pampu
Every settings file that can contribute permission rules, in documented precedence order, with whether it exists, whether it parsed, how many rules it carries, and what a leading / in its path rules anchors to. Use when a rule is not taking effect, when you cannot tell which file granted something, or to confirm a managed policy is or is not present.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the project directory whose permissions you want. Defaults to the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what the tool reports (existence, parsed status, rule count, path anchor meaning) and that it lists files in precedence order. It doesn't explicitly state read-only, but the informational nature is evident. It adds useful behavioral context beyond a generic list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's output and scope, the second gives usage guidance. No fluff, front-loaded with core functionality, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema, the description fully enumerates what the tool returns (existence, parse status, rule count, path anchor meaning) and covers precedence order and use cases. It is complete for a single-parameter listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter 'dir', including its meaning and default. The tool description adds no additional parameter detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as enumerating every settings file that can contribute permission rules, in documented precedence order, with specific details per file (existence, parse status, rule count, path anchor semantics). It distinguishes itself from siblings by stating use cases like 'when a rule is not taking effect' or 'when you cannot tell which file granted something'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Use when a rule is not taking effect, when you cannot tell which file granted something, or to confirm a managed policy is or is not present.' It lacks named alternatives or explicit 'when not to use', but the guidance is clear and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permission rules whose documented behaviour differs from their apparent intent: rules Claude Code accepts and never consults, /path rules in user settings that anchor at the config directory rather than your project, wildcards without a word boundary, allow rules on commands that run other commands, and allow rules a deny or ask rule reaches first. Each finding cites the documented behaviour. Use before trusting a guard rail you wrote a while ago.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the project directory whose permissions you want. Defaults to the server's working directory. | |
| kind | No | Restrict to one category of finding. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details multiple behavioral aspects of the tool: it surfaces rules that are ignored, misanchored, over-broad, or shadowed, and each finding includes documented behavior. It does not explicitly state that it is read-only, but the analytical nature is evident. This is above minimum but could say more about outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and packed with useful detail, but the first sentence is quite long and lists many edge cases. It is still concise and every part contributes to understanding the tool's purpose, though a more front-loaded verb would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the results look like. It only says 'Each finding cites the documented behaviour,' which gives a hint but not the complete shape of the output. Given the tool's diagnostic nature and the rich input schema, the description is adequate but leaves room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has full descriptions for both 'dir' (absolute path, default working directory) and 'kind' (enum with five categories). The description does not add any additional parameter-specific details, so it relies entirely on the schema. Baseline of 3 applies since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's scope: it identifies permission rules whose documented behavior differs from their apparent intent. It enumerates specific categories (inert, misreads, wider, shadowed) which makes the purpose concrete, but it lacks an explicit verb like 'find' or 'list,' so it's slightly less direct than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives concrete guidance: 'Use before trusting a guard rail you wrote a while ago.' This indicates when to use the tool, but it does not explicitly mention alternative sibling tools or when not to use it. Still, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The parts of the configuration that let a tool call go through without a human: the winning defaultMode, blanket allow rules, extra directories granted, whether bypass and auto modes are disabled, and hook commands — which run on agent events without a permission prompt of their own. Use before leaving an agent running unattended, or when reviewing what a repo's settings would do on your machine.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the project directory whose permissions you want. Defaults to the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output content (defaultMode, allow rules, directories, bypass/auto disabled, hook commands) and notes hook commands run without a permission prompt. It does not explicitly state side-effect-free or read-only, but the nature of the config inspection implies safety. This adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool's core purpose, followed by usage guidance. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description provides a good list of what the result contains. It also ties into the intended scenario (unattended agents) and repository review, making it sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter 'dir' with a clear explanation. The tool description does not add any parameter-specific detail beyond that, but with 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: exposing configuration elements that allow tool calls to proceed without human supervision, listing specific components. This distinguishes it from sibling tools like whats_allowed or permission_sources by focusing on the 'unattended' operation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage contexts: 'Use before leaving an agent running unattended, or when reviewing what a repo's settings would do on your machine.' However, it does not explicitly contrast with alternatives, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. One-call summary of the permission configuration in force for a directory: which settings files contribute, how many allow/ask/deny rules each carries, the winning defaultMode, blanket allows, hooks wired to tool use, and how many rules do not do what they look like they do. Use at session start, before an unattended run, or when a prompt appeared that you did not expect.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the project directory whose permissions you want. Defaults to the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description takes on the full burden of behavioral context. It discloses that the tool returns a summary containing specific details, including a note about rules that do not behave as they appear. It does not explicitly state that the tool is read-only, but the nature of a summary implies no side effects. This is adequate transparency for a simple informational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, with two sentences. The first sentence front-loads the tool's purpose and lists its output contents in a structured list, while the second provides precise usage guidance. Every phrase contributes to understanding, with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description sufficiently explains what the tool returns and when to use it. It covers the key aspects of the tool's functionality, though it does not explicitly describe the output format. However, the list of contents is enough for an agent to understand the tool's role within the sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter 'dir', including a default. The tool description also mentions 'directory', reinforcing the schema. Since the schema already documents the parameter meaning, the description adds no additional semantic value beyond what is present in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a one-call summary of the permission configuration for a directory, enumerating specific elements such as contributing settings files, allow/ask/deny rule counts, defaultMode, blanket allows, hooks, and rule mismatches. This distinguishes it from siblings like permission_sources and rule_findings, which are likely more detailed or narrow in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: at session start, before an unattended run, or when an unexpected prompt appears. This provides clear context, but it does not mention when not to use it or explicitly name alternatives, though 'Start here' implies it is the entry point to the permission investigation process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1permission_sourcesrule_findingsunattended_surfacewhats_allowedScored across 4 tools
Each tool addresses a distinct aspect of permission configuration: overall summary, file sources, behavioral anomalies, and unattended execution pathways. There is no functional overlap between the four tools; their purposes are clearly separated and easy to distinguish.
All four tool names follow the same snake_case convention and are descriptive noun phrases that clearly reflect their output (e.g., permission_sources, rule_findings). The naming is consistent across the entire set, with no mixed conventions or ambiguous verbs.
With only four tools, the server is tightly focused on its purpose of analyzing permission configuration. Each tool covers a necessary dimension of the domain, and the count is well within the ideal range for a specialized MCP server.
The tool set provides comprehensive coverage for inspecting and understanding permission configuration: a starting summary, source file inventory, anomaly detection, and unattended execution risk. For its diagnostic scope, there are no obvious missing operations or dead ends.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Permission boundary receipts for ChatGPT agents.
Git-native policy layer for AI agents: check_action verdicts against rules approved via PR.
Runtime permission, approval, and audit layer for AI agent tool execution.
