Frequently Asked Questions

• MCP Server — exposes capabilities (tools, resources, prompts) over a defined protocol.
• MCP Client — the AI host application (e.g. Claude Desktop, an IDE plugin) that connects to servers.
• Transport — communication can happen over stdio (local process), HTTP with SSE, or Streamable HTTP.

The AI discovers what tools a server offers, then calls them by name with structured arguments — much like a function call — and receives structured results it can reason over.

• Tools — callable functions (e.g. search the web, run a SQL query, send an email).
• Resources — readable data sources the AI can access (e.g. files, database rows, API responses).
• Prompts — reusable prompt templates the AI or user can invoke.

# Install via npm
npx -y @modelcontextprotocol/server-filesystem /path/to/dir

# Or add to Claude Desktop config (~/.claude/claude_desktop_config.json)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
    }
  }
}

After restarting Claude Desktop the new tools will appear automatically in the conversation.

• stdio — the server is a local subprocess; the client communicates over stdin/stdout. Best for local tools.
• HTTP + SSE — the server runs as an HTTP service using Server-Sent Events for streaming. Best for remote or shared servers.
• Streamable HTTP — a newer, stateless variant that works over plain HTTP POST/GET without a persistent SSE connection.

# TypeScript
npm install @modelcontextprotocol/sdk

# Python
pip install mcp

Define your tools with a name, description, and JSON schema for their inputs. The SDK handles the protocol framing. Official quickstart guides are on modelcontextprotocol.io. Once your server is live, you can submit it to mAIndala so the community can discover it.

• Browse the mAIndala catalog — 3,400+ MCP servers.
• modelcontextprotocol.io — official specification, SDKs, and documentation.
• github.com/modelcontextprotocol/servers — Anthropic's reference server implementations.
• awesome-mcp-servers — curated community list on GitHub.

• Skills are authored by community members and published to the Skills catalog.
• Each Skill has a category, tags, and a short description so you can find the right one quickly.
• Prompts inside a Skill are gated — you must install a Skill before you can view or use its prompts.
• Authors can publish Skills as draft (private), active (public), or deprecated.

1. Browse or search the Skills catalog to find a Skill that fits your task.
2. Open the Skill detail page and click Install. This creates an install record tied to your account.
3. Once installed, the full prompt set is revealed — copy the prompts into Claude, your AI IDE, or any agent harness.
4. You can also access installed Skills programmatically via the mAIndala MCP Gateway's install_skill and get_skill tools.

After using a Skill you can leave a star rating to help the community discover the best ones.

Yes — the maindala CLI lets you install Skills and Agents directly into Claude Code, Cursor, GitHub Copilot, Windsurf, Zed, Continue, Cline, OpenClaw, or any plain markdown file, all from your terminal.

1. Get a personal API key

Go to your Profile and generate a personal API key (mk_...). Then save it:

npx maindala login mk_your_api_key_here

2. Install a Skill

# Auto-detects your tool from project files (CLAUDE.md, .cursor/, .clinerules, etc.)
npx maindala install linkedin-connection-request

# Or specify a format explicitly
npx maindala install linkedin-connection-request --format cursor

3. Install an Agent

npx maindala install agent/stock-analyst-pro --format claude

Supported formats

• claude — appends to CLAUDE.md (Claude Code full agent bundle)
• claude-skill — writes .claude/skills/<slug>/SKILL.md (Claude Code skill file)
• cursor — writes .cursor/rules/<slug>.mdc
• copilot — appends to .github/copilot-instructions.md
• windsurf — appends to .windsurfrules
• zed — writes to .rules
• continue — writes .continue/rules/<slug>.md
• cline — writes .clinerules/<slug>.md
• openclaw — writes .openclaw/skills/<slug>.md
• raw — writes <slug>.md in the current directory

Re-running the same install updates the existing block in-place (idempotent). The CLI is published as maindala on npm — no global install needed with npx.

1. Go to Create a Skill and fill in the name, category, and description.
2. Add one or more prompts — give each a label (e.g. "System prompt", "Step 1: Research") and the prompt text.
3. Save as draft to keep it private, or publish as active to make it discoverable by everyone.
4. Edit or deprecate your Skill at any time from its detail page.

Yes. When creating a new Agent, click “Build full agent” and describe what you want your agent to accomplish in plain language — for example, “Research competitors and draft a weekly competitive intelligence report”.

The platform analyzes your goal, searches the real Skills and MCP services catalog for relevant capabilities, and assembles a complete agent automatically — including nodes, routing logic, and execution configuration. You can review and adjust everything before saving.

