How Anthropic Built a Plugin System That Doesn’t Require Programming
Hook
Most AI plugin systems require developers to write code, deploy infrastructure, and maintain APIs. Anthropic’s knowledge-work-plugins takes a radically different approach: plugins are just markdown files and JSON configs that Claude interprets on the fly—no build step, no servers, no deployment pipeline.
Context
LLMs like Claude are generalists by design, trained on broad internet-scale data to handle any query reasonably well. But knowledge workers don’t need “reasonable”—they need Claude to understand their CRM’s specific fields, their company’s approval workflows, and their industry’s terminology. The obvious solution is fine-tuning or RAG, but both require ML expertise and infrastructure. OpenAI’s GPTs attempted to democratize customization with a no-code builder, but they’re siloed to individual users and lack organizational versioning.
Anthropic’s knowledge-work-plugins repository addresses this gap with a file-based plugin architecture specifically for Claude Cowork and Claude Code. Instead of writing Python classes or deploying API endpoints, you create a folder structure with markdown files describing domain expertise (skills) and JSON files defining executable actions (commands). The entire plugin is just static files that Claude reads and interprets at runtime. It’s infrastructure-as-documentation taken to its logical extreme—if you can write a README, you can extend Claude’s capabilities.
Technical Insight
The plugin architecture revolves around three core concepts: manifests, skills, and commands, all tied together through the Model Context Protocol (MCP) for external integrations.
Every plugin starts with a .claude-plugin/plugin.json manifest that declares metadata and capabilities:
{
"name": "sales-assistant",
"version": "1.0.0",
"description": "Helps sales reps manage deals and forecast pipeline",
"skills": ["skills/crm-knowledge.md", "skills/sales-methodology.md"],
"commands": ["commands/update-deal", "commands/generate-forecast"],
"mcp_servers": ["salesforce", "gong"]
}Skills are markdown files in the skills/ directory that provide background knowledge Claude automatically incorporates into conversations. Unlike RAG chunks or vector embeddings, skills are human-readable documentation written in natural language. A CRM skill might explain your custom fields, deal stages, and qualification criteria—information Claude needs to interpret user requests correctly but shouldn’t require explicit invocation. The key insight here is that Claude’s context window is large enough (200K+ tokens) to include multiple skills simultaneously, eliminating the retrieval problem that plagues traditional RAG systems. You’re not searching for relevant context; you’re loading all context upfront.
Commands are the executable counterpart to skills—explicit actions users trigger with slash commands like /update-deal or /generate-forecast. Each command is a directory containing a command.json manifest and optional parameter schemas:
{
"name": "update-deal",
"description": "Update deal fields in Salesforce",
"parameters": {
"deal_id": {"type": "string", "required": true},
"stage": {"type": "string", "enum": ["Prospecting", "Qualification", "Proposal", "Negotiation", "Closed Won"]},
"amount": {"type": "number"},
"close_date": {"type": "string", "format": "date"}
},
"mcp_call": {
"server": "salesforce",
"method": "update_opportunity",
"arg_mapping": {
"id": "${deal_id}",
"StageName": "${stage}",
"Amount": "${amount}",
"CloseDate": "${close_date}"
}
}
}The mcp_call section is where the magic happens. MCP (Model Context Protocol) is Anthropic’s standardized interface for connecting Claude to external tools. Instead of writing bespoke API integration code in each plugin, you configure MCP server connections in the root .mcp.json file and reference them in commands. An MCP server is a long-running process that exposes methods Claude can invoke—think of it as a function-calling gateway to your enterprise tools.
The .mcp.json configuration defines available MCP servers and their authentication:
{
"mcpServers": {
"salesforce": {
"command": "npx",
"args": ["-y", "@anthropic-ai/mcp-server-salesforce"],
"env": {
"SALESFORCE_INSTANCE_URL": "${SALESFORCE_INSTANCE_URL}",
"SALESFORCE_ACCESS_TOKEN": "${SALESFORCE_ACCESS_TOKEN}"
}
},
"gong": {
"command": "python",
"args": ["-m", "mcp_server_gong"],
"env": {
"GONG_API_KEY": "${GONG_API_KEY}"
}
}
}
}This architecture is brilliant in its simplicity. Plugin authors don’t write integration code—they declare which MCP servers they need and map command parameters to server methods. The actual API calls, authentication, error handling, and retry logic live in the MCP server implementations, which can be shared across plugins and maintained independently. It’s dependency injection for AI capabilities.
The plugin discovery mechanism is equally straightforward. Claude Cowork scans directories for .claude-plugin/plugin.json manifests, loads referenced skills into its context window, and registers commands as available slash commands. There’s no registry, no versioning server, no publication process. To share a plugin with your team, you commit it to a Git repository and point your teammates to clone it into their ~/claude-plugins/ directory. Version control is just Git. Distribution is just file sharing.
What makes this approach viable is Claude’s instruction-following capability and massive context window. The entire plugin system relies on Claude correctly interpreting markdown documentation and JSON schemas without any fine-tuning or specialized training. When a user types /update-deal 006Qy000001 stage:Proposal amount:50000, Claude parses the command, validates parameters against the schema, performs the arg_mapping transformation, and executes the MCP call—all through prompt-based reasoning, not programmed logic. The plugin system is essentially a sophisticated prompting framework with standardized file conventions.
Gotcha
The most significant limitation is runtime dependency—plugins only work in Claude Cowork or Claude Code, not in standard Claude.ai conversations or API integrations. This isn’t a technical constraint but a product one. The plugin loading mechanism, MCP server lifecycle management, and command parsing are all features of these specific client applications. If you primarily use Claude through the web interface or API, this entire ecosystem is inaccessible. You’re betting on Anthropic’s desktop/editor products, not their core platform.
The MCP server ecosystem is still nascent. While Anthropic provides reference implementations for popular tools like Salesforce, Slack, and PostgreSQL, niche or proprietary systems require building custom MCP servers. That means writing actual code—typically in Python or TypeScript—to expose your tool’s API as MCP methods. The promise of no-code plugins evaporates when your critical workflow depends on a homegrown CRM or legacy ERP system. You’ll need developers to build and maintain MCP servers before non-technical users can author plugins against them.
Skill authoring lacks clear guidelines on scope and specificity. Should a sales skill document every Salesforce field or just custom ones? How much company-specific context is too much? The repository includes example plugins, but they’re intentionally generic—realistic organizational plugins would be far more detailed. There’s a tension between comprehensive documentation (which risks overwhelming Claude’s context) and terse summaries (which might miss critical nuances). Unlike code, where correctness is binary, markdown skills exist on a spectrum of usefulness that’s hard to evaluate without trial and error.
Verdict
Use if: You’re a Claude Cowork or Code user whose team works with mainstream tools that have MCP server implementations, and you want to encode company-specific workflows without hiring developers. The file-based approach makes plugin authoring accessible to technical product managers, solutions architects, or power users comfortable with JSON and markdown. It’s particularly valuable for organizations that need to distribute Claude customizations across teams while maintaining version control through Git. Skip if: You primarily use Claude through the web or API, work with highly specialized tools lacking MCP support, or need complex runtime logic that can’t be expressed through declarative configs. If your customization needs include stateful workflows, complex data transformations, or fine-grained access control, you’ll hit the ceiling of what file-based plugins can express. In those cases, traditional API integrations or LangChain-style agent frameworks offer more power at the cost of requiring actual programming.
