단 하나의 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 토큰 | 모든 대화, 항상 |
MCP 서버 (유휴 상태) | ~55 토큰 | 모든 대화 |
MCP 서버 (검색 중) | ~350 토큰 | 검색할 때만 |
MCP 서버 (에이전트 사용 중) | ~2,700 토큰 | 에이전트를 생성할 때만 (중앙값) |
이는 기본 컨텍스트 사용량이 150배 감소한 것입니다. 동일한 160개 이상의 에이전트를 사용할 수 있으면서, 실제로 사용하는 에이전트에 대해서만 비용을 지불하면 됩니다.
설치된 에이전트 (8,300 토큰): agency-agents 설치 스크립트(install.sh --tool claude-code)를 실행하여 162개의 에이전트 파일을 ~/.claude/agents/로 복사했습니다. 그 후 새로운 Claude Code 세션을 열고 /context를 실행했습니다. Claude Code는 "Custom agents: 8.3k tokens"라고 보고했으며, 이는 에이전트 사용 여부와 관계없이 모든 대화에 로드됨을 의미합니다.
MCP 유휴 상태 (55 토큰): 대신 MCP 서버를 구성하면 /context에는 두 개의 지연된 도구 이름(agency_search, agency_browse)과 시스템 프롬프트의 간략한 서버 설명만 표시됩니다. 에이전트 데이터는 로드되지 않습니다.
MCP 검색 중 (350 토큰): 어시스턴트가 agency_search 및 agency_browse 도구를 해결하기 위해 ToolSearch를 호출할 때 로드되는 전체 JSON 도구 스키마를 토큰화하여 측정했습니다. @anthropic-ai/tokenizer로 계산했습니다.
MCP 에이전트 사용 중 (2,700 토큰): 145개의 모든 에이전트 파일에 대한 중앙값 토큰 수이며, @anthropic-ai/tokenizer로 측정했습니다. 실제로 사용하는 단일 에이전트 파일만 컨텍스트에 로드됩니다. 에이전트에 따라 383~12,724 토큰 범위입니다 (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-serverMCP 설정에 추가하세요:
{
"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 저장소. 본인의 포크 저장소를 지정하세요 |
|
| 자동 가져오기를 비활성화하려면 |
|
| 업데이트 확인 간격(시간) |
로컬 디렉토리를 지정하세요:
{
"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에이전트 템플릿은 @msitarzewski의 agency-agents에서 가져왔습니다.
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.