• The builder selects only real Skills and MCP services that exist in the catalog — no hallucinated references.
• Routing and execution mode are set appropriately based on the capabilities selected.
• An AI notes section explains the choices made and suggests next steps.

Rate limit: 5 AI builds per minute per account. The builder is available on all plans.

• Each Agent has nodes (capabilities assigned a role in the workflow) and routes (edges between nodes with conditions like always, on_success, or on_failure).
• One node is marked as the entry point — where execution begins.
• Agents can be deployed to a live cloud endpoint, run locally via the CLI, or downloaded as a framework bundle for Claude, CrewAI, or LangGraph.

There are several ways to deploy an Agent depending on which AI platform you use.

Option 1 — mAIndala website (works with any platform)

1. Find an Agent in the Agents catalog and open its detail page.
2. Click Deploy. This downloads a JSON bundle containing the full Agent definition, all Skill prompts, and frameworkHints for Claude, CrewAI, and LangGraph.
3. Follow the framework hint for your platform to wire up the Agent in your harness.

Option 2 — Claude Code

Add the mAIndala MCP server to your project's .claude/settings.json:

{
  "mcpServers": {
    "maindala": {
      "type": "streamableHttp",
      "url": "https://mcp.maindala.com/mcp"
    }
  }
}

Then ask Claude: “Use the mAIndala MCP server to deploy the Stock Analyst Agent and set it up for LangGraph.” Claude will call the Deploy Agent tool and return the full bundle.

Option 3 — Claude Desktop

Add the following to your Claude Desktop config at ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), then restart Claude Desktop:

{
  "mcpServers": {
    "maindala": {
      "type": "streamableHttp",
      "url": "https://mcp.maindala.com/mcp"
    }
  }
}

Once connected, you can say: “Search mAIndala for stock analysis agents and deploy the best one.”

Option 4 — ChatGPT, Gemini, or Grok

These platforms don't yet support remote MCP servers directly from their chat UI. Instead, download the Agent bundle from mAIndala and paste the prompts manually:

• ChatGPT — deploy the Agent from the mAIndala website to get the bundle, then create a Custom GPT using the system prompt from the first Skill node. For API users, the openai-tool format gives you a ready-to-use tool schema.
• Gemini — copy the Agent's node prompts into a Gem or paste them as context. Vertex AI users can integrate via the gemini format bundle.
• Grok — paste the Agent's prompts into a custom instruction or system message. The raw format bundle gives you clean, platform-agnostic prompt text.

Platform-specific bundles are available via the mAIndala API: GET /agents/[slug]/package?format=openai-tool (or gemini, grok, claude, crewai, langgraph).

Yes — every account can deploy any Agent to a live cloud endpoint directly from mAIndala today, no infrastructure setup required. New accounts get a 30-day trial with full deployment access; after that, cloud deployment continues on a paid plan — with one exception, a Model Bake-off (comparing an agent across models) can still deploy temporarily on the Free plan, torn down automatically when it finishes.

1. Open an Agent in the Agents catalog and click Deploy to Cloud.
2. Select your Google Cloud Run credentials and LLM credentials (Anthropic, OpenAI, or Gemini).
3. Click Deploy. mAIndala provisions a container and returns a live HTTPS endpoint — usually within 60 seconds.
4. Open My Deployments to chat with the running agent, inspect per-step traces, and download any files the agent produced.

You bring your own Google Cloud and LLM credentials — mAIndala does not charge for the underlying infrastructure. You can also download the JSON bundle for manual deployment in any framework, or run any agent locally for free and indefinitely using npx maindala run agent/<slug>.

Yes. Every new account gets a 30-day trial with full cloud deployment: live chat, per-step traces, persistent agent memory, file outputs, and autonomous scheduled runs. After the trial, cloud deployment continues on a paid plan — except for a Model Bake-off, which the Free plan can always run: up to three models compared side by side on one cloud provider, deployed temporarily and torn down automatically when it completes. You can also run any agent locally, for free and indefinitely, with npx maindala run agent/<slug>.

You bring your own Google Cloud credentials and LLM API key — mAIndala does not charge for the underlying infrastructure. Visit My Deployments to see everything currently running.

Yes. When deploying an agent to the cloud, you can configure a schedule so the agent runs automatically without any manual trigger.

