A
licenseA
qualityF
maintenanceA Model Context Protocol server that connects GitHub code to Claude.ai. This server utilizes the Pera1 service to extract code from GitHub repositories and provide better context to Claude.
1
34
6
MIT
DollhouseMCP
by DollhouseMCP
DollhouseMCP is a comprehensive Model Context Protocol (MCP) server for managing, sharing, and customizing AI behaviors through dynamic personas and other AI customization elements. Key capabilities include:
AI Customization Management: Create, edit, validate, activate/deactivate, and manage personas, skills, templates, agents, memory, and ensembles through a portfolio system
Element-Specific Operations: Render content using templates with variables and execute autonomous agents for specific goals
GitHub Collection Integration: Browse, search, install, and submit AI customization elements to/from a community-driven GitHub collection with secure OAuth authentication
Import/Export & Sharing: Import personas from files/URLs, export to JSON format, and generate time-limited shareable URLs
User Identity Management: Set, retrieve, and clear user identity for content attribution
Server Management: Check status, perform automated updates with rollback capabilities and built-in safety features
Customization Options: Configure how persona indicators are displayed in AI responses
Offers containerized deployment options with production and development configurations, supporting volume mounts for custom personas and environment variable configuration
Provides a complete GitHub-powered marketplace integration for browsing, searching, installing, and submitting personas, with support for authentication and automated submission workflows
Click on "Install 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., "@DollhouseMCPactivate the 'helpful assistant' persona from the community collection"
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.
DollhouseMCP
Open-source AI customization through modular elements.
Website · Browse the Collection · NPM Package · Discord
How It Works
CREATE or EDIT PORTFOLIO ACTIVATE → USE
─────────────────────────────────────────────────────────────────────────────
"Create a skill for 📁 ~/.dollhouse/portfolio/ "Activate the Dollhouse
writing blog posts" Expert ensemble"
37 starter elements:
"Edit the code review ──▶ personas · skills · ──▶ Your AI now has
persona to add security" templates · agents · new behavior,
memories · ensembles capabilities, and
persona · skill · template permission policies
agent · memory · ensemble + everything you create
+ community installsPick any path to start:
Activate a starter element from your portfolio — your AI immediately changes
Create any element type (persona, skill, template, agent, memory, ensemble) by describing what you want in plain English
Edit any existing element to refine it
Browse the community collection and install elements made by other users
Your portfolio (~/.dollhouse/portfolio/ on macOS/Linux, %USERPROFILE%\.dollhouse\portfolio\ on Windows) is a local folder that holds all your Dollhouse elements. It ships with 37 starters — including the dollhouse-expert-suite ensemble (persona + knowledge base) you can activate for guided help. Everything you create or install lands here. Share back to the community or sync to GitHub whenever you're ready.
Related MCP server: MCP Development Server
Quick Start
v2.0.0 is now available. DollhouseMCP v2 is the default release. Release notes | Migration guide | Report issues
DollhouseMCP installs on any MCP-compatible AI client — Claude Code, Claude Desktop, Cursor, Gemini, Codex, and local LLMs. Core element management (create, activate, search, browse) works across all platforms. Advanced features (Gatekeeper confirmation flows, agentic loop execution) have been tested extensively on Claude Code and should work on any client that supports standard MCP tool call/response patterns.
Interactive Setup (any platform):
npx @dollhousemcp/mcp-server@latest --webOpens a browser-based setup wizard with one-click install for Claude Desktop, Claude Code, Cursor, VS Code, Codex, Gemini CLI, Windsurf, Cline, and LM Studio. Detects existing installations, supports auto-updating and pinned versions.
Permission hook support in the setup wizard currently breaks down like this:
Platform | Setup status | Permission hook status |
Claude Code | One-click install | Full native support |
Cursor | One-click install | Partial native support |
VS Code | One-click install | Partial native support |
Codex | One-click install | Partial native support, Bash-only |
Gemini CLI | One-click install | Partial native support |
Windsurf | One-click install | Partial native support |
Cline | One-click install | MCP setup only in this release |
LM Studio | One-click install | MCP setup only in this release |
Claude Desktop | One-click install | No native permission hook path in this release |
Claude Code (one command):
claude mcp add -s user dollhousemcp -- npx -y @dollhousemcp/mcp-serverClaude Desktop (one-click install):
Download the DollhouseMCP Desktop Extension (.mcpb file) and double-click it. Claude Desktop handles the rest — no terminal required.
Other platforms — see the Quick Start Guide or run the interactive setup above.
Then start a conversation:
"What DollhouseMCP tools do you have available?"
"List all available Dollhouse personas"
"Activate the Dollhouse debug detective persona"DollhouseMCP ships with 38 Dollhouse elements across all 6 types. Just describe what you want in natural language.
First time? The Public Beta Onboarding Guide walks you from install to your first activated Dollhouse persona in under 10 minutes.
Dollhouse Elements: Behavior, Capabilities, and Permissions
Dollhouse elements are modular building blocks that customize your AI. When you activate a Dollhouse element, you're not just changing a prompt — you're changing what tools the AI can access, what commands it can run, and what operations require your approval.
Dollhouse Element | What It Does |
Dollhouse Personas | Shape behavior, tone, expertise, and priorities. Act as security principals with permission policies that control what the AI can do. |
Dollhouse Skills* | Add discrete capabilities the AI can activate on demand. Code review, data analysis, penetration testing, translation, and more. |
Dollhouse Templates | Standardize outputs with variable substitution. Reports, emails, briefs, documentation — consistent structure every time. Variables are auto-derived from |
Dollhouse Agents | Execute multi-step goals autonomously. State tracking, resilience policies, autonomy evaluation, and an execution lifecycle. |
Dollhouse Memories | Persist structured context across sessions. Facts, preferences, project state. Can auto-load on startup. |
Dollhouse Ensembles | Bundle multiple elements into one activatable unit. Activation strategies, conflict resolution, and coordinated permission policies. |
*Skills Compatibility
Dollhouse Skills (introduced July 2025) predate the agent skills format later adopted by Claude/Anthropic. DollhouseMCP includes a built-in lossless bidirectional converter between the two formats.
Import: Convert agent skills → Dollhouse Skills via
convert_skill_format. Once converted, they're first-class Dollhouse elements — combinable with Personas, Templates, and other Skills inside Ensembles, managed by Dollhouse Agents, and protected by Gatekeeper policies.Export: Convert Dollhouse Skills → agent skills for platforms that don't have DollhouseMCP installed.
Roundtrip: The converter supports a lossless mode that preserves everything in both directions. A safe mode is also available that sanitizes potentially risky patterns during conversion.
All Dollhouse elements are readable markdown or YAML files stored in your local portfolio. You own them, you control them. When interacting with your AI, use "Dollhouse" to disambiguate — say "activate the Dollhouse code review persona" or "run the Dollhouse research agent" to ensure the AI uses DollhouseMCP elements rather than native platform features.
MCP-AQL: How Your AI Talks to DollhouseMCP
Most MCP servers expose dozens of individual tools, each consuming context tokens and forcing the LLM to pick the right one from a flat list. DollhouseMCP takes a different approach.
MCP-AQL (Model Context Protocol – Advanced Agent API Adapter Query Language) organizes all operations into 5 semantic endpoints — CRUDE: Create, Read, Update, Delete, Execute. The A pulls quadruple duty: Advanced query capabilities, Agent-first design, API consolidation, and Adapter layer to bridge other MCP servers and APIs to work directly with LLMs. Each endpoint groups operations by what they do to state, giving the LLM clear semantic signals about the consequences of each action:
Endpoint | Purpose | Permission Level |
Create | Add new elements, install from collection, add memory entries | Confirm once per session |
Read | List, search, get details, activate, introspect | Auto-approved (safe, no side effects) |
Update | Edit existing elements | Confirm each time |
Delete | Remove elements, clear entries | Confirm each time |
Execute | Run agents, manage execution lifecycle, confirm operations | Confirm each time |
Why This Matters
Semantic clarity — The LLM knows that calling
mcp_aql_readis always safe. Callingmcp_aql_deleteis always destructive. No guessing.Host-level permission control — MCP clients like Claude Code can set different approval policies per endpoint (auto-approve reads, require confirmation for deletes).
Progressive disclosure through introspection — The LLM starts with just 5 tool endpoints. It discovers operations, parameters, element formats, and usage examples at runtime by asking the server:
{ "operation": "introspect", "params": { "query": "operations" } } { "operation": "introspect", "params": { "query": "format", "name": "persona" } }This is progressive disclosure built into the protocol — the LLM only loads what it needs, when it needs it. Unlike client-side solutions that require special harness support (like Claude Code's deferred tool loading), MCP-AQL's introspection works on any MCP client because it's just a standard tool call that returns structured data. No fancy client features required. The server describes itself.
Elements use the same principle: YAML frontmatter provides metadata for quick scanning, full markdown content loads only when activated. The LLM can list 200 elements at a glance and deep-dive into the ones it needs.
Token efficiency — 5 endpoints at ~4,300 tokens vs ~29,600 for ~40 discrete tools (85% reduction). Single mode reduces further to ~350 tokens.
Full MCP-AQL documentation — protocol design, CRUDE pattern rationale, introspection system, endpoint modes, and debugging.
The Gatekeeper: Elements Control Permissions
Every MCP-AQL operation passes through the Gatekeeper — a server-side permission system that Dollhouse elements directly control. When you activate a Dollhouse Persona, Skill, or Ensemble, its permission policies take effect immediately.
Example: Activate a "read-only analyst" persona
┌─────────────────────────────────────────────────────────────────┐
│ Persona: read-only-analyst │
│ │
│ gatekeeper: │
│ allow: [list_elements, search, get_element, introspect] │
│ deny: [create_element, edit_element, delete_element, │
│ execute_agent, confirm_operation] │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ What the LLM CAN do: What the LLM CANNOT do: │
│ │
│ ✓ List and search elements ✗ Create new elements │
│ ✓ Read element details ✗ Edit existing elements │
│ ✓ Introspect operations ✗ Delete anything │
│ ✓ Activate/deactivate ✗ Run agents │
│ ✗ Confirm any gated operation │
└─────────────────────────────────────────────────────────────────┘This works even if the MCP client has "Always Allow" enabled. The Gatekeeper runs server-side — after the client approves the tool call, the Gatekeeper still enforces the active element's policies. A deny from any active element cannot be overridden by the LLM or the client.
Use the two gatekeeper surfaces differently:
allow/confirm/denyare for MCP-AQL operation patterns likeread_*,edit_*,delete_element, andexecute_agentexternalRestrictionsis for external tool and hook patterns likeRead:*,Edit:*,Bash:git status*, andBash:rm *
How Policy Resolution Works
deny > confirm > allow > route default
(highest priority) (lowest priority)Element deny — hard-blocked, cannot be confirmed or bypassed
Element confirm — requires user confirmation even if the route default is auto-approve
Element allow — auto-approves operations that would normally require confirmation
Route default — the endpoint's built-in permission level (reads auto-approve, deletes confirm)
Policies stack across all active elements. If one persona allows an operation but another denies it, deny wins. This lets you compose elements with confidence — a security-focused persona can lock down operations while a skill adds capabilities.
What This Means in Practice
Activate a read-only persona → the LLM can only browse and search, even if you've given the MCP client full access
Activate a security analyst ensemble →
delete_elementandrm -rf *are denied, but code review tools work normallyDeactivate the restrictive element → full access returns immediately
Nuclear sandbox →
deny: ['confirm_operation']blocks ALL confirmations, making the session completely read-only until the element is deactivated
Platform compatibility: The Gatekeeper enforces policies server-side — deny and allow decisions work on any MCP client. The confirmation flow (where the LLM calls
confirm_operationin response to a block) has been tested extensively on Claude Code and the DollhouseMCP Bridge. It should work on any MCP client where the LLM can interpret structured tool responses and make follow-up tool calls, but has not been rigorously verified on all platforms.
Gatekeeper documentation — confirmation flows, element policy syntax, sandbox model, external tool restrictions, and the session-allow problem.
Portfolio
Your Dollhouse elements live in a local portfolio at ~/.dollhouse/portfolio/ (macOS/Linux) or %USERPROFILE%\.dollhouse\portfolio\ (Windows). Ask your AI to "open the portfolio browser" (or call open_portfolio_browser via MCP-AQL) to browse them visually. Activation is done through the LLM — ask it to "activate the Dollhouse code review persona" and it handles the rest.
Local-first — Everything works offline. No account required.
37 bundled elements — 7 personas, 7 skills, 8 templates, 7 agents, 3 memories, 5 ensembles ship with the server as starter content. Includes the dollhouse-expert-suite ensemble (persona + knowledge base memory) for guided help, and a Session Monitor agent that keeps your LLM synchronized with server state changes.
GitHub sync — Optionally back up your portfolio to a GitHub repository and share elements with others.
Community Collection — Browse the collection to see what's available, then install elements directly from your AI. Or submit your own.
GitHub Portfolio Sync Guide — back up to GitHub, sync between machines, submit to the community.
Dollhouse Agent Execution
Dollhouse Agents don't just run — every step passes through the MCP server, back to the LLM, and through the Gatekeeper. The LLM makes semantic decisions; the server handles programmatic enforcement. Neither side operates alone.
┌───────────────┐
│ HUMAN │
│ (optional) │◄──── LLM asks for guidance
│ │ when autonomy evaluator
│ Approve, deny,│ says "pause"
│ or guide │
└───────┬───────┘
│ responds to LLM
▼
┌─────────────┐ ┌─────────────────────────────┐ ┌─────────────┐
│ │ │ DollhouseMCP MCP Server │ │ │
│ LLM │────▶│ │────▶│ LLM │
│ │ │ 1. Gatekeeper checks policy │ │ │
│ Decides │ │ 2. Autonomy Evaluator scores │ │ Records │
│ next │ │ 3. Danger Zone enforcement │ │ step and │
│ action │ │ 4. Execute or block │ │ continues │
│ │ │ 5. Return result + autonomy │ │ or pauses │
│ │◀────│ guidance to LLM │◀────│ │
└─────────────┘ └─────────────────────────────┘ └─────────────┘
│ │
└──────────────── repeats every step ───────────────────┘Each step in the loop:
Gatekeeper checks every operation against active element policies — deny, confirm, or allow
Autonomy Evaluator scores whether the agent should continue autonomously or pause for human input
Danger Zone enforces hard blocks on high-risk operations (file deletion, external API calls, system commands)
Step recording creates an audit trail of every decision and outcome
The LLM receives autonomy guidance with each response — continue, pause, or escalate — so it never operates unmonitored
This means a Dollhouse Agent can't silently escalate. Every action is visible, every step is evaluated, and active element policies are enforced throughout the entire execution.
Platform note: The agentic loop relies on the LLM making sequential MCP tool calls and interpreting structured responses — standard MCP behavior. It has been tested extensively on Claude Code and the DollhouseMCP Bridge. The server-side enforcement (Gatekeeper, Danger Zone, step recording) is platform-independent. The LLM's ability to follow autonomy guidance (continue/pause/escalate) depends on the LLM's capability to interpret structured tool responses, which may vary across platforms.
Full Agent Execution documentation — the agentic loop, security enforcement, human-in-the-loop control, agent composition, resilience policies, and execution lifecycle operations.
More Features
Web Portfolio Browser — Built-in web console for browsing and managing your portfolio visually. Ask your AI to "open the portfolio browser" or run
npm run webstandalone.Batch Operations — Execute multiple operations in a single MCP-AQL request for efficient workflows
Activation Persistence — Elements activated in a session are restored on server restart. No re-activation needed.
Universal Backup — Built-in backup service for portfolio elements with restore capability
Cache Memory Budget — Configurable memory budget for collection and index caches to control resource usage
NLP Discovery — Jaccard similarity and Shannon entropy scoring for intelligent element search and discovery
Cross-Element Relationships — GraphRAG-style mapping between elements for finding related content
Security Hardened — Input sanitization, path traversal prevention, YAML injection protection, file locking, DOMPurify sanitization, content validation against hundreds of attack vectors. Security docs
Cross-Platform — Tested on Windows, macOS, and Linux across Node.js 20+
Installation Options
The Quick Start above covers the fastest path. For more control:
Local Install (Recommended for Multiple Configs)
mkdir -p ~/mcp-servers && cd ~/mcp-servers
npm install @dollhousemcp/mcp-serverThen point your MCP client at node <path>/node_modules/@dollhousemcp/mcp-server/dist/index.js.
MCP-AQL Endpoint Modes
Mode | Endpoints | Tokens | Env Variable | Best For |
CRUDE (default) | 5 | ~4,300 |
| Most users. Semantic grouping with host-level permission control |
Single | 1 | ~350 |
| Multi-server setups with constrained context windows |
Discrete | ~40 | ~29,600 |
| Backward compatibility with v1 tool names |
Note: CRUDE and Single are controlled by
MCP_AQL_ENDPOINT_MODE. Discrete mode uses a different variable:MCP_INTERFACE_MODE=discrete.
Common Configuration
Variable | Default | Description |
|
| Endpoint mode: |
|
| Interface style: |
|
| Custom portfolio location |
| — | Personal access token for GitHub operations |
Full environment variable reference · MCP client setup for other platforms
Documentation
Guide | Description |
Platform-specific install for Claude Code, Desktop, Cursor, Gemini, Codex, local LLMs | |
Install to first persona in 10 minutes | |
Operation cheat sheet written for AI assistants | |
CRUDE protocol, introspection, endpoint modes | |
Permission layers, element policies, sandbox model | |
Back up to GitHub, sync between machines, community submission | |
Persistent context storage and retrieval | |
Bidirectional agent skills conversion | |
Agentic loop, security enforcement, human-in-the-loop, composition | |
System design, DI container, data flow | |
Threat model, testing, and vulnerability reporting | |
Complete MCP tool catalog and payload schemas | |
Upgrading from v1.x | |
Common issues and solutions |
Contributing
We welcome contributions — bug reports, feature requests, documentation, code, and community elements.
git clone https://github.com/DollhouseMCP/mcp-server.git
cd mcp-server
npm install && npm run build && npm testSee CONTRIBUTING.md for the full development workflow, branch strategy, and code style guide.
Community
GitHub Discussions — Questions, ideas, and showcase
GitHub Issues — Bug reports and feature requests
Discord — Real-time chat
Browse the Collection — Community-contributed Dollhouse elements you can install
Collection Repository — Source repo for submissions and contributions
License
AGPL-3.0-or-later — free to use, modify, and distribute. Network use requires source disclosure. See LICENSE for full terms.
Copyright 2024-2026 Mick Darling / DollhouseMCP
Available Tools
5 toolsmcp_aql_createA
Additive, non-destructive operations.
Supported operations: create_element, import_element, addEntry, verify_challenge, release_deadlock, beetlejuice_beetlejuice_beetlejuice, record_execution_step, install_collection_content, submit_collection_content, init_portfolio, sync_portfolio, portfolio_element_manager, setup_github_auth, configure_oauth, import_persona
Element types: persona, skill, template, agent, memory, ensemble
These operations add new data without removing or overwriting existing content.
Quick start examples: { operation: "create_element", element_type: "persona", params: { element_name: "MyPersona", description: "A helpful assistant", instructions: "You ARE a helpful assistant. ALWAYS provide clear, accurate responses." } } { operation: "create_element", element_type: "agent", params: { element_name: "MyAgent", description: "Task executor", instructions: "Execute goals methodically. Report progress at each step.", goal: { template: "Complete: {objective}", parameters: [{ name: "objective", type: "string", required: true }] } } } { operation: "create_element", element_type: "memory", params: { element_name: "session-notes", description: "Session context and notes" } } { operation: "create_element", element_type: "ensemble", params: { element_name: "my-ensemble", description: "Combined element set", metadata: { elements: [{ element_name: "expert", element_type: "persona", role: "primary" }, { element_name: "analysis", element_type: "skill", role: "support" }] } } } Valid ensemble roles: primary, support, override, monitor, core { operation: "addEntry", params: { element_name: "session-notes", content: "Remember this fact", tags: ["important"] } } Note: addEntry content supports markdown (headers, lists, bold, tables, code blocks). Ensure markdown content is properly JSON-escaped — use \n for newlines, " for quotes, and \ for backslashes within the JSON string value.
Execution lifecycle — record agent progress (appends step records, like addEntry): { operation: "record_execution_step", params: { element_name: "code-reviewer", stepDescription: "Analyzed files", outcome: "success", findings: "Found 3 issues" } } This is the normal next lifecycle call after mcp_aql_execute { operation: "execute_agent", ... }. Response flow: record_execution_step returns { autonomy: { continue, factors, notifications? } }. Check autonomy.continue to decide whether to proceed. Check autonomy.notifications for permission_pending (gatekeeper blocks), autonomy_pause, or danger_zone alerts to relay to human operators.
Import & portfolio: { operation: "import_element", element_type: "skill", params: { element_name: "code-formatter", data: "..." } } { operation: "import_persona", params: { source: "/path/to/persona.md" } } { operation: "install_collection_content", params: { element_type: "persona", element_name: "Creative-Writer" } } { operation: "submit_collection_content", params: { element_type: "skill", element_name: "code-formatter" } } { operation: "init_portfolio" } { operation: "sync_portfolio" } { operation: "portfolio_element_manager", params: { action: "push", element_type: "persona", element_name: "Tech-Writer" } }
Auth & verification: { operation: "setup_github_auth" } { operation: "configure_oauth", params: { client_id: "your-client-id" } } { operation: "verify_challenge", params: { code: "ABC123" } } { operation: "release_deadlock" } { operation: "beetlejuice_beetlejuice_beetlejuice" }
Batch operations: Use the operations array to execute multiple operations sequentially in a single request. { operations: [{ operation: "addEntry", params: { element_name: "log", content: "Step 1" } }, { operation: "addEntry", params: { element_name: "log", content: "Step 2" } }] }
Discover required parameters — use mcp_aql_read: { operation: "introspect", params: { query: "operations", name: "create_element" } } Discover element format specs (required fields, syntax, examples) — use mcp_aql_read: { operation: "introspect", params: { query: "format", name: "template" } }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Operation parameters | |
| operation | Yes | Operation name to execute | |
| operations | No | Array of operations for batch execution | |
| element_type | No | Target element type (optional) |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false and destructiveHint=false. The description adds substantial behavioral detail: operations are non-destructive and additive; record_execution_step appends records and returns an autonomy object with continue, factors, and notifications; batch operations execute sequentially; and markdown content must be JSON-escaped. This goes well beyond the annotations and is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well organized into clear sections: core scope, element types, quick start examples, execution lifecycle, import/portfolio, auth, batch operations, and introspection. It is front-loaded with the most important semantic constraint. Some examples could be trimmed, but the length is largely justified for a multi-operation facade tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex polymorphic tool with a thin schema, no output schema, and a large set of operations. The description covers operation categories, element types, parameter discovery, batch behavior, and the response flow for the lifecycle operation. It does not explain return shapes for most operations, but given the breadth and the explicit pointer to mcp_aql_read for discovering formats, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, but the descriptions are generic ('Operation parameters', 'Operation name to execute'). The tool description compensates by listing valid operation names, giving concrete params examples for create_element, addEntry, record_execution_step, and portfolio operations, and explaining the operations array for batch execution. It does not document every operation's full parameter set, but it explicitly directs the agent to use mcp_aql_read for introspection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Additive, non-destructive operations' and immediately enumerates the supported operations and element types. It clearly states that these operations add new data without removing or overwriting existing content, which differentiates this tool from its update/delete/execute siblings even without seeing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage context: it distinguishes additive operations from non-additive ones, provides examples for common operation classes, and explicitly directs the agent to mcp_aql_read for discovering required parameters and element format specs. It also frames record_execution_step as the expected follow-up after mcp_aql_execute. It does not enumerate every 'when not to use' scenario relative to siblings, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_aql_deleteADestructive
Destructive operations that remove data.
Supported operations: delete_element, clear, clear_github_auth
Element types: persona, skill, template, agent, memory, ensemble
These operations remove data. Use with caution.
⚠️ SECURITY: Do not auto-allow this endpoint in your host settings (e.g., Claude Code settings.json). Each delete operation should require explicit human approval. Auto-allowing bypasses the per-operation confirmation gate, leaving only element deny policies as protection against unintended data loss.
Quick start examples: { operation: "delete_element", element_type: "persona", params: { element_name: "Old-Persona" } } { operation: "clear", params: { element_name: "temp-notes" } } { operation: "clear_github_auth" }
Discover required parameters — use mcp_aql_read: { operation: "introspect", params: { query: "operations", name: "delete_element" } }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Operation parameters | |
| operation | Yes | Operation name to execute | |
| operations | No | Array of operations for batch execution | |
| element_type | No | Target element type (optional) |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description adds substantial behavioral context: the operations remove data, should be gated by human approval, and should not be auto-allowed. The security warning about bypassing the per-operation confirmation gate is exactly the kind of risk disclosure that helps an agent invoke this tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and lists supported operations and element types before moving to caution and examples. There is minor redundancy ('Destructive operations that remove data' vs 'These operations remove data'), and the security warning is long, but it is important and all sections serve a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-operation destructive tool with no output schema, the description covers scope, examples, security expectations, and a clear path to discover required parameters via mcp_aql_read. It doesn't describe return values or every operation's exact parameters, but the introspection instruction fills the most important gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% property description coverage, but the description adds value by showing concrete payloads like { operation: 'delete_element', element_type: 'persona', params: { element_name: 'Old-Persona' } } and by instructing the agent to introspect for per-operation parameters. It does not enumerate every operation's required params, but the discovery mechanism compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit: 'Destructive operations that remove data' names the verb and resource, then enumerates supported operations (delete_element, clear, clear_github_auth) and element types. This clearly distinguishes it from the sibling create/read/update/execute tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when this tool applies: when data must be removed, with caution and explicit human approval. It points to mcp_aql_read for discovering required parameters, but it doesn't explicitly state when to prefer non-destructive sibling tools like mcp_aql_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_aql_executeADestructive
Execution lifecycle operations for executable elements (agents, workflows, pipelines).
Supported operations: confirm_operation, approve_cli_permission, execute_agent, complete_execution, continue_execution, abort_execution, prepare_handoff, resume_from_handoff
These operations manage runtime execution state. Unlike CRUD operations (which manage definitions), Execute operations handle the execution lifecycle:
execute_agent: Start a new execution (returns goalId and stateVersion for tracking)
complete_execution: Signal successful completion once the goal is done
continue_execution: Resume a previously paused execution with the same goal parameters
abort_execution: Abort a running execution, rejecting further operations
confirm_operation: Confirm a pending operation that requires user approval (Gatekeeper flow)
approve_cli_permission: Approve a pending CLI tool permission request
prepare_handoff: Serialize goal progress into a portable handoff block for session transfer
resume_from_handoff: Resume agent execution from a handoff block with integrity validation
IMPORTANT: Execute operations are potentially destructive (agents can perform any action) and non-idempotent (calling execute_agent twice creates two separate executions).
⚠️ SECURITY: Do not auto-allow this endpoint in your host settings (e.g., Claude Code settings.json). Each execution should require explicit human approval. Auto-allowing bypasses the per-operation confirmation gate. While DangerZone verification and element deny policies still provide protection, the primary human review checkpoint is lost.
Canonical loop:
Call execute_agent once to start the goal and receive { goalId, stateVersion, activeElements, safetyTier, ... }.
After each chunk of work, use mcp_aql_create: { operation: "record_execution_step", ... }.
Read record_execution_step.autonomy.continue and any autonomy.notifications to decide whether to continue, pause for a human, or handle a gatekeeper block.
When the goal is finished, call complete_execution. Use continue_execution only when an already-started goal was paused and you are resuming it with the same goal parameters. It is not the normal next call after execute_agent.
Quick start examples: { operation: "execute_agent", params: { element_name: "code-reviewer", parameters: { objective: "Review code" } } } Next lifecycle step — use mcp_aql_create: { operation: "record_execution_step", params: { element_name: "code-reviewer", stepDescription: "Reviewed auth module", outcome: "success", findings: "Found 2 security issues" } } { operation: "complete_execution", params: { element_name: "code-reviewer", outcome: "success", summary: "Completed review" } } { operation: "abort_execution", params: { element_name: "data-collector", reason: "User requested cancellation" } } { operation: "continue_execution", params: { element_name: "rubric-qa-agent", previousStepResult: "Verified citation set", parameters: { run_dir: "/app/run", deliverable_path: "/app/run/output.docx" } } } { operation: "confirm_operation", params: { operation: "execute_agent" } } { operation: "approve_cli_permission", params: { request_id: "req-123", decision: "allow" } } { operation: "prepare_handoff", params: { element_name: "code-reviewer" } } { operation: "resume_from_handoff", params: { element_name: "code-reviewer", handoff_block: "..." } }
Discover required parameters — use mcp_aql_read: { operation: "introspect", params: { query: "operations", name: "execute_agent" } }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Operation parameters | |
| operation | Yes | Operation name to execute | |
| operations | No | Array of operations for batch execution | |
| element_type | No | Target element type (optional) |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description goes far beyond that by disclosing that executions are potentially destructive, non-idempotent, and require human approval. It even warns against auto-allowing the endpoint in Claude Code settings, preserving a security checkpoint that is not inferable from annotations. It also discloses execute_agent's return fields and abort semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately structured for the complexity: purpose, supported operations, security warning, canonical loop, and quick-start examples. Each section contributes non-redundant information an agent cannot get from annotations or the schema. Important constraints like 'continue_execution is not the normal next call' are front-loaded in the workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given eight operations, a destructive/non-idempotent profile, nested params, and no output schema, the description is remarkably complete. It covers the full lifecycle, gatekeeper approval flow, CLI permission approval, handoff serialization and validation, abort behavior, and the exact return fields of execute_agent. It also tells the agent where to look for remaining parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for top-level parameters, so the baseline is 3. The description adds meaningful per-operation parametrization through concrete examples (element_name, parameters, objective, outcome, request_id, decision, handoff_block, previousStepResult). It does not exhaustively document every nested param, but it tells the agent to use mcp_aql_read introspect to discover required parameters, which is an acceptable complement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, accurate statement: 'Execution lifecycle operations for executable elements (agents, workflows, pipelines).' It enumerates all eight supported operations and explicitly contrasts Execute operations with the CRUD siblings, so an agent can distinguish mcp_aql_execute from mcp_aql_create/read/update/delete without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The canonical loop provides a precise execution sequence: execute_agent first, then record_execution_step via mcp_aql_create, then continue or complete. It explicitly warns that continue_execution is not the normal next call after execute_agent and should only be used when resuming a paused goal with the same parameters. It also points to mcp_aql_read for introspecting required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_aql_readARead-only
Safe, read-only operations.
Supported operations: activate_element, open_portfolio_browser, open_logs, open_metrics, open_permissions, open_setup, permission_prompt, evaluate_permission, get_effective_cli_policies, get_permission_authority, get_pending_cli_approvals, search, list_elements, get_element, get_element_details, search_elements, query_elements, get_active_elements, validate_element, render, export_element, deactivate_element, introspect, get_capabilities, get_execution_state, get_gathered_data, browse_collection, search_collection, search_collection_enhanced, get_collection_content, get_collection_cache_health, portfolio_status, portfolio_config, search_portfolio, search_all, check_github_auth, oauth_helper_status, dollhouse_config, convert_skill_format, get_build_info, get_cache_budget_report, query_logs, query_metrics, find_similar_elements, get_element_relationships, search_by_verb, get_relationship_stats
Element types: persona, skill, template, agent, memory, ensemble
These queries only read data and never modify server state.
Quick start examples: { operation: "list_elements", element_type: "persona" } { operation: "get_active_elements", element_type: "persona" } { operation: "search_elements", params: { query: "creative" } } { operation: "get_element", element_type: "memory", params: { element_name: "session-notes" } }
Element operations: { operation: "activate_element", element_type: "persona", params: { element_name: "Default" } } { operation: "deactivate_element", element_type: "persona", params: { element_name: "Default" } } { operation: "get_element_details", element_type: "skill", params: { element_name: "code-review" } } { operation: "query_elements", element_type: "persona", params: { filters: { category: "creative" } } } { operation: "validate_element", element_type: "agent", params: { element_name: "task-planner" } } { operation: "render", params: { element_name: "meeting-notes", variables: { date: "2026-03-03" } } } { operation: "export_element", element_type: "persona", params: { element_name: "Tech-Writer" } } { operation: "open_portfolio_browser" } { operation: "open_logs" } { operation: "open_metrics" } { operation: "open_permissions" } { operation: "open_setup" }
Memory-specific search (filter by tags): { operation: "search", params: { query: "*", type: "memory", filters: { tags: ["important"] } } }
Execution lifecycle — read-only queries: { operation: "get_execution_state", params: { element_name: "code-reviewer" } } { operation: "get_gathered_data", params: { element_name: "code-reviewer", goalId: "goal-id" } } For execution-state reads, reuse the same element_name you passed to execute_agent. If element_name is missing, retry with the same agent name rather than inventing a new one.
Collection: { operation: "browse_collection", params: { section: "personas" } } { operation: "search_collection", params: { query: "creative" } } { operation: "search_collection_enhanced", params: { query: "creative", page: 1 } } { operation: "get_collection_content", params: { element_type: "persona", element_name: "Creative-Writer" } } { operation: "get_collection_cache_health" }
Portfolio: { operation: "portfolio_status" } { operation: "portfolio_config" } { operation: "search_portfolio", params: { query: "creative" } } { operation: "search_all", params: { query: "creative" } }
System: { operation: "dollhouse_config" } { operation: "get_build_info" } { operation: "get_cache_budget_report" } { operation: "query_logs", params: { level: "error", limit: 10 } } { operation: "query_metrics" } { operation: "query_metrics", params: { names: ["system.memory.*"], type: "gauge" } } { operation: "convert_skill_format", params: { direction: "agent_to_dollhouse", agent_skill: { "SKILL.md": "---\nname: my-skill\ndescription: test\n---\n\nUse this skill." } } } { operation: "convert_skill_format", params: { direction: "agent_to_dollhouse", security_mode: "warn", path_mode: "lossless", agent_skill: { "SKILL.md": "---\nname: my-skill\ndescription: test\n---\n\nUse this skill." } } } { operation: "convert_skill_format", params: { direction: "dollhouse_to_agent", path_mode: "lossless", dollhouse_markdown: "---\nname: my-skill\ndescription: test\ninstructions: Use this skill.\n---\n\n### binaries/logo.png\n(binary link: ./skills/binaries/logo.png)" } }
Auth: { operation: "check_github_auth" } { operation: "oauth_helper_status" }
Gatekeeper & CLI policies: { operation: "permission_prompt", params: { tool: "Bash", prompt: "run npm test" } } { operation: "evaluate_permission", params: { tool_name: "Bash", input: { command: "git status" }, platform: "claude_code" } } { operation: "get_effective_cli_policies" } { operation: "get_pending_cli_approvals" } { operation: "get_permission_authority" } { operation: "get_permission_authority", params: { host: "claude-code" } }
Enhanced index: { operation: "find_similar_elements", params: { element_type: "persona", element_name: "Creative-Writer" } } { operation: "get_element_relationships", params: { element_type: "skill", element_name: "code-review" } } { operation: "search_by_verb", params: { verb: "review" } } { operation: "get_relationship_stats" }
Discover all operations and parameters: { operation: "get_capabilities" } { operation: "get_capabilities", params: { category: "Element Lifecycle" } } { operation: "introspect", params: { query: "operations" } }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Operation parameters | |
| operation | Yes | Operation name to execute | |
| operations | No | Array of operations for batch execution | |
| element_type | No | Target element type (optional) |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a firm read-only guarantee beyond the annotations and provides useful contextual guidance, such as reusing element_name for execution-state reads and retrying with the same agent name rather than inventing a new one. However, some listed operations (activate_element, deactivate_element, permission_prompt) sound like state changes or side effects, and the description does not clarify why they are safe/read-only, which creates mild ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the tool genuinely supports many operations, and the length is justified by sectioned examples and quick-start templates. It front-loads the key safety property and then organizes content into logical categories. Some repetition across quick-start and element-operation examples could be trimmed, but it remains navigable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-operation read facade with no output schema, the description is remarkably complete: it covers all operation categories, gives representative examples, names supported element types, explains retry behavior, and even includes memory-specific tag filtering and convert_skill_format examples. An agent has enough information to select and invoke the right operation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only generic descriptions ('Operation parameters', 'Operation name to execute'), but the description supplies concrete parameter shapes for dozens of operations, including nested params like filters, variables, goalId, type, and query. This goes far beyond the schema and materially helps an agent construct valid invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Safe, read-only operations' and explicitly catalogues the full set of supported operations, element types, and categories. It clearly identifies this as the read-only tool among the create/update/delete/execute siblings, so an agent can distinguish it at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames when to use the tool: any read-only query or inspection, with the explicit statement 'These queries only read data and never modify server state.' It does not explicitly name sibling tools or say 'for writes use mcp_aql_create', but the read-only framing gives clear context without being misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_aql_updateADestructive
Modifying operations that overwrite data.
Supported operations: edit_element, upgrade_element
Element types: persona, skill, template, agent, memory, ensemble
These operations modify existing data, potentially overwriting previous values.
Note: Memories are append-only and do not support edit_element. Use addEntry (CREATE) to add new entries.
Quick start example: { operation: "edit_element", element_type: "persona", params: { element_name: "MyPersona", input: { description: "Updated description" } } } { operation: "edit_element", element_type: "persona", params: { element_name: "Friendly-Teacher", input: { instructions: "Updated behavioral directives." } } } { operation: "edit_element", element_type: "agent", params: { element_name: "code-reviewer", input: { instructions: "Updated agent behavioral profile.", goal: { template: "Complete: {task}" } } } } { operation: "upgrade_element", element_type: "agent", params: { element_name: "task-planner" } }
Discover required parameters — use mcp_aql_read: { operation: "introspect", params: { query: "operations", name: "edit_element" } }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Operation parameters | |
| operation | Yes | Operation name to execute | |
| operations | No | Array of operations for batch execution | |
| element_type | No | Target element type (optional) |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive behavior, and the description adds specificity: 'potentially overwriting previous values' and the memory append-only constraint. This tells the agent what is at risk and for which element types the operation is unsafe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The summary is front-loaded and information-dense. The quick-start examples are numerous but each demonstrates a different element type or operation, and every section has a clear purpose. Slightly longer than minimal, but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers operation types, element types, limitations, examples, and discovery. It doesn't define upgrade_element beyond its name or describe batch execution, but the input schema handles the batch property and the introspection pointer compensates for per-operation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema description coverage is 100%, the schema descriptions are generic. The tool description adds concrete operation values, element types, and multiple nested-parameter examples, and it recommends introspection to discover required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a clear modifying/overwrite action, and the supported operations and element types are enumerated. It is plainly differentiated from siblings by being the update tool, and the memory note even routes CREATE operations away.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells agents not to use edit_element on memories and points to addEntry (CREATE) as the correct alternative. It also instructs agents to use mcp_aql_read for introspecting required parameters. It doesn't spell out all create/delete routing, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.4/5.0
Disambiguation4/5
The five top-level tool names create/read/update/delete/execute map to clearly distinct CRUD-style actions, so misselection between tools is generally unlikely. However, mcp_aql_read is not truly read-only (it includes activate_element, deactivate_element, open_portfolio_browser, and permission_prompt), and mcp_aql_create bundles auth and deadlock operations, creating minor boundary ambiguity.
Naming Consistency4/5
Tool names follow a highly consistent mcp_aql_<verb> pattern, and most sub-operations use verb_noun snake_case. The pattern is not perfect because a few operations like addEntry, portfolio_element_manager, and beetlejuice_beetlejuice_beetlejuice break convention.
Tool Count4/5
Five tools is a reasonable surface size and maps neatly to a CRUD-plus-execution lifecycle. The count is slightly coarse for the server's actual breadth because each tool is a mega-router exposing dozens of operations, especially mcp_aql_read.
Completeness4/5
The set covers element CRUD, execution lifecycle, auth/OAuth, collections, portfolio, logs/metrics, and self-discovery, so most workflows have a path. Minor lifecycle edges such as explicitly removing from a portfolio/collection or listing all executions are not clearly surfaced, but they are not critical dead ends.
Maintenance
ActivityMaintained
ResponsivenessResponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
An MCP server that gives your AI access to the source code and docs of all public github repos
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Claude to manage software development projects with complete context awareness and code execution through Docker environments.244
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants like Claude to interact with GitHub repositories, issues, and pull requests.17MIT
- FlicenseNot gradedqualityNot gradedmaintenanceA Model Context Protocol server that provides comprehensive GitHub integration for Claude Desktop, allowing users to manage repositories, issues, and pull requests. It supports file operations, branch management, and repository searches through natural language commands.467
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DollhouseMCP/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server