Ein MCP-Konfigurationseintrag. Über 150 spezialisierte Agenten auf Abruf. Keine manuelle Einrichtung.
Ihr KI-Assistent ist ein Generalist. Manchmal benötigen Sie einen Spezialisten – einen Game-Economy-Designer, einen Sicherheitsprüfer, einen technischen Redakteur. Dieser MCP-Server gibt Ihrem Assistenten sofortigen Zugriff auf über 150 Experten-Agentenvorlagen. Beschreiben Sie, was Sie benötigen, er findet den richtigen Agenten und startet ihn.
You: "Help me design a balanced game economy"
Claude: [searches -> finds Game Economy Designer -> spawns it -> expert response]Vorlagen werden beim ersten Ausführen automatisch von agency-agents abgerufen und bleiben auf dem neuesten Stand. Sie müssen nichts tun.
Das können Sie. Das Installationsskript von agency-agents kopiert alle über 160 Agentendateien direkt in das Konfigurationsverzeichnis Ihres Tools (z. B. ~/.claude/agents/). Es funktioniert – aber der Name und die Beschreibung jedes Agenten werden in das Kontextfenster jeder Konversation geladen, egal ob Sie sie verwenden oder nicht.
Wir haben es gemessen:
Ansatz | Kontextkosten | Wann |
Installierte Agenten ( | ~8.300 Token | Jede Konversation, immer |
MCP-Server (im Leerlauf) | ~55 Token | Jede Konversation |
MCP-Server (Suche) | ~350 Token | Nur bei der Suche |
MCP-Server (Verwendung eines Agenten) | ~2.700 Token | Nur wenn Sie einen starten (Median) |
Das ist eine 150-fache Reduzierung der grundlegenden Kontextnutzung. Sie erhalten dieselben über 160 Agenten, zahlen aber nur für den, den Sie tatsächlich verwenden.
Installierte Agenten (8.300 Token): Wir haben das Installationsskript von agency-agents (install.sh --tool claude-code) ausgeführt, das 162 Agentendateien nach ~/.claude/agents/ kopiert hat. Dann haben wir eine neue Claude-Code-Sitzung geöffnet und /context ausgeführt. Claude Code meldete "Custom agents: 8.3k tokens" – geladen in jede Konversation, unabhängig davon, ob ein Agent verwendet wird.
MCP im Leerlauf (55 Token): Wenn stattdessen der MCP-Server konfiguriert ist, zeigt /context nur die beiden verzögerten Tool-Namen (agency_search, agency_browse) und eine kurze Serverbeschreibung im System-Prompt. Es werden keine Agentendaten geladen.
MCP-Suche (350 Token): Gemessen durch Tokenisierung der vollständigen JSON-Tool-Schemata, die geladen werden, wenn der Assistent ToolSearch aufruft, um die Tools agency_search und agency_browse aufzulösen. Gezählt mit @anthropic-ai/tokenizer.
MCP bei Verwendung eines Agenten (2.700 Token): Die mittlere Token-Anzahl über alle 145 Agentendateien hinweg, gemessen mit @anthropic-ai/tokenizer. Nur die einzelne Agentendatei, die Sie tatsächlich verwenden, wird in den Kontext geladen. Der Bereich liegt je nach Agent zwischen 383 und 12.724 Token (p25: 1.549, p75: 3.584).
Related MCP server: pantheon-mcp
Als Plugin:
/plugin marketplace add npupko/agency-mcp-server
/plugin install agency@agency-mcp-serverOder über CLI:
claude mcp add agency -- npx -y agency-mcp-serverFügen Sie dies zu Ihrer MCP-Konfiguration hinzu:
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"]
}
}
}Das war's. Beim ersten Start werden die Vorlagen nach ~/.cache/agency-mcp-server/ geklont und alle 24 Stunden aktualisiert.
Fragen Sie Ihren Assistenten:
"Suche nach einem Game-Economy-Designer-Agenten"
Sie sollten Ergebnisse vom Tool agency_search sehen. Wenn es der erste Durchlauf ist, werden die Vorlagen automatisch heruntergeladen (~30 Sekunden).
Ihr Assistent erhält vier Tools:
agency_search(query, division?) -- beschreiben Sie eine Aufgabe, erhalten Sie passende Agenten mit Startanweisungen
agency_browse(division?) -- erkunden Sie Abteilungen und Agenten, wenn Sie sehen möchten, was verfügbar ist
agency_status() -- überprüfen Sie die Aktualität des Index: Anzahl der Agenten, Zeitpunkt der letzten Aktualisierung, ob ein Update verfügbar ist
agency_update() -- rufen Sie die neuesten Vorlagen von Git ab und erstellen Sie den Suchindex neu, ohne neu zu starten
Wenn Sie um Hilfe bei etwas Bestimmtem bitten, ruft Ihr Assistent agency_search auf, wählt die beste Übereinstimmung aus und startet einen Unteragenten mit dem vollständigen System-Prompt dieses Spezialisten. Sie erhalten eine Expertenantwort, ohne jemals eine Konfigurationsdatei anfassen zu müssen.
Agenten sind in Abteilungen unterteilt:
Abteilung | Beispiele |
Engineering | Softwarearchitekt, DevOps-Ingenieur, Technischer Redakteur |
Design | UI-Designer, UX-Forscher, Design-Systeme |
Spieleentwicklung | Game-Economy-Designer, Game-Mechanics-Designer |
Marketing | Content-Stratege, SEO-Spezialist, E-Mail-Marketing |
Sicherheit & Spezialisiert | Sicherheitsprüfer, Datenwissenschaftler, Rechtsanalyst |
...und mehr | Akademisch, Vertrieb, Strategie, Support, Testen, Spatial Computing |
Die gesamte Konfiguration erfolgt über Umgebungsvariablen in Ihrer MCP-Konfiguration:
Variable | Standard | Beschreibung |
|
| Pfad zu Agentenvorlagen. Legen Sie dies fest, um Ihre eigenen Vorlagen anstelle des automatischen Klonens zu verwenden |
|
| Git-Repo, aus dem Vorlagen geklont werden sollen. Zeigen Sie auf Ihren Fork |
|
| Auf |
|
| Stunden zwischen Update-Prüfungen |
Zeigen Sie auf ein lokales Verzeichnis:
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"],
"env": {
"AGENCY_AGENTS_PATH": "/path/to/your/agent-templates"
}
}
}
}Oder klonen Sie aus Ihrem eigenen Repo:
{
"mcpServers": {
"agency": {
"command": "npx",
"args": ["-y", "agency-mcp-server"],
"env": {
"AGENCY_REPO_URL": "https://github.com/yourorg/custom-agents.git"
}
}
}
}Jeder Agent ist eine Markdown-Datei mit YAML-Front-Matter, organisiert nach Abteilung:
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.Der Server indiziert die Felder name und description für die Suche. Der vollständige Markdown-Text wird zum System-Prompt des Agenten, wenn er gestartet wird.
agency_search(query, division?) -- finden Sie Agenten nach Aufgabenbeschreibung, gibt Übereinstimmungen mit Dateipfaden und einer gebrauchsfertigen Startvorlage zurück
agency_browse(division?) -- listen Sie alle Abteilungen auf oder listen Sie Agenten innerhalb einer bestimmten Abteilung auf
agency_status() -- überprüfen Sie die Aktualität des Index: Anzahl der Agenten, Zeitpunkt der letzten Aktualisierung, ob ein Update ansteht
agency_update() -- rufen Sie die neuesten Vorlagen von Git ab und erstellen Sie den Suchindex zur Laufzeit neu
agency://agents -- vollständiger Agentenindex als JSON
agency://divisions -- Abteilungsliste mit Anzahlen und Beispielen
use-agent -- beschreiben Sie eine Aufgabe, erhalten Sie den am besten passenden Agenten mit Startanweisungen
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 inspectAgentenvorlagen von agency-agents von @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.