• Choose from preset intervals — hourly, every 6 hours, every 12 hours, daily, or weekly.
• Or enter a custom cron expression for precise scheduling (e.g. every weekday at 8 AM).
• Each scheduled run is recorded in the activity log in My Deployments — including trigger time, status, duration, and a summary of what the agent produced.
• Scheduled agents are ideal for autonomous monitoring, weekly reporting, or any task that benefits from regular, hands-off execution.

Yes. Deployed agents can store and retrieve facts across sessions using persistent memory — so an agent can remember preferences, prior research, or accumulated context between runs.

• Memory is scoped to each deployment — different deployments of the same agent have separate memory stores.
• Agents can read, write, and delete memory entries during a run. Memory is loaded as context at the start of every execution.
• This is especially powerful for autonomous scheduled agents that need to track state over time — for example, remembering which topics have already been researched, or which reports have been sent.

Yes — any agent in the catalog can run on your laptop with a single CLI command, using your own LLM API key. No mAIndala cloud subscription, no cloud provider account required.

# Run any agent locally (requires Docker)
npx maindala run agent/stock-analyst-pro --provider anthropic --llm-key sk-ant-...

# Run with a specific input
npx maindala run agent/seo-growth-agent --input "Analyze our blog at maindala.com"

# Run an agent team locally
npx maindala run agent/stock-analyst-pro --team report-writer-agent

• Server mode — starts a local HTTPS endpoint you can chat with at http://localhost:<port>.
• One-shot mode — pass --input to run the agent with a single prompt, print the result, and exit.
• Requires Docker installed locally. The agent image is pulled automatically on first run.
• Supports all LLM providers: Anthropic, OpenAI, Gemini, and xAI.

Local execution is free for all mAIndala users, including Free plan. A personal API key (mk_...) is required to download the agent bundle. Generate one from your Profile.

An Agent Team is two or more Agents deployed together on a single cloud instance. One agent is the Entry Agent — the one you chat with. The others are Worker Agents — specialists the entry agent can delegate sub-tasks to.

• The entry agent sees each peer as a callable tool and decides autonomously when to delegate.
• Worker agents run on the same container — delegation has near-zero latency and no extra network hops.
• Every step — from the entry agent and from all workers — appears in the chat's step log, tagged with which agent produced it.
• Teams support up to 5 agents (1 entry + 4 workers).

Example: pair a Stock Analyst Agent (entry) with a Report Writer Agent (worker). You ask "Give me a full analysis of NVDA" — the entry agent gathers data, then delegates report formatting to the writer.

1. Go to the Agents catalog and check the checkbox on two or more Agent cards. A sticky footer appears showing how many are selected.
2. The first agent selected becomes the Entry Agent (shown with a crown badge). Click the crown icon on any other card to reassign it.
3. Click Deploy as Team → in the footer.
4. Choose cloud credentials, LLM provider, and model, then click Deploy.
5. Your team appears in My Deployments with a TEAM badge. Chat with it there — all delegation happens automatically.

Agent Teams can also be run locally using npx maindala run agent/entry-agent --team worker-agent-slug.

Yes. mAIndala deployed agents support Agent-to-Agent (A2A) calls — a deployed agent can invoke another deployed agent as a sub-task at runtime, so work can be delegated dynamically rather than wired up in advance.

• How it works: Agents automatically receive a call_agent tool. When the LLM decides a task is best handled by a specialist, it calls that tool with the target agent's slug and a task description. mAIndala looks up the target agent's live endpoint and routes the call there.
• Difference from Agent Teams: Teams are statically configured at deploy time (fixed set of workers). A2A calls are dynamic — any running agent can reach any other agent in the registry at runtime, unlike Agent Teams which are wired up in advance.
• Governed, not open: Within an organization, delegations are not open-ended — each call is checked against the organization's policy before it proceeds, and every call is recorded in the activity log. Reachability between agents is a governed decision, not an open mesh.
• Loop prevention: An agent cannot call itself. A2A calls are one-hop by default to prevent runaway delegation chains.

A2A is available on all paid plans. The A2A registry is powered by the mAIndala catalog — agents are discoverable by slug as soon as they are deployed.

• Skill — a single capability. One task, one prompt set. Used directly by a human or an agent to accomplish a specific thing.
• Agent — a workflow. Multiple Skills stitched together with routing logic to achieve a broader goal automatically.

A Skill is a building block; an Agent is the finished assembly. You can think of Skills as functions and Agents as programs.

A well-designed Agent might use an MCP server for data retrieval at one node and a Skill's prompt to interpret and format the results at the next. Together they form a complete agentic system: MCP handles the “hands”, Skills and Agents handle the “brain”.

