Catalogs of skills and MCP servers: so the team doesn't build the same thing twice

Over two weeks, several pieces of news came out on one subject: how to store instructions and connections for AI tools so the whole team takes one proven version. Camunda released a catalog of approved blocks, Workato showed an MCP server that updates itself, and HubSpot and Google spelled out where skills fit. For a business owner the question is simple: who in the company holds "how we do this thing," and who is responsible when it changes.

What came out

On October 21, Camunda described the Catalog in Camunda Hub using a fictional bank as the example. The organization has one catalog, and a center of excellence publishes proven blocks into it: a credit bureau request, identity verification, a sanctions list check, a customer notification. Teams pick a block from the menu in the process editor and add their own steps before and after. The block's life cycle lives in git: commit, review, version, and CI publishes it to the catalog. The center of excellence sees which project runs which version, and before retiring a block it knows who will be affected. It ships with Camunda 8.10.

On October 20, Workato wrote about its MCP server for Google Workspace. Seven Google apps (Gmail, Drive, Calendar, Docs, Sheets, Slides and Contacts) are available through one tool with two helpers instead of seven servers with dozens of descriptions in the model's context. More than a thousand actions sit on the server side and are matched by phrase without a model in the loop. Once a day the server walks Google's catalog describing every endpoint, runs each new capability in a sandbox on a test account, and then three models in the roles of judge, dissenter and arbiter decide whether to release it.

On October 14, HubSpot published a breakdown of how skills, plugins and MCP connectors differ in Claude. The formula is simple: a connector is access to an outside service, a skill is a procedure in words, a plugin is packaging for the whole team. A skill works without a connector, but it doesn't see live data.

On October 13, Google updated the launch timeline for skills: skills in the Gemini app roll out from October 13 through mid-November, while skills in Workspace, promised by October 12, are postponed with no new date. That speaks to whether a team's workflow should be built on a feature that doesn't have a date yet.

On October 16, Red Hat announced general availability of its MCP gateway as part of Connectivity Link 1.5: isolation of the gateway and servers between teams, stateless sessions, support for prompts and resources, and limits for MCP. That's enterprise scale, but the point is the same: someone has to manage which tools an agent has access to.

Why this matters to a business

Take a car rental company with three managers. Each has their own contract template in Word, their own email text for clients and their own checklist for what to inspect when a car comes back. When the insurance price changes, it gets fixed in one template out of three. That's "building the same thing three times," just without AI.

The catalog from the news solves the same problem: one proven version, with an owner, and a procedure for changes. The tool alone doesn't give you that. A folder of skills where everyone drops whatever they like turns into the same three templates within six months. The conclusion: a catalog is worth starting when every entry has someone responsible for it and it's clear how to change it.

How it works for me

At the PDR company in the US, where I've been the technical partner since 2021, we agree on projects as a group of three: the owner, the second permanent developer and me. After that, each project has its own owner. The second developer runs AppSheet; the server, network, telephony, API and website are mine. We don't have a catalog as a product, but the principle is the same: every part has a person responsible for its version.

Rules for the tools that help me with code are easiest to keep next to the code, in the same repository, like documentation. Then they pass to the client together with the code and the database, and another developer can pick up the system. On my own website, in October 2026, I added llms.txt and a facts page for AI assistants, so an assistant doesn't invent what I do and on what terms. I have no numbers on the effect.

Among the Google Sheets jobs on Upwork from 2021 to 2025 there was a very practical version of a catalog too: moving finished spreadsheet templates into new ones, from 2022 to 2025. A template is the same proven block, and the question is always the same: which version is the right one.

I haven't tested Workato or Camunda myself. A self-updating MCP server I'd install only with a log: what it added on its own and when, and who looked at it.

What I would do

I'd start with an inventory: which instructions, templates and connections the team uses every day.

I'd assign each entry an owner and a storage location: git for technical things, a shared document with change history for team instructions.

I'd separate access from procedure, as in the HubSpot breakdown: the connection to the CRM and the rule for how we fill in a request change at different speeds.

I'd put each new entry through a check on a real request, the way Workato runs a canary in a sandbox. Once a quarter I'd look at what in the catalog nobody uses, and remove it.

Related reading

I covered how to describe process rules for employees and tools in the article Business logic: rules, statuses and permissions. The approach: AI in a process where the result can be verified and process automation from request to next action. Cases: technical partner of a PDR company in the US and Google Sheets and Apps Script: jobs on Upwork. From the digests on the same topic: how I split work with an AI agent, why I build on free tools and what I allow an agent on a production server. Earlier: where process logic begins in a ready-made connector. If your team's instructions and templates live in three places, tell me which ones change most often. Discuss your task.