Claude Enterprise: Give Every Agent Live Tools and Your Team's Playbooks

Claude has a particular strength that matters more in enterprise deployments than raw benchmark scores: it follows an instruction set carefully. Give it a written procedure and it will work through it rather than improvising something adjacent.

That makes the binding constraint obvious. The quality of a Claude agent in your organisation is largely a function of two inputs: whether it has your written procedure, and whether it currently has access to the systems that procedure assumes.

Both of those are supply problems, not model problems. A governed MCP layer solves them.

The configuration drift problem

Most Claude rollouts start the same way. Someone stands up a few MCP servers, writes a short guide, and asks teams to add the servers to their client. It works immediately, which is why it spreads.

The trouble is that a pasted configuration is a photograph. It captures what was true when someone took it. Six weeks later:

• Two teams are on different versions of the same connector.
• A restriction agreed with legal applies to whoever re-pasted and nobody else.
• A joiner has no tools until a colleague walks them through setup.
• A leaver's laptop still holds working credentials.
• The new system that was supposed to be the whole point of the programme is used by four people.

None of this is dramatic. It is just a steady divergence between the documented state and the operating state, and it compounds. The first time anyone measures it is usually during an audit.

Access as a property of identity

Palma assigns connectors per person by IdP group, from Entra ID or Okta. There is no per-user setup step and no credentials on laptops. Group membership is the source of truth, and it is evaluated when the session connects.

When a Claude agent performs its MCP initialize handshake against the gateway, it receives that person's current tool and skill set. The skill-set cache runs a 30-second TTL with push invalidation on commit, so a change committed by a platform owner is reflected within seconds rather than at the next onboarding cycle.

Install policy remains a platform decision: open, whitelist or restricted. A regulated business unit can run restricted while a research group runs open, on the same platform, without two deployments.

Skills: your best operator's process, distributed

Here is the distinction that matters. A tool is a verb — "send an email", "open a pull request", "run the report". A skill is the playbook that tells the agent when and how to use the verbs it already has.

Every organisation has a handful of people whose version of a process is noticeably better than everyone else's. They know which system is authoritative, which check catches the common error, and what the finished artefact should look like. That knowledge normally travels by apprenticeship, slowly, and leaves when they do.

A skill is that knowledge written down once and served to every agent that needs it. Versioned, scanned, scoped.

How Claude finds them

Palma exposes skills across four MCP surfaces:

• skill:// resources, with an index.json discovery manifest.
• Five meta-tools: search_skills, load_skill, save_skill, suggest_skill_improvement, skill_feedback.
• MCP prompts named skill__<name>.
• A Skills section injected into the initialize handshake instructions, capped at twelve entries with a "+N more" tail.

The handshake injection is the one that changes behaviour. An agent that is told at connection time which playbooks exist will go and load the relevant one. An agent that has to guess will not. search_skills is substring matching over the catalogue — deliberately literal, so naming conventions in your skill library do real work.

The write path matters as much as the read path. save_skill lets a good process be captured at the moment someone works it out. suggest_skill_improvement and skill_feedback let the people running a playbook push corrections back to its owner, which is how a library stays alive instead of ossifying.

The rules that keep this from becoming shadow IT

Handing every agent in the company a set of executable procedures is only responsible if the mechanism is disciplined:

• Versions are immutable, content-hashed snapshots. There is always an exact answer to "what did it follow".
• Only scanner-passed versions are ever served.
• Secrets are stripped from skill content before a version is stored.
• Visibility tiers: private, shared, public. Personal skills serve only their owner and are off by default per tenant.
• A tool reference in a skill documents a dependency. It never grants access to the tool. Reading a runbook is not the same as being allowed to run it.
• A skill that requires a tool cannot be attached directly to a space. It must travel in a pack, so the playbook never lands without the access it assumes.

That last constraint prevents the most expensive failure mode in agent deployments: a perfectly good procedure arriving at an agent that cannot execute step three, and the agent narrating around the gap instead of stopping.

Why serve this over MCP

Claude speaks MCP natively, so there is nothing to build. But the more important reason is what happens next year.

Serving capability over MCP makes the connector client-agnostic. The same connectors, skills and policies follow the person into whichever assistant they open. Switching or adding a client does not mean re-approving connectors, re-installing anything or re-auditing the access model. There is no SDK to adopt and no per-client integration project.

For a platform lead, that converts a client choice from a strategic commitment into an operational one. You can standardise on Claude now because it is the right tool now, and keep the freedom to run something else alongside it without duplicating the governance layer.

Palma is a Silver member of the Agentic AI Foundation and a member of the Linux Foundation, and builds on MCP as an open standard rather than a proprietary connector format.

Where to start

Pick one process where you know exactly who does it best, and write that process down as a skill. Put it in a pack with the connectors it depends on. Assign the pack to the group that does the work. Then watch what the agents produce against what that person would have produced.

That comparison is the honest measure of an agent programme, and it is a much better first milestone than counting how many tools you have connected.