Yes. The maindala CLI includes a live activity stream you can run from your terminal — npx maindala tail — with no mAIndala account required. It shows metadata about what your agents are doing: which tools were called, what was decided, and how long it took. Prompts and payload contents are never transmitted.

Yes. The public catalog API is available at api.maindala.com, covering MCP services, Skills, and Agents, including trust scan results. The full endpoint list is published at maindala.com/llms.txt.

Yes. A Model Bake-off runs one agent on several models at once, side by side, using the same input for every one. You see each model's output next to its real cost, response time, and token counts, so you can trade quality against price with actual figures rather than guesses. Start one from any agent's page.

Every variant is deployed and run separately, so models are not competing for a shared runtime — and every one receives a byte-identical input, recorded with a fingerprint so you can prove the comparison was fair. Each variant also gets a discarded warm-up run first, so the response times you compare are not just a race between container start-ups. Trying models by hand gives you impressions; a bake-off gives you a record.

Yes, on Teams and above. The judge is a real agent in the catalog — model-bakeoff-judge — not a hidden prompt, so you can read exactly how it evaluates, fork it, and change the rubric for your own criteria. It scores each output, explains its reasoning, and can legitimately return "no meaningful difference" rather than inventing a winner between equivalent answers. If you pick a judge model that is also one of the models being tested, the result says so.

Every plan can run one. Free covers three models per bake-off, one at a time, on a single cloud provider, with the containers torn down automatically when it finishes. Teams raises the limits, lets you keep variants running, and adds the AI judge. Business adds a custom judge rubric. See the pricing page for the full comparison.

• MCP servers run with the permissions you grant them — a file-system server only accesses paths you configure.
• Always review what a server claims to do before connecting your AI agent to it.
• Prefer servers from known, reputable providers or open-source projects you can audit.
• The MCP spec includes an authorization framework (OAuth 2.1) for servers that need user-delegated access.

On mAIndala, every listed service is automatically analyzed for security and receives a mAIndala Verified badge. Community ratings and reviews provide additional signal. Look for high-rated, Verified listings before connecting.

mAIndala Verified is a trust badge applied to every Skill, Agent, and MCP service in the catalog after an automated security analysis. Each item receives one of three ratings:

• Verified — No security indicators were detected. The item meets mAIndala's safety criteria.
• Partial — Some concerns were flagged. The item is still listed; review the Trust tab before using it.
• Unverified — The item has not yet been analyzed or lacks sufficient information to assess.

The analysis is aligned with OWASP Agentic AI security principles, covering categories such as prompt injection risk, data exfiltration indicators, and undisclosed behavior. Verified status is re-evaluated when content changes.

Verified status is one signal, not a guarantee. For MCP servers that will run with elevated permissions, also review the source code before connecting to your agent.

Look for the mAIndala Verified badge on any Skill, Agent, or MCP service detail page. The badge shows how many automated security checks ran and how recently the item was scanned, so you can tell a current result from a stale one. You can see the full breakdown by clicking the Trust tab on any listing.

Additional signals to check:

• Community ratings — items that have not been reviewed by the community are labelled Unrated rather than given a score; where real reviews exist, they appear here. GitHub stars are shown as stars, not as ratings.
• Author reputation — items authored by a group or organization with a track record carry more weight.
• Repository link — for MCP servers, you can audit the source code directly before connecting.
• Publisher — check who published the listing before running it with elevated permissions.

Security is always layered. mAIndala Verified helps you make an informed decision quickly — combine it with your own judgment for high-stakes deployments.

Yes. The public keys used to sign agent identities are published at a standard well-known endpoint, so your own security tooling can verify a signature independently — offline, with no mAIndala account and no call back to us. Verification does not depend on our availability.

Most MCP catalogs are directories — they list servers with basic metadata and let you search by name or category. mAIndala is the trust & governance control plane for agentic AI:

• Automated Trust verification — every Skill, Agent, and MCP service receives a Verified badge after security analysis. No other MCP catalog does this at scale.
• Private team catalogs — enterprises curate and govern their own approved AI stack, invisible to the public. Content can be published to the community on their timeline.
• One-click cloud deployment — any Agent deploys to a live Google Cloud Run endpoint in under 60 seconds.
• AI Agent Builder — describe a goal; the platform assembles a complete agent from real catalog entries automatically.
• Local execution — run any agent locally in Docker with one CLI command, free on all plans.
• Autonomous scheduling + persistent memory — agents can run on a schedule and remember context across sessions.
• Multi-provider LLM neutrality — supports Anthropic, OpenAI, Gemini, and xAI.
• External agent governance — govern agents built on LangGraph, CrewAI, Copilot Studio, Bedrock, or in-house — not just agents built on mAIndala — with a single inventory, OWASP-aligned risk scanning, a policy gateway, and a one-click kill-switch.

