Team toolboxes
Pick the tools a job needs, name them clearly, lock the values that must not change and write down how to use them. Every teammate gets that same kit in Claude, ChatGPT, Cursor or any other MCP client.
In short
An Elaichi toolbox is a named set of tools for one job, built from your connected apps.
Each tool in it can be renamed and re-described for the model, given defaults or frozen values the AI cannot change, and switched on or off. A toolbox can also carry a skill: written guidance, up to 10,000 characters, on how to use its tools well. Share it with a person, a team or the whole organization, or publish it as a template others stamp their own copy from. Because it lives in Elaichi rather than in one chatbot, every client connected to it is served the same tools and the same guidance.
What changes
Today
With Elaichi
Who it is for
You know how the work should be done, and want every teammate’s AI to start from the same tools and the same instructions.
You roll out a way of working and want it to land the same in Claude, ChatGPT and Cursor, without writing it up once per client.
You want the tools a team relies on built and owned in one place, with roles, restrictions and the audit log still in force.
Real situations
A sales manager builds a deal-review toolbox from Salesforce reads and the Slack tool that posts to the team’s deals channel, with the channel frozen. The skill spells out how the team reviews a deal. Reps open it from ChatGPT or Claude and start from the same tools and the same steps.
A support lead builds an escalation toolbox from Zendesk and Jira: read the ticket, then open an issue in the engineering project, with the project frozen. The skill lists what every escalation must include, so an issue reads the same whichever agent and whichever client filed it.
A platform team publishes an incident-response template with Sentry, Jira and Notion tools and a skill for the first hour of an incident. Each squad stamps its own toolbox from it, maps its own connections and gets a copy of the skill to adapt. Later edits to the template never change a squad’s copy.
Setup
Four steps, in the order an admin takes them.
Create a toolbox and add the tools the job needs from your connected apps, including synthetic tools that chain several steps. Switch off anything the team should not use.
Rename a tool and rewrite its description so the model knows when to reach for it, set default values, and freeze the values that must never change.
Add written guidance on how to use the toolbox, up to 10,000 characters. Edits are versioned, and the skill is flagged when tools are added, removed or renamed under it.
Share the toolbox at use with a person, a team or the organization, or share a template so teams stamp their own. Each person then connects their AI client to the toolbox once.
Compare your options
| Aspect | Prompts passed around | Each AI client’s own connectors | An Elaichi toolbox |
|---|---|---|---|
| Tools in reach | Everything each person connected | Whatever each person attached in that client | The tools the toolbox holds |
| How tools are described | As each app ships them | As each app ships them | Renamed and described for the job |
| Values that must not change | Repeated in every prompt | Whatever the client’s settings offer | Frozen; the AI cannot change them |
| The know-how | Shared in chats and docs | Set up again in each client | A versioned skill that travels with the toolbox |
| A second AI client | Bring the prompts over | Set it up again in that client | Connect it to the same toolbox |
| Updating it for everyone | Re-shared by hand | Changed client by client | Edit the toolbox once |
Under the hood
The specifics a careful reviewer checks, answered up front.
Guidance, not permission. A skill grants nothing. Elaichi serves it with a fixed notice that it is the owner’s guidance, not instructions from Elaichi or the user, and every call still runs under the person’s own role and restrictions.
A rename cannot slip a restriction. Restrictions check the catalog tool’s own name and operation, so renaming a tool or overriding its schema inside a toolbox never gets it past a block.
Templates copy once. A toolbox stamped from a template gets its own copy of the entries and the skill. Later edits to the template never change it, so a team’s working copy changes only when the team changes it.
Where the guidance shows up. Elaichi names a toolbox’s skill in its server instructions and offers it as a resource to any client connected to chosen toolboxes. A client connected to All my tools is offered neither, and whether a client passes server instructions to its model is the client’s choice.
Share a capability, not a secret. A colleague works through your connection without ever seeing it.
Read the use caseConnect each app once and use it from Claude, ChatGPT, Cursor, and any MCP client.
Read the use caseDecide who can act, choose which tools each agent can use, and keep an attributed record of every call that runs.
Read the use caseSee the whole picture in the product tour and the security model.
FAQ
A named set of tools for one job, built from your connected apps. Each tool in it can be renamed and re-described, given defaults or frozen values, and switched on or off, and the toolbox can carry a skill: written guidance on how to use it.
Owner-written markdown guidance on how to use a toolbox’s tools, up to 10,000 characters. It is kept in a version history, flagged when tools are added, removed or renamed under it, and served with a notice that it is guidance and grants no access.
Elaichi serves the same tools, frozen values and skill to every client connected to the toolbox, from one endpoint. Each client’s own model still decides how to use them, and whether a client passes Elaichi’s instructions to its model is the client’s choice.
Connect the client to chosen toolboxes on Elaichi’s consent screen. Elaichi then names those toolboxes’ skills in its server instructions and offers each one as a resource the client can read. A client connected to All my tools is not offered skills.
Yes. Freeze it in the toolbox entry. Frozen values are merged in when the tool runs, so the AI cannot change them. The model may still see the value; it just cannot override it.
No. Someone you share it with at use runs its tools through the connections pinned in it, without access of their own to those connections. Their own role and restrictions still apply to every call.
Sharing a toolbox gives people that same toolbox, so your edits reach them. Sharing a template lets each person or team stamp their own copy, with their own connections and a copy of the skill, and later template edits do not reach copies already made.
Each client’s own connectors are set up per person, inside that client, with the tools each app ships. A toolbox is built once in Elaichi, so the same chosen tools, frozen values and guidance reach every client a teammate connects, under one set of roles and restrictions and one audit log.
Start a trial, build a toolbox with a skill, and open it from two AI clients.
and any other MCP client, or the Elaichi Agent.
