The whats-inherited-mcp server enumerates everything in a code checkout that is addressed to an AI agent — instruction files, hooks, declared MCP servers, and shipped agent extensions — so you can review the agent-facing surface of code you clone or PRs that touch agent config.
inherited_summary — Get a headline count of all agent-targeted items in a directory: instruction files, hook commands, declared MCP servers, and skills/commands/subagents. The recommended starting point before working in an unfamiliar repo or reviewing a PR that touches agent config.
instruction_files — List every instruction file (e.g., CLAUDE.md, AGENTS.md, .cursorrules) including nested ones deep in subdirectories, with size, estimated token cost, and what each @import line pulls in (including imports that resolve outside the repo). File contents are never returned — you open the paths yourself.
auto_run_commands — Show hook commands declared in .claude/settings.json / settings.local.json: the command, its trigger (tool use, session start, prompt submit), and whether the referenced script lives inside the repo, outside it, or is missing.
declared_mcp_servers — List MCP servers the repo declares (.mcp.json and equivalents): launch command, whether it fetches remote code from a package registry at start time, filesystem paths granted outside the checkout, and the names of environment variables it expects (values are never read).
agent_extensions — Identify skills, slash commands, subagent definitions, and plugin markers shipped in the checkout's .claude/ or .agents/ directories (root, or 1–2 levels deep for monorepos), with counts, names, and sizes — never file contents.
All tools take an optional dir argument (absolute path); when omitted, they fall back to WI_DEFAULT_ROOT if set, otherwise the server's working directory. Conservative by design: no shell, no child processes, no network, no writes; file contents are never emitted, env var values are never read, and output is fenced to prevent injection. Reports what files declare, not what your client will actually do, and handles edge cases like symlinks, deduplication by real path, and truncation on large monorepos.
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-inherited-mcp What does this repo tell my agent to do?"
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 review the code you clone. Almost nobody reviews the part of it that talks to your agent. An MCP server that enumerates everything in a checkout addressed to an AI agent rather than to you: instruction files, hook commands wired to agent events, MCP servers the repo declares, and the skills and subagents it ships.
git diff shows you code, and you read code. It also shows you three added lines in a CLAUDE.md, and you skim those, because they look like documentation. They are not documentation — they are instructions your model will follow.
The surface is bigger than most people picture. A directory you cloned can carry:
CLAUDE.md / AGENTS.md / .cursorrules — loaded into context and treated as instructions, including nested copies deep in the tree that only apply when the agent works in that subdirectory
hook commands in .claude/settings.json — shell wired to fire on tool use, session start, or prompt submit
.mcp.json — MCP servers the repo asks to add, often launched with npx -y <package>, which means the code that runs is downloaded at start time and is not the code you reviewed
.claude/skills, .claude/commands, .claude/agents — capabilities the repo hands the agent
Nothing collects that in one place. This does.
Run against a checkout of langfuse/langfuse at 7d2afa4 — an ordinary, reputable open-source repo, picked precisely because there is nothing wrong with it:
# Inherited agent surface
**12 item(s) in this checkout are addressed to an agent, not to you.**
| Surface | Count | Detail |
|-------------------------------|------:|--------------------------------------------------------------|
| Instruction files | 12 | ~41,848 est. tokens, 5,593 lines your agent is told to follow |
| Hook commands | 0 | configured to run on agent events |
| MCP servers declared | 0 | 0 fetch code from a registry at launch |
| Skills / commands / subagents | 33 extensions (196 files) | shipped under `.agents/`, available to the agent |
## Worth a look
- 11 instruction file(s) are **not at the repo root** — they apply when the agent
works in those subdirectories and are easy to miss in review.and instruction_files adds:
> Counted once, reachable under more than one name (symlinks):
> - `AGENTS.md` ← also `.agents/AGENTS.md`, `CLAUDE.md`Five and a half thousand lines of standing instruction, most of it in files you would never open, in a repo nobody has any reason to distrust. That is the point: the number is large even in the benign case, which is exactly why an unusual entry in it goes unnoticed.
Related MCP server: claude-init
Tool | What it answers |
| The headline: everything in this checkout addressed to an agent. Start here |
| Every |
| Hook commands the checkout wires to agent events, and whether the script each references is inside the repo, outside it, or missing |
| MCP servers the repo declares, which of them fetch code at launch, and filesystem paths they are granted outside the checkout |
| Skills, slash commands and subagents the repo ships |
Every tool takes an optional dir. When it is omitted the server falls back to
WI_DEFAULT_ROOT if that is set, and otherwise to its working directory.
Claude Desktop (one-click, no terminal): download the latest whats-inherited-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-inherited -- npx -y whats-inherited-mcpOr in any MCP client config:
{
"mcpServers": {
"whats-inherited": {
"command": "npx",
"args": ["-y", "whats-inherited-mcp"]
}
}
}git clone https://github.com/stcmain/whats-inherited-mcp.git
cd whats-inherited-mcp
npm install && npm run build
# then point your client at node /path/to/whats-inherited-mcp/dist/index.jsPublished as whats-inherited-mcp on npm and as
io.github.stcmain/whats-inherited-mcp in the MCP Registry.
One optional setting, and it takes no credentials.
Variable | Default | Meaning |
| the server's working directory | Directory to inspect when a tool is called without a |
Every tool accepts an explicit dir, which always wins. WI_DEFAULT_ROOT only
changes the fallback, and it is worth setting when a desktop client launches the
server: the process then inherits that client's working directory, which is
rarely the checkout you meant to inspect.
{
"mcpServers": {
"whats-inherited": {
"command": "npx",
"args": ["-y", "whats-inherited-mcp"],
"env": { "WI_DEFAULT_ROOT": "/path/to/the/checkout" }
}
}
}Inflating this in the alarming direction would be easy and would make the tool useless, so the accounting is deliberately conservative:
It does not detect malicious content. There is no heuristic scanner, no "suspicious phrase" regex, no risk score. Those produce confident false positives on ordinary repos and miss anything written with care. This server tells you where to look; you do the reading.
Files are counted once. A repo can expose one file under several names — CLAUDE.md → AGENTS.md → .agents/AGENTS.md is a real pattern in the wild. Entries are deduplicated by resolved real path and the aliases are listed, rather than counting the same content three times.
.claude/ is not double-counted. A skill's own CLAUDE.md is reported as a skill, not also as a project instruction file.
"No path token identified" is not a safety claim. When a hook command has no filesystem path this server can confidently extract, it says so and stops. That is a stated gap in the analysis, not a verdict.
Import detection is conservative. Fenced code blocks are stripped first, and an unrooted @token only counts when it names a document — so @scope/pkg and @mentions stay out of the number.
It reports; it does not judge, and it does not fix. Nothing is edited, quarantined or scored. Every item it lists is normal in a legitimate repo.
Whether your client actually runs project hooks is your client's business. Clients differ, and they prompt differently and change between versions. This server reports what the files declare, not what your client will do with them.
Token counts are estimates (~4 chars/token). Treat them as a ranking and a rough scale, not as billing. Anthropic's tokenizer is not public, so nothing local can do better.
Claude Code layout is the model. Cursor, Windsurf, Cline and Copilot instruction files are recognised, but hook and MCP parsing follows the Claude Code schema.
Very large monorepos are truncated. The walk is depth- and entry-capped; when the cap is hit the output says so and marks the results partial rather than quietly under-reporting.
It never reads git history. It describes the working tree as it is on disk right now, not what a diff changed.
Symlinked directories are not followed (loop risk). Symlinked files are.
This server's whole job is to look at content that may be hostile, so the design assumes it is.
It must not become the injection vector it reports on. The body of an instruction file is never returned — only metadata, paths and structured fields parsed out of known JSON config keys. Pasting a repo's CLAUDE.md into your context to tell you the repo might contain something bad would be self-defeating.
Repo-authored strings are fenced and labelled. Hook commands and MCP launch lines 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 every block carries a standing note that the quoted text is data from the checkout, not instructions.
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 scanned repo can be executed by scanning it.
dir is the one model-controlled path, and it is bounded by construction: it is resolved, real-pathed and required to be an existing directory. Because file bodies are never emitted, pointing it somewhere sensitive discloses filenames and sizes, never contents — and it cannot write, execute or transmit anything.
Environment variable values are never read — only names. .mcp.json is a place people leave API keys in plaintext.
Bounded work: depth cap, entry cap, file-size ceiling, and no symlinked-directory traversal.
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-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
Skills, slash commands, subagent definitions and plugin markers shipped inside the checkout's .claude/ or .agents/ directories (root, or one to two levels down — monorepos put them per package). These become available to an agent working in this directory. Counts distinct extensions and the markdown files they carry. Names and sizes only — contents are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the checkout to inspect. Defaults to WI_DEFAULT_ROOT if set, otherwise 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 transparency burden and does well by disclosing key behaviors: it searches root or one/two levels down, counts distinct extensions and markdown files, and explicitly states 'contents are never returned.' It omits details like output format or error behavior, but the essential behavioral facts are present.
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 with useful scoping details, though the first sentence is long and packs the action verb later in the paragraph ('Counts...'). There is minimal redundancy, but it could be slightly more front-loaded, so it earns a 4 rather than a 5.
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?
Although there is no output schema, the description compensates by stating what is returned (counts, names, and sizes) and where it looks. It does not address edge cases like a missing directory or symlink behavior, but for a simple read-only inspection tool the essential context is covered.
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 fully documents the single optional `dir` parameter with 100% coverage, including its default behavior. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score 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 uses a specific action ('Counts distinct extensions and the markdown files they carry') and clearly identifies the resource (`.claude/` or `.agents/` directories). It also distinguishes itself from sibling tools by scoping to skills, slash commands, subagents, and plugin markers, and explicitly states the output limitation ('Names and sizes only').
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?
Provides clear context on when to use the tool: it inspects agent extensions shipped in the checkout and handles monorepo layouts ('one to two levels down'). However, it never explicitly contrasts with sibling tools like instruction_files or declared_mcp_servers, nor states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hook commands declared in the checkout's .claude/settings.json and settings.local.json — shell commands wired to fire on agent events such as tool use, session start or prompt submit. Shows the command, its trigger, and whether the script it references lives inside the repo, outside it, or is missing.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the checkout to inspect. Defaults to WI_DEFAULT_ROOT if set, otherwise 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 of disclosing behavior. It says 'Shows' and details the output, clearly implying a read-only inspection that does not execute hooks. However, it doesn't explicitly state that no commands are run or that no modifications occur, leaving a slight ambiguity.
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 an efficient two-sentence structure that front-loads the core purpose and then adds relevant detail. Every sentence earns its place with no filler.
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 listing tool, the description covers the source (settings files), the output (command, trigger, script location status), and the optional input (via schema). It lacks an explicit read-only statement but is otherwise complete for its complexity.
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 single 'dir' parameter is fully described in the schema (100% coverage) with defaults and meaning. The tool description adds no additional parameter semantics, so the baseline 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's purpose: it shows hook commands declared in the checkout's settings files, including the command, trigger, and script location. This is specific and distinct from sibling tools that inspect MCP servers, summaries, instruction files, and agent extensions.
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 usage when one wants to inspect configured hook commands, but it does not explicitly state when to use this over alternatives or provide exclusions. No mention of sibling tools or scenarios where this tool would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MCP servers declared by the checkout (.mcp.json and equivalents) — the launch command, whether it fetches code from a package registry at start time, filesystem paths it is granted outside the repo, and the NAMES of environment variables it expects. Values are never read.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the checkout to inspect. Defaults to WI_DEFAULT_ROOT if set, otherwise the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: 'Values are never read', which is a strong privacy guarantee. It also clarifies the scope of information returned. Since no annotations are provided, this disclosure adds meaningful behavioral context, though it does not cover all potential behaviors (e.g., handling of missing .mcp.json files).
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 a single sentence that front-loads the core purpose and then provides a concise, structured list of details. Every phrase adds value, and there is no redundant or explanatory fluff.
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 read-only inspection tool with one optional parameter and no output schema, the description provides sufficient context about what information is available, including the privacy note. It could be more complete by explicitly stating that it returns a list of servers, but this is strongly implied by the phrasing.
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 provides a complete description for the single 'dir' parameter, including its default behavior. The tool description adds no additional parameter-level information, 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 returning information about MCP servers declared by the checkout, with a detailed list of what aspects are covered (launch command, package registry fetching, filesystem paths, environment variable names). However, it lacks an explicit verb like 'list' or 'inspect', making it slightly less actionable than ideal, though the title partially compensates.
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 usage is implied: an agent would use this when needing to know which MCP servers a checkout declares. However, there is no explicit 'when to use' guidance or reference to sibling tools (e.g., instruction_files) to differentiate use cases, so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. Headline count of everything in a directory that is addressed to an AI agent rather than to you: instruction files, hook commands wired to run automatically, MCP servers the repo declares, and skills/commands/subagents it ships. Use before working in a repo you did not write, or when reviewing a PR that touches agent config.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the checkout to inspect. Defaults to WI_DEFAULT_ROOT if set, otherwise the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly explains the tool returns a 'headline count' (not detailed content) and enumerates exactly what categories it covers. It does not explicitly state read-only behavior, but the nature of a count implies it, and all listed items are inspection targets.
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 'Start here,' and every word adds value. It concisely lists the included categories and provides usage context without any fluff.
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 summary tool, the description fully covers its scope, purpose, and when to use it. Given the simple one-parameter schema and no output schema, it provides sufficient context for an agent to select and invoke the tool correctly. The sibling tools are implicitly referenced by the categories listed.
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 provides 100% coverage with a clear description of the 'dir' parameter. The tool description does not add additional meaning beyond the schema, so it meets the baseline but does not go beyond it.
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 a 'headline count' of agent-related items in a directory, listing specific categories (instruction files, hook commands, MCP servers, etc.). This is a specific verb+resource and distinguishes it from sibling tools that likely drill into individual categories.
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?
Explicit guidance is given on when to use: 'Use before working in a repo you did not write, or when reviewing a PR that touches agent config.' The phrase 'Start here' also signals this is the intended entry point before using more specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every CLAUDE.md, AGENTS.md, .cursorrules and equivalent in the checkout, with size, estimated token cost, and what each one's @import lines pull in — including imports that resolve outside the repo. File contents are never returned; open the paths yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Absolute path to the checkout to inspect. Defaults to WI_DEFAULT_ROOT if set, otherwise the server's working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses a critical behavioral constraint: file contents are never returned, so the agent must open paths itself. It also mentions imports resolving outside the repo, adding context beyond simple listing. This is strong disclosure for a read-only metadata 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?
Two sentences: the first enumerates what the tool returns, the second states a key limitation. Every word contributes, and the structure is well 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?
With no output schema, the description must convey return values, and it does: files with size, estimated token cost, and @import lines. It also tells the agent that contents are not included. This is complete for a simple, 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 fully describes the only parameter 'dir' with default behavior, achieving 100% coverage. The description adds no additional parameter detail, so it meets the baseline but doesn't exceed it.
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's output: all instruction files (CLAUDE.md, AGENTS.md, .cursorrules, etc.) with size, token cost, and @import details. This is specific and distinct from sibling tools which cover MCP servers, summaries, commands, and extensions.
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 purpose is evident: use when you need to know which instruction files exist and their imports/costs. It doesn't explicitly state exclusions or alternatives, but the sibling tools are semantically different, making the use case clear without further guidance.
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.6agent_extensionsauto_run_commandsdeclared_mcp_serversinherited_summaryinstruction_filesScored across 5 tools
Each tool targets a distinct category of AI-facing repo content: MCP servers, instruction files, hook commands, agent extensions, and a summary count. There is no overlap in what they return.
All tool names follow a consistent lower_snake_case noun-phrase pattern describing the resource they expose. No verb confusion or mixed conventions.
Five tools is well-scoped for inspecting AI-related repository configuration. Each tool earns its place without redundancy or excessive granularity.
The set covers the major categories of AI-agent-related configuration: declared MCP servers, instruction files, auto-run hooks, agent extensions, and a summary. No obvious missing operation for the stated purpose.
Search, fetch (with provenance), scan, and convert AI instruction files for agents.
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Agent-native catalogue of Baseframe Labs dev tools and MCP servers.