mAIndala also has an agent-native MCP Gateway — AI agents can discover services, install Skills, and deploy Agents programmatically at inference time, without human intervention.

Every service, Skill, and Agent detail page has a Report Listing action. Reports are queued for the mAIndala team to review, and repeat or serious issues can result in a listing being removed from the catalog.

Skills come from two places: those authored by mAIndala, and those imported from public sources. Imported Skills show their real origin rather than being attributed to mAIndala, so you can always see where a Skill came from before you install it.

Yes. Each variant's output is scanned for prompt-injection and secret-leakage patterns, and any findings are shown on that variant's result. Because every model received the same input, a finding on one variant and not another is a real difference in what that model produced — not a difference in what it was asked. This reports what was found; it is not a safety certification.

A mandala (from Sanskrit, meaning “circle”) is a geometric design used across Hindu, Buddhist, and other contemplative traditions to represent the universe: a unified center surrounded by concentric, symmetrical layers — each part distinct, yet organized in relation to the whole. Below are three illustrative examples of that pattern.

That structure is the whole point of our name. mAIndala — “AI” at the center of “mandala” — represents the platform's role as that unified center: the trusted governance layer every agent, tool, and connection in your organization's AI ecosystem orbits around. Just as a mandala holds many distinct forms in one coherent, balanced pattern, mAIndala holds every agent you deploy — plus every agent your teams build or connect from other platforms — in a single governed system: one inventory, one policy layer, one audit trail, one kill-switch, no matter how many agents, tools, or providers make up the outer rings.

mAIndala is pronounced “main-dah-la” — the word “mandala” with “AI” woven into its center. It is an enterprise agent-governance platform for autonomous AI agents. The name is a deliberate statement of the platform's vision: not another isolated tool in the ecosystem, but the trusted center that brings order, visibility, and governance to the whole. See how this shapes our architecture on the About page.

It governs agents at the boundaries they cross:

• Agent inventory — a single registry with an Agent Bill of Materials for every agent in your org.
• Risk scanning — automated, OWASP-aligned checks with an approve/block workflow and drift alerts when an approved agent later changes.
• Tool & data control — a policy-controlled gateway decides which tools and data each agent may reach, with rate limits, time-of-day windows, and data-loss-prevention redaction.
• Credential brokering — scoped, short-lived credentials the agent never holds directly, with a full audit trail of every call.
• Kill-switch — instantly cut off any agent's access with one click.

Yes. Organizations can export a signed, tamper-evident evidence pack — a time-bounded snapshot of governance records: the agent inventory, risk-scan results, publish approvals, every policy decision made at the gateway, execution history, and usage records.

• Each pack is cryptographically signed and carries an independent, third-party timestamp, so recipients can confirm the records existed at that time and have not been altered.
• Packs can be verified entirely offline — an auditor needs no mAIndala account and no network access: npx maindala verify-pack <folder>.

An evidence pack is a record of what your governance controls did — mAIndala exports and protects your records; it does not certify compliance with any law or standard. Evidence packs are an Enterprise capability, enabled per organization.

Both. Before deployment, an agent's definition is scanned for security and prompt-safety risks. While it runs, agents deployed through mAIndala are also checked against your organization's guardrails at the point where they call a model — so a policy applies to what the agent actually does, not only to what it declared it would do.

Yes. When one agent delegates work to another inside your organization, that delegation is checked against your policy before it proceeds, and the call is recorded. You can decide which agents may reach which, and review the full history of what was delegated to whom.

Agents governed by an organization can carry a verifiable identity, so when an agent calls a tool or another agent, the platform can confirm it is the agent it claims to be rather than something impersonating it. Identities can be revoked, which stops anything presenting that identity from being accepted, typically within seconds.

Every governed call is recorded with the agent and identity behind it, which control allowed or blocked it, and fingerprints of the request and the result. The record distinguishes a call that completed from one that was allowed and then failed or timed out — so an allowed call is never recorded as finished when it isn't known to have finished. Org admins can review this in the governance dashboard or export it in a signed evidence pack.

