{
"answer": "whats-loaded-mcp is a read-only MCP server that audits what's silently consuming your AI agent's context window before you even start typing — skills, memory files (including hidden @import chains), and configured MCP servers — so you can find and fix context bloat.\n\nAvailable tools:\n\n- context_budget — Your starting point. Shows total pre-session token consumption broken down by source (skills, memory files, MCP servers), revealing where the biggest costs live.\n- skill_costs — Ranks skills by the token cost of their always-loaded name + description, with optional name filtering and a configurable result limit (1–200). Pinpoints which skills yield the biggest savings if trimmed.\n- duplicate_skills — Finds skills installed more than once. Compares by hash to separate byte-identical duplicates (safe to remove — pure waste) from same-name-different-content copies (flagged for review to avoid losing work).\n- memory_files — Reports the true size of CLAUDE.md / AGENTS.md files, including everything pulled in via @import lines. Shows the import graph and sizes only — never file contents — to protect privacy.\n- mcp_servers — Enumerates every MCP server configured across all agent clients (Claude Code, Claude Desktop, Cursor, Windsurf, VS Code) and which config file declares each. Only environment variable names are emitted, never values.\n\nSafety guarantees: read-only (reports only, never edits), conservative accounting (only always-loaded descriptions count; disabled plugins, cached duplicates, and marketplace sources are excluded), no child processes, no network calls, no model-controlled file paths, and no reading of memory file contents or environment variable values into reports."
}
Your context window is already half spent before you type. An MCP server that shows what is consuming it — every skill description, every memory file and its hidden @imports, every configured MCP server — ranked by cost, with duplicates called out.
Skills are cheap to install and permanently expensive to keep. A skill's name and description go into the system prompt of every session, forever — only the body is loaded on demand. Install a few hundred and you've quietly mortgaged half your window before the first message.
Nothing surfaces this. You notice it as sessions that compact sooner than they used to, and you have no idea which of the things you installed six months ago is responsible.
On the machine this was written on:
# Context budget — cost before you type a single character
**~95,316 estimated tokens always loaded.**
For scale: ~47.7% of a 200K window, ~9.5% of a 1M window.
| Source | Count | Est. tokens |
|----------------------------------------------|------:|-------------:|
| Skill descriptions | 1,767 | 92,884 |
| Memory files (CLAUDE.md/AGENTS.md + imports) | 3 | 2,432 |
| MCP servers configured | 10 | not measured |
| **Total measurable** | | **95,316** |
> **79 duplicate skill names** are costing ~9,435 tokens.79 names were installed more than once — the same skill picked up from several sources, like agent-browser appearing three times from three authors. But a shared name does not always mean a redundant copy: on that install only 34 groups were byte-identical (~1,523 tokens genuinely recoverable), while 45 shared a name and differed in content — different work wearing the same label, where deleting a copy loses something. duplicate_skills compares content hashes and reports those two groups separately, so the cleanup advice is safe to act on rather than merely impressive.
Related MCP server: openclaw-cost-tracker-mcp
Tool | What it answers |
| The headline: how much is loaded before you type, split by source. Start here |
| Skills ranked by token cost, so you trim where it actually pays |
| The same skill installed more than once — usually pure waste |
|
|
| Every MCP server configured across your clients, and which config declares it |
Claude Desktop (one-click, no terminal): download the latest whats-loaded-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-loaded -- npx -y whats-loaded-mcpOr in any MCP client config:
{
"mcpServers": {
"whats-loaded": {
"command": "npx",
"args": ["-y", "whats-loaded-mcp"]
}
}
}git clone https://github.com/stcmain/whats-loaded-mcp.git
cd whats-loaded-mcp
npm install && npm run build
# then point your client at node /path/to/whats-loaded-mcp/dist/index.jsPublished as whats-loaded-mcp on npm and as
io.github.stcmain/whats-loaded-mcp in the MCP Registry.
One optional setting, and it takes no credentials.
Variable | Default | Meaning |
| the server's working directory | Directory treated as "the project" for project-scoped skills, memory files and |
Personal and plugin scopes are read from ~/.claude either way. Setting this is
worth it when a desktop client launches the server: the process inherits that
client's working directory, which is rarely the project you are asking about.
{
"mcpServers": {
"whats-loaded": {
"command": "npx",
"args": ["-y", "whats-loaded-mcp"],
"env": { "WL_PROJECT_ROOT": "/path/to/the/project" }
}
}
}Getting this wrong in the flattering direction would be easy, so the accounting is deliberately conservative:
Skill descriptions only. name + description is what loads at startup. The body of a SKILL.md is fetched on demand and is not counted, even though it is 100× larger.
Enabled plugins only. Skills belonging to disabled plugins sit on disk costing nothing, and are reported separately rather than folded into the total.
One version per plugin. The plugin cache keeps several content-hash copies of the same plugin; only the live one is counted. Counting them all would inflate the total and invent duplicates you cannot act on.
marketplaces/ is never counted. That tree is a git checkout of marketplace source, not installed content.
Token counts are estimates (~4 chars/token). Real counts depend on the tokenizer; prose runs lighter, code and CJK run denser. Treat the numbers as a ranking and a rough scale, not as billing. Anthropic's tokenizer is not public, so nothing local can do better than an estimate.
MCP tool definitions are not measured. They can be a large share of your context, but measuring them means launching every server and enumerating its tools. This server does not launch anything, so it reports the server count and says so rather than guessing.
JSON configs only. TOML-based clients (Codex config.toml) are not parsed.
Client-specific. Built around the Claude Code layout (~/.claude). The MCP inventory reads Claude Desktop, Cursor, Windsurf and VS Code configs too, but skill accounting is Claude Code's model.
It reports; it does not edit. Nothing is deleted, disabled or rewritten. Acting on the findings is your call.
This server's output goes straight into a model's context, so the interesting risk is not what it does to your machine — it is what it hands to the model.
No child processes. No network. It only reads files. There is no exec, no shell, and no outbound connection anywhere in the codebase.
No model input ever becomes a path. Every path is derived from homedir() or cwd(). The only model-controlled parameters are a clamped integer and a substring matched in memory against names already collected. Path traversal is not possible because there is no path construction to traverse.
Memory file contents are never read into the report. CLAUDE.md routinely contains private operational detail. This server reports size and the import graph, never a line of content.
MCP environment values are never read. Config files are where people leave API keys in plaintext. Only variable names are emitted — never values, not even masked.
Skill names and descriptions are emitted, which is a deliberate exception: they are already in the model's context by definition, so reporting them discloses nothing new.
Bounded work: depth-capped directory walks, symlink-loop protection via realpath, and a file size ceiling.
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-inherited-mcp — what a checkout you did not write tells your agent to do: instruction files, hooks, and the MCP servers it declares.
whats-allowed-mcp — what your agent can do without asking you: merged permission rules, which settings file wins, and the rules your client accepts and then ignores.
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 two 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
The headline answer: how much of the context window is consumed before the conversation starts, broken down by source (skills, memory files, MCP servers). Use this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool is a read-only style overview but does not disclose return format, pagination, or any side effects. This is adequate for a simple query tool but not highly detailed.
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 short sentences, front-loaded with the key answer and a direct usage directive. Every word earns its place with no redundancy.
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 zero-parameter tool with no output schema, the description covers the key aspects: what it computes, by which breakdown, and when to use it. It is slightly thin on what precisely the numbers mean, but sufficient for selection and invocation.
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 tool has zero parameters, and schema coverage is 100%, so there is nothing to explain. The description adds meaning by clarifying the output's breakdown by source, matching the 0-param baseline of 4.
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 provides the headline context budget consumption before conversation starts, broken down by source. This is specific and distinct from sibling tools that drill into details.
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?
Explicitly advises 'Use this first', giving clear ordering guidance relative to sibling tools. It does not state when not to use it, but the directive is strong and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Skills whose name appears more than once (same skill installed from several sources). Every copy pays full description cost in every session. Copies are compared by content hash: identical copies are safe to remove, same-name copies that DIFFER are flagged for review because deleting one would lose work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It explains the comparison mechanism (content hash), the outcome categories (identical vs. differing copies), and the recommended actions (safe to remove vs. flagged for review). This gives the agent a complete understanding of the tool's behavior and side effects.
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, front-loaded with the definition of what the tool handles, followed by crucial behavioral details. Every word earns its place; no filler or redundancy exists.
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 zero-parameter tool with no output schema, the description adequately covers the core behavior and implications. It explains the duplication source, cost impact, comparison method, and recommended actions. A brief mention of the return format (e.g., a list) would make it fully complete, but the description already provides sufficient context for correct use.
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 tool has zero parameters, and the schema is empty, so there are no parameter semantics to explain. The baseline for no parameters is 4, and the description correctly focuses on behavior rather than input.
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: 'Skills whose name appears more than once' identifies the resource and intent. It distinguishes from sibling tools by focusing specifically on duplicate skills, not budget, costs, memory, or servers. The lack of an explicit verb (e.g., 'list' or 'report') prevents 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 description provides clear context for when to use this tool: to identify duplicate skills that incur full description cost. It explains the safety implications of removal ('identical copies are safe to remove') and when review is needed, giving the agent actionable guidance. It does not explicitly compare against alternatives, but sibling tools are topically distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every MCP server configured across the agent clients on this machine, and which config declares it — useful for spotting servers you forgot you installed. Environment variable NAMES only; values are never read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It explicitly discloses that only environment variable NAMES are read and values are never read, providing a non-obvious privacy/safety guarantee. It also clarifies that the output includes which config declares each server, which is useful 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?
The description is two concise sentences. The first sentence states the core purpose, and the second adds a critical detail about environment variable values. There is no fluff, and the information is front-loaded.
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 is simple: no parameters and no output schema. The description adequately conveys what the tool returns (servers and their declaring configs) and includes a safety note. It does not explicitly describe the return format (e.g., list vs table), but for an inventory tool this is enough. Slightly more detail about the source of the config data would have made it a 5.
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 tool has zero parameters and an empty input schema, so no parameter documentation is needed. Per the rubric, 0 parameters earns a baseline 4. There is no missing parameter information to penalize.
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 an inventory of every MCP server configured across agent clients on the machine, plus which config declares each server. This specific verb-like framing ('Every MCP server configured...') distinguishes it from sibling tools like context_budget or skill_costs, and matches the title 'MCP server inventory'.
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 a clear use case: 'useful for spotting servers you forgot you installed.' This gives the agent context for when to use the tool, though it does not explicitly mention when not to use it or name alternative tools. That matches a 4: clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CLAUDE.md / AGENTS.md files that load in full every session, including files pulled in by @import lines — the cost that hides behind a small-looking parent file. Reports sizes and the import graph only, never file contents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool never returns file contents, which is a significant behavioral guarantee. It explains the scope (all memory files loaded every session) and that it only reports sizes and import graph, adding context beyond safe operation.
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 well-structured sentences. The first sets the context (what files and the hidden cost), the second clearly states what the tool reports and what it excludes. Every clause adds value, no redundancy.
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 zero-parameter tool with no output schema, the description covers the essential behavior: the subject files, the load mechanism, the output (sizes and import graph), and the explicit exclusion of contents. It is sufficiently complete for an agent to select and invoke it correctly.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; it appropriately focuses on output and scope.
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 reports sizes and import graph of memory files, with a specific verb ('Reports') and resource (CLAUDE.md/AGENTS.md and imports). It distinguishes itself from sibling tools by focusing on memory file loading costs.
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 implies when to use it: to understand the hidden cost of memory files (including @import pull-ins). It explicitly states what it does not do (never file contents), which provides a clear boundary, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Skills ranked by how many tokens their always-loaded description costs. The top of this list is where trimming pays off most.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many skills to return | |
| filter | No | Only include skills whose name contains this substring |
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 a key trait: the described costs are for always-loaded descriptions, not optional invocations. It also implies read-only behavior. However, it doesn't detail output structure or whether the list is sorted descending (though 'top' implies it). Reasonable but not exhaustive.
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 concise sentences, front-loaded with the main purpose and followed by actionable insight. No wasted words; every phrase 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?
For a simple query tool with no output schema, the description sufficiently explains what it returns (ranked skills with token costs). It does not explicitly state whether token counts are included or the sort order, but 'top of this list' implies descending order. Most users would find it complete enough.
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?
Schema description coverage is 100%, with both parameters (limit, filter) having descriptions in the schema. The tool description adds no parameter-specific information, so it relies on the schema. Baseline 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 states the tool ranks skills by the token cost of their always-loaded descriptions, with a specific verb ('ranked') and resource ('skills'). This distinguishes it from sibling tools like duplicate_skills (which finds duplicates) and context_budget (which measures overall budget).
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 explicitly says 'The top of this list is where trimming pays off most,' which gives clear guidance on when to use the tool (to identify costly skills for trimming). While it doesn't name alternatives or exclusions, the use case is strong and implied.
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.
skill_costs1 field changedInput schema / properties / filter / maxLengthAdded value: +100v0.2.5context_budgetduplicate_skillsmcp_serversmemory_filesskill_costsScored across 5 tools
Each tool has a clearly distinct purpose: context_budget provides the overview, while skill_costs, duplicate_skills, memory_files, and mcp_servers drill into specific sources of context consumption. The descriptions reinforce a natural hierarchy rather than overlapping functionality.
All tool names follow a consistent lowercase snake_case noun-phrase pattern: context_budget, skill_costs, duplicate_skills, memory_files, mcp_servers. There are no mixed conventions or vague verb clashes.
Five tools is well-scoped for the server's purpose: one summary tool and four detailed drill-down tools. Each tool earns its place and the set is neither bloated nor too thin.
The tool surface covers the stated domain completely: the headline context budget plus dedicated tools for skills, memory files, and MCP servers. The duplicate_skills tool adds useful lifecycle insight without leaving obvious gaps.
Signed security scores for what an AI agent runs and reads: skills, MCP servers, prompts, tokens.
Statically audits MCP tool surfaces for token cost, schema quality, and design issues.
Scan agent skills and MCP servers for malicious patterns before you load them
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.