一个 MCP 配置条目。按需获取 150 多个专业智能体。无需手动设置。
你的 AI 助手是一个通才。有时你需要一位专家——游戏经济设计师、安全审计员、技术文档撰写者。此 MCP 服务器让你的助手能够即时访问 150 多个专家智能体模板。描述你的需求，它会找到合适的智能体并将其生成。
You: "Help me design a balanced game economy"
Claude: [searches -> finds Game Economy Designer -> spawns it -> expert response]模板在首次运行时会自动从 agency-agents 获取并保持更新。你无需进行任何操作。
你可以这样做。agency-agents 安装脚本会将所有 160 多个智能体文件直接复制到你的工具配置目录（例如 ~/.claude/agents/）。这确实有效——但每个智能体的名称和描述都会被加载到每次对话的上下文窗口中，无论你是否使用它们。
我们进行了测量：
方法 | 上下文成本 | 时间 |
已安装的智能体 ( | ~8,300 tokens | 每次对话，始终加载 |
MCP 服务器 (空闲) | ~55 tokens | 每次对话 |
MCP 服务器 (搜索中) | ~350 tokens | 仅当你搜索时 |
MCP 服务器 (使用智能体) | ~2,700 tokens | 仅当你生成一个时 (中位数) |
这使得基准上下文使用量减少了 150 倍。你获得了同样的 160 多个智能体，但只需为你实际使用的那个付费。
已安装的智能体 (8,300 tokens)： 我们运行了 agency-agents 安装脚本 (install.sh --tool claude-code)，将 162 个智能体文件复制到了 ~/.claude/agents/。然后打开一个新的 Claude Code 会话并运行 /context。Claude Code 报告“自定义智能体：8.3k tokens”——无论是否使用任何智能体，都会加载到每次对话中。
MCP 空闲 (55 tokens)： 改用 MCP 服务器配置后，/context 仅显示两个延迟工具名称 (agency_search, agency_browse) 以及系统提示词中的简短服务器描述。不会加载任何智能体数据。
MCP 搜索中 (350 tokens)： 通过对助手调用 ToolSearch 以解析 agency_search 和 agency_browse 工具时加载的完整 JSON 工具模式进行分词测量。使用 @anthropic-ai/tokenizer 进行计数。
MCP 使用智能体 (2,700 tokens)： 所有 145 个智能体文件的中位数 token 计数，使用 @anthropic-ai/tokenizer 测量。只有你实际使用的那个智能体文件会被加载到上下文中。根据智能体的不同，范围在 383–12,724 tokens 之间 (p25: 1,549, p75: 3,584)。
Related MCP server: pantheon-mcp
作为插件：
/plugin marketplace add npupko/agency-mcp-server
/plugin install agency@agency-mcp-server或通过 CLI：
claude mcp add agency -- npx -y agency-mcp-server添加到你的 MCP 配置中：
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"]
}
}
}就是这样。首次启动会将模板克隆到 ~/.cache/agency-mcp-server/，并每 24 小时拉取一次更新。
询问你的助手：
“搜索游戏经济设计师智能体”
你应该能看到来自 agency_search 工具的结果。如果是首次运行，模板会自动下载（约 30 秒）。
你的助手拥有四个工具：
agency_search(query, division?) -- 描述任务，获取匹配的智能体及生成说明
agency_browse(division?) -- 当你想查看可用内容时，浏览部门和智能体
agency_status() -- 检查索引新鲜度：智能体数量、上次更新时间、是否有可用更新
agency_update() -- 从 git 拉取最新模板并重建搜索索引，无需重启
当你寻求特定帮助时，你的助手会调用 agency_search，选择最佳匹配项，并使用该专家的完整系统提示词生成一个子智能体。你无需触碰任何配置文件即可获得专家级的响应。
智能体按部门组织：
部门 | 示例 |
工程 | 软件架构师、DevOps 工程师、技术文档撰写者 |
设计 | UI 设计师、UX 研究员、设计系统 |
游戏开发 | 游戏经济设计师、游戏机制设计师 |
市场营销 | 内容策略师、SEO 专家、电子邮件营销 |
安全与专业领域 | 安全审计员、数据科学家、法律分析师 |
...及更多 | 学术、销售、策略、支持、测试、空间计算 |
所有配置均通过 MCP 配置中的环境变量进行：
变量 | 默认值 | 描述 |
|
| 智能体模板路径。设置此项以使用你自己的模板，而不是自动克隆 |
|
| 用于克隆模板的 Git 仓库。指向你的 fork |
|
| 设置为 |
|
| 更新检查的时间间隔（小时） |
指向本地目录：
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"],
"env": {
"AGENCY_AGENTS_PATH": "/path/to/your/agent-templates"
}
}
}
}或从你自己的仓库克隆：
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"],
"env": {
"AGENCY_REPO_URL": "https://github.com/yourorg/custom-agents.git"
}
}
}
}每个智能体都是一个带有 YAML 前置元数据的 Markdown 文件，按部门组织：
engineering/
software-architect.md
devops-engineer.md
design/
ui-designer.md
game-development/
game-economy-designer.md---
name: Software Architect
description: Expert software architect specializing in system design...
---
Full agent system prompt goes here.服务器会索引 name 和 description 字段以供搜索。完整的 Markdown 正文在生成时将成为智能体的系统提示词。
agency_search(query, division?) -- 按任务描述查找智能体，返回带有文件路径和即用型生成模板的匹配项
agency_browse(division?) -- 列出所有部门，或列出特定部门内的智能体
agency_status() -- 检查索引新鲜度：智能体数量、上次更新时间、是否需要更新
agency_update() -- 在运行时从 git 拉取最新模板并重建搜索索引
agency://agents -- 完整的智能体索引（JSON 格式）
agency://divisions -- 带有数量和示例的部门列表
use-agent -- 描述任务，获取最佳匹配智能体及生成说明
npm install
npm run build
# Run with auto-fetched templates
node dist/index.js
# Run with local templates
AGENCY_AGENTS_PATH=./my-agents node dist/index.js
# Type checking
npm run typecheck
# MCP Inspector
npm run inspect智能体模板来自 agency-agents，作者 @msitarzewski。
MIT
Browse all agent divisions and their agents. Explore the agent registry when you want to see what's available. Use agency_search instead if you already know what kind of agent you need. Call with no arguments to see all divisions. Pass a division name to list its agents.
| Name | Required | Description | Default |
|---|---|---|---|
| division | No | Division to list agents for (omit to see all divisions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds clarity on how to invoke different behaviors (no args vs division), but does not add novel behavioral traits beyond annotations.
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, well-structured with usecase and instructions tags, and front-loaded with the primary action.
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 low complexity (1 optional param, no output schema), the description provides complete guidance on usage and alternatives, leaving no gaps.
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 coverage is 100% with a clear description for the division parameter. The description restates the schema's intent without adding new semantic detail, meeting the baseline.
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 'Browse all agent divisions and their agents.' It differentiates from sibling agency_search by recommending its use when knowing the agent type.
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 instructions: 'Call with no arguments to see all divisions. Pass a division name to list its agents.' Also includes when to use agency_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and launch a specialized agent for any task. Search agent templates by keyword. Returns matching agents with file paths and a spawn template. Call this before spawning any agency subagent.
Pass a task description as query (e.g. 'game mechanics', 'security audit')
Pick the best match from results
Spawn a subagent using the template at the bottom — replace with the file path and <describe the user's task> with the user's full, unabridged request
Return the subagent's response directly to the user without summarizing it
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Task or keyword to search for (e.g. 'game mechanics', 'frontend React', 'security audit') | |
| division | No | Optional: narrow to a division (e.g. 'engineering', 'game-development') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details like output format (matching agents with file paths and spawn template) and the spawning workflow. It does not contradict annotations and provides useful context beyond them.
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 well-structured with <usecase> and <instructions> tags, front-loading the main purpose. Each sentence adds value, though the instructions are detailed. It is concise for the complexity involved.
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 lacking an output schema, the description comprehensively explains the output (matching agents with file paths and spawn template) and provides full workflow instructions. Given the tool's complexity and the annotations covering safety, the description is complete enough for an AI agent.
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 coverage is 100% with both parameters described. The description adds example values for query (e.g., 'game mechanics') and division (e.g., 'engineering'), and clarifies that query should be a task description, enhancing the schema's meaning.
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 'Find and launch a specialized agent for any task' and the usecase elaborates on searching agent templates by keyword, returning file paths and spawn templates. It distinguishes from siblings (agency_browse, agency_status, agency_update) by focusing on search and spawning, not browsing, status, or updates.
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 states 'Call this before spawning any agency subagent' and provides step-by-step instructions on how to use it: pass task description, pick best match, spawn using the template, and return response directly. This gives clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current status of the agent index — last update time, whether an update is available, and agent count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds valuable behavioral details: what specific data the tool returns (last update time, update availability, agent count), which goes beyond the annotations.
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, clear sentence with no fluff. It front-loads the purpose and efficiently conveys the key information.
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 tool's simplicity (0 params, no output schema), the description fully informs the agent of what the tool does and what to expect. It covers all necessary aspects for correct 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?
There are no parameters, so the description does not need to add param meaning. The baseline for 0 params is 4, and the description effectively explains the output, compensating for the absence of an output schema.
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 verb 'check' and the resource 'agent index status', and specifies the three pieces of information returned (last update time, update availability, agent count). This distinguishes it from sibling tools like agency_browse or agency_search.
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 (for a quick status check) but does not explicitly state alternatives or when not to use. No guidance on context or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull latest agent templates from git (if applicable) and rebuild the search index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, but description adds context: pulling from git (with 'if applicable') and rebuilding the search index. This clarifies the exact side effect beyond the annotation flags.
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?
Single sentence, no fluff. Every word adds value: specifies action, resource, and condition ('if applicable'). Efficient and 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?
Given no parameters, no output schema, and a simple action, the description is sufficient. It covers the essential behavior and conditionality, making it complete for an agent to understand and invoke.
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?
No parameters in schema; schema coverage is 100%. Description adds no parameter info, but baseline for 0 parameters is 4. No need for additional parameter details.
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?
Description clearly states the verb 'pull' and 'rebuild' on specific resources 'agent templates' and 'search index'. Distinguishes from sibling tools (browse, search, status) as an update operation.
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?
No explicit when-to-use or when-not-to-use guidance. However, the idempotentHint annotation implies it can be called repeatedly without side effects, and siblings handle other tasks. Lacks explicit alternatives or exclusion criteria.
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.3.1agency_browseagency_searchagency_statusagency_updateScored across 4 tools
Each tool has a clearly distinct purpose: browse lists divisions/agents, search finds agents by keyword with spawn templates, status checks index health, update refreshes the index. No overlap.
All tools follow a consistent 'agency_' + verb in snake_case pattern (browse, search, status, update), making it predictable and easy to understand.
With 4 tools, the server is slightly on the minimal side but still well-scoped for agent registry operations. Each tool serves a distinct purpose without redundancy.
The tool surface covers the core workflows: browsing, searching, status checking, and updating. Minor gap is the lack of a direct spawn tool, but search provides a template for spawning.
150+ vertical AI expert bots as agent tools. $1 bots run on YOUR machine - your data stays yours.
Contextual prompts and agent skills for 140+ AI platforms.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
AI agent tools: web search, browser, 400+ LLMs, image gen, TTS, phone verify. Pay-per-use.