Yes. Each time an agent is scanned — when it's first registered, and on every re-scan — mAIndala records that version of its definition alongside the trust result, rather than overwriting the previous one. Earlier versions stay intact, so you can see what changed and when. Note that this records scans, not edits: after changing an agent's details, re-scan to capture the new version.

That's your organization's choice. By default a governed call proceeds when the policy check can't be completed, so an outage doesn't halt your agents. Organizations that would rather stop than risk an ungoverned call can turn on fail-closed in Governance → Policy, which denies calls whenever policy can't be evaluated.

Yes. Organizations can set spending limits for agent activity and track usage against them, broken down by user, group, and model. This makes a runaway agent a budgeting question rather than a surprise invoice.

A scheduled sweep checks every registered external agent for seven signal types — first-seen tools, call-rate spikes, unusual response volume, off-hours activity, definition drift, denied calls, and dormant agents waking up — and raises an alert in your org's Governance dashboard.

Two of the highest-confidence signals (a burst of denied calls, or an unusual spike in response volume) can also trigger an automatic, temporary suspension — but only if your org admin has explicitly opted in per rule, it self-lifts after 15 minutes, and a human can restore access with one click at any time. Alerts are always visible in-app; email notification is a separate, off-by-default setting your org admin can enable.

Yes. Model-selection decisions are included in the signed evidence pack an organization can export — each bake-off with the input fingerprint that proves every model got the same task, the exact agent version tested, each model's cost and token usage, any output-safety findings, and the recorded verdict. Like the rest of the pack, it carries an independent third-party timestamp and can be verified offline. Evidence packs are an Enterprise capability, enabled per organization.

• Public groups are discoverable in the Groups directory and open to anyone who wants to join.
• Private groups are invite-only — members join via an email invite link sent by an admin.
• Groups are useful for enterprises curating a vetted tool list, developer communities around a theme, or teams that want a focused, noise-free catalog.

To create: Any signed-in user can go to Create a Group, choose a name and slug, set visibility (public or private), and add a description. You become the group admin automatically.

To join a public group: Browse the Groups directory, find a group, and click Join. No approval required for public groups.

To join a private group: An admin must invite you by email. Click the link in the invitation email to accept and become a member.

• The Browse page filters to show only that group's curated service list instead of the full public catalog.
• Searches and category filters operate within the curated list.
• Group API keys grant access to the group's curated Skills and Agents — no individual install or deploy record required for curated items.
• Group admins manage services, skills, agents, members, and API keys from the group admin panel.
• You can switch back to the full catalog at any time by clearing your active group from the Groups menu.

You can be a member of multiple groups and switch between them freely.

• Filtered MCP catalog — all MCP Gateway tool calls (list_services, search_services, etc.) automatically filter to the group's curated service list.
• Skill downloads — GET /skills/[slug]/package succeeds for any Skill the group admin has curated, without needing an individual install record.
• Agent packages — GET /agents/[slug]/package succeeds for any Agent the group admin has curated, without needing an individual deploy record.

Group admins generate and revoke API keys from the API Keys tab on the group admin page (/groups/[slug]/admin). Use Group API keys when building agents that should only ever see your team's approved tools, skills, and agents.

Group admins can hand-pick which Skills and Agents are available to their members from the group admin page (/groups/[slug]/admin):

• Open the Skills tab, search the Skills catalog by name, and click Addnext to any Skill you want to curate.
• Open the Agents tab and do the same for Agents.
• Curated items appear in the list below the search — click the trash icon to remove any entry.

Once a Skill or Agent is curated, any member holding a Group API key can download its package via the CLI or API without needing to individually install or deploy it first:

# Install a group-curated Skill
MAINDALA_API_KEY=mg_... npx maindala install financial-analysis

# Install a group-curated Agent
MAINDALA_API_KEY=mg_... npx maindala install agent/stock-analyst-pro

This is designed for teams that want to standardise on a set of approved AI capabilities and distribute them to members without requiring each person to manage their own installs.

Yes — any group can create Skills and Agents with group-private visibility, accessible only to members of that group, and can also add private MCP server URLs to their group's catalog.

• Private Skills and Agents appear only in your group's catalog — they are never discoverable by users outside the group.
• Group members can install and use private Skills and download private Agent bundles using a Group API key.
• When you are ready to share more broadly, a publish flywheel lets group admins promote content: group-private → unlisted (reachable by link) → public (in the main catalog).
• Each step in the publish flywheel triggers a security analysis. Content must pass the quality gate before advancing.

Private catalog management is on the Private Catalog tab of your group admin page at /groups/[slug]/admin.