Share an AI tool setup with a team, once

What does "share an AI tool setup with a team" mean in practice?

You have an AI setup that works. One person built it: a set of tools from Notion, Stripe and Jira, named sensibly, with a couple of arguments locked down. Now eight other people want it. The honest options look like writing a runbook, pasting a JSON file into a shared drive, or sitting with each of them for twenty minutes. To share an AI tool setup with a team gets harder still when the people who need the tools sit in support, finance or sales rather than in a terminal. Elaichi lets one person build a toolbox once and share it, and everyone else adds one MCP address.

In Elaichi there are two ways to do it. They differ in one place: whose account the calls run on. A toolbox shared at the use level runs every call on the connection pinned into its entries. A template shared at the use level is copied by each person, who picks their own connection for each app as they copy it. Both end the same way for the team: each person adds one address in their AI client and approves their own sign-in.

MCP is the protocol AI clients use to call tools. An endpoint is the address they call. Elaichi serves MCP at one endpoint, POST https://api.elaichi.ai/mcp, the same string for every organization. Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL.

Toolbox or template: which one fits your team?

Use a toolbox when the tools should run on one shared account. Use a template when each person should act as themselves in the app.

A stored toolbox is a named list of entries. Each entry is a connector tool pinned to one connection, or a synthetic tool. When you share that toolbox at the use level, every grantee's call runs through the connection pinned in the entry, under the authority of whoever pinned it. A stored toolbox never substitutes the caller's own connection for an entry. That is the point of it: the billing account, the company Stripe connection, the shared Notion workspace behave identically for everyone. A read-only Stripe toolbox shared with support is the shape this takes in practice.

A template stores no connection at all. Its entries have no connection field, and the API refuses a connection_id on a template entry. Sharing a template at use lets each person stamp it, which copies its entries into a new toolbox they own. During the stamp, they pick a connection per connector from their own connections or ones shared with them. Each person's copy then runs on the accounts they picked, so the third-party app sees them and applies their own permissions there.

Sharing a template gives nobody a toolbox. It gives them the right to make one. A connector the stamper skipped is left needing a connection: the entry stays listed but is not advertised or runnable until someone pins one.

Sharing a connection, toolbox, template or connector comes with Gold; on Personal the share routes answer 403. Removing a grant is never gated, so a workspace that drops to Personal can always take back what it set.

How do you build and share the toolbox once?

Build it, pin the connections, share it with the team at use, then write the skill. That order matters, because the skill is guidance about tools that already exist.

1. Connect the account the team should run on. Add the connection in Elaichi. Leave it unshared if the only path you want the team to have is through the toolbox. A toolbox grantee who runs a tool through an entry pinned to an unshared connection never gains their own reach to that connection.
2. Create the toolbox and add entries. Up to 1,000 entries. Each one can be renamed, re-described, given a replacement input schema, given defaults, or given frozen parameters, which are argument values written into the entry that a caller cannot override.
3. Share it with the team at use. View sees the configuration, including every entry and its frozen values. Use also runs its tools. Edit also changes entries and shares it. Sharing needs edit access or ownership plus the toolbox:share permission.
4. Write a skill. A toolbox can carry up to 10,000 characters of owner-written markdown telling the AI how to use its tools. It grants nothing. Every surface that shows a skill carries the notice that it is guidance written by the resource's owner, not instructions from Elaichi, and that it cannot grant any access.

Permission levels, concretely:

Worked example. A support lead connects the team's shared Zendesk account and creates a toolbox named Support Zendesk. They add the "List all Zendesk tickets" and "Update a Zendesk ticket by ID" entries. On both, they lock the ticket's brand, so every update stays in one brand whatever the model sends. They share the toolbox at use with the support team, then write a 400-character skill: "Always search for an existing ticket before creating one. Never close a ticket without a resolution note." Eight agents add https://api.elaichi.ai/mcp in Claude and consent once. Each picks "Only the ones I pick" and selects Support Zendesk.

Frozen parameters are the piece people ask about most. A frozen key is removed from the tool's advertised input schema, so the client cannot set it. At execution the frozen value is merged over the caller's arguments. The model can still see what is frozen, and often the value: Elaichi prefixes the tool's description with a note such as "(frozen: folder_id=HR)", and anyone who can open the toolbox reads every frozen value in full. The guarantee is that the AI cannot change a locked value, not that it cannot see one. Read locking an argument before you rely on it.

A freeze only holds on calls that run through the entry carrying it. Anyone who can use the connection directly has the same tool without the freeze, in their All tools toolbox. If the lock matters, keep the connection unshared and share only the toolbox.

How do you share a template so each person uses their own account?

Share the template at use, and tell the team to stamp it and pick their own connection for each app.

In the console, the stamp dialog is "Use this template". It shows one connection picker per connector, each starting at "Skip and add a connection later", and sends only the connections the person picks. It does not pre-fill anything from their own connections, and the API never fills a connection by itself. A connection they name has to be visible to them, match the entry's connector, be one they can use, and have finished sign-in. Otherwise the whole stamp fails rather than leaving that entry empty.

Stamping copies the entries once. The new toolbox keeps the template's id as provenance, not as a live link, so editing or deleting the template later never changes a toolbox already stamped from it. It also copies the template's skill, attributed to whoever wrote it, and later edits to the template's skill do not reach the copies.

The stamper becomes the owner of their toolbox and the delegator on every entry that received a connection. Stamping needs toolbox:create; attaching shares in the same request also needs toolbox:share.

This is the only shape that gives a team per-person permissions in the app. Tools that run on each person's own account come from each person's own connections: their All tools toolbox, a toolbox they built on their own connections, or a template each person stamps. A single toolbox shared with a team cannot do it, and per-rep CRM access is the common place that matters.

What does each teammate do in Claude, ChatGPT or Cursor?

They add one address and approve their own sign-in. There is no per-user JSON file, no API key to paste, and no per-team URL.

The address is https://api.elaichi.ai/mcp, the same string for every organization. Clients register themselves through OAuth dynamic client registration (RFC 7591), so nobody looks up a client ID or a secret. In the Elaichi web app, "Connect your AI client" shows the endpoint with a copy button and setup steps for Claude, ChatGPT and Cursor.

On Elaichi's consent screen each person picks the organization and ticks the scopes the client asked for. When "Run your connected tools" is ticked, they also choose between "All my tools" and "Only the ones I pick". "All my tools" reaches everything they can run today and accounts they connect later. "Only the ones I pick" names one to 50 stored toolboxes they can use, re-checked on every call. For a team rollout built on one shared toolbox, picking it is the tighter choice.

The per-client steps are already written up: Claude, ChatGPT and Cursor across a team. If the tools do not appear afterwards, work through the missing-tools checklist rather than re-sharing anything.

Elaichi never lists connected tools one by one in a client's tool list, however few there are. The model finds a connected tool with search_tools and runs it with read_tool (a read) or execute_tool (anything), or with run_code under Code Mode. Each search result says which of the two to use. A tool list holding only elaichi__ operations does not mean the share failed.

What breaks a shared toolbox, and how do you fix it?

The usual failure is delegation, not sharing. Each entry records the person who pinned its connection. If that person loses use on the connection or stops being an active member, the entry resolves as unmet for everyone, the toolbox owner included. It stays listed but is not advertised or runnable.

Failure mode, cause, and fix:

It recovers by itself if the delegator again holds use as an active member. Otherwise somebody with edit on the toolbox who holds use on the connection re-pins it, with the console's "Re-pin to my access", and becomes the new delegator. Nothing re-pins automatically.

This is why the person whose connection backs a shared toolbox should be somebody who will stay. If they leave, offboarding can transfer the connection. The entries they pinned keep them as delegator and stop resolving until someone re-pins them.

Two more things change what a grantee actually sees. Restrictions are evaluated for the person calling, not the delegator, so a tool blocked for someone is withheld inside every toolbox entry for them, frozen or not. In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call. Role, team and restriction changes are slower: about two minutes.

How do you govern what the shared setup can reach?

Sharing decides who may use a resource. It does not decide which connectors and tools a person may reach at all. That is a separate layer: restrictions, written on a role or on one member, and enforced on every call. The clamp runs on every path that reaches a connected tool: tools/call, execute_tool, read_tool, a toolbox execution, each step of a synthetic tool, and a run_code program. There is no organization-wide restriction and no team restriction. A boundary for a team is written on the role its members hold, or on each member.

Do not try to set that boundary in the AI client. Per-tool client permissions see Elaichi's connected tools as a few tool names, execute_tool, read_tool and run_code, so they cannot tell one connected app from another. Gating execute_tool alone leaves read_tool and run_code. Per-app and per-tool control is set in Elaichi, as restrictions.

execute_tool is only a naming indirection: it unwraps to the tool name and arguments it was given and meets the same gates as a direct call by that name. read_tool unwraps the same way and goes through the same gates, then refuses anything that is not a connected read. Neither is a lower permission level.

The practical pairing for a team rollout is a shared toolbox for the setup and a restriction for the boundary. Block the tools nobody on that role should run, then share the toolbox that holds the ones they should. Do not try to close an unfrozen path with a restriction: a restriction that blocks a tool for a member blocks it inside the frozen toolbox entry too. Close that path by not sharing the connection.

Every call that reaches execution writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), so a shared toolbox does not blur who did what. The three layers and how they interact are set out in roles, restrictions and ACLs, and the first-week order of operations is in the setup checklist.

Can you mix authored connectors and vendors' own MCP servers?

Yes. Toolboxes and templates draw from one catalog, and it holds two kinds of connector.

The sharing mechanics are the same for both. A native MCP connector's tools come through the same address and the same search_tools, read_tool and execute_tool. Members connect with their own sign-in at the vendor, and a connection someone shares runs on its owner's account. Restrictions bind a remote tool exactly as they bind any other, and every call that runs is written to the audit log.

The vendor builds and maintains that server's tools. A report about how a tool behaves goes to the vendor's support contact, shown on the connector's page. Keep that in mind when you write the skill. If the apps your team needs are not yet connected, start at the connector catalog; 650+ are listed.

When you do not need any of this

If your whole team is three engineers in the same terminal, a committed MCP config file in the repository is a shorter path. Cursor reads MCP servers from .cursor/mcp.json in a project and from ~/.cursor/mcp.json in the home directory. That is from Cursor's own docs, checked October 2026. Claude Code keeps project-scope servers in .mcp.json at the project root, shared with the team through version control. That is from Anthropic's docs, checked October 2026. For a small all-engineer team it is less work than any control plane: no OAuth consent screen, no roles, no audit log, just a file in git.

It stops being the right answer when the people who need the tools do not use a terminal. It also stops when the connection behind a tool should not be a credential on each laptop, or when you need one place that records who ran what. The wider "do I need this yet" argument is laid out in when you don't need an MCP gateway.

There is also a middle case. Suppose the one thing you want is for every person to run on their own account, with no shared setup at all. Then skip toolboxes entirely: each person connects their own accounts and consents with "All my tools." Sharing is for when the setup itself should be the same for everybody: the names, the locked arguments and the skill.

Mechanics described here (toolbox, template, frozen parameters, search_tools, read_tool and execute_tool) are Elaichi-specific implementations of the general MCP protocol; other MCP gateways implement team sharing differently or not at all. This page describes how Elaichi does it, checked against the current product as of October 2026.