MCP Tool Categories and Enterprise Use Cases

MCP servers now split into five working categories: data access, communication and collaboration, code and dev tooling, business operations, and security and identity. Knowing which category handles which job is the first real skill an enterprise needs before it puts an agent anywhere near production, because each category carries its own risks and its own rules for who gets to act without asking first.

Before I get into the categories, I want to explain why this matters now instead of a year from now.

Before Anthropic released the Model Context Protocol in late 2024, every AI-to-tool connection was a one-off. If you wanted your model to talk to Slack, you had to build a connector, and if you wanted it to talk to Snowflake too, you had to build another one. Every pairing of model and tool meant custom glue code, and none of it was reusable across vendors. It was the integration equivalent of needing a different charger for every device you own.

MCP fixed that by giving both sides a shared language. It runs on JSON-RPC 2.0 and works in both directions: a client can call a server, and a server can call back into the client, and any MCP-compliant client can talk to any MCP-compliant server, full stop. People call this the "USB-C for AI," and that's a fine shorthand, but it's worth being precise about what's actually being standardized. It's not data formats or business logic, but rather the negotiation of capabilities, meaning tools, resources, and prompts, between an AI client and whatever system sits behind it.

The growth numbers back up that this wasn't a science project. MCP server downloads went from around 100,000 in November 2024 to over 8 million by April 2025, and today there are more than 16,000 active MCP servers running, with over 5,800 of them catalogued in public registries where anyone can find and install them. And in December 2025, Anthropic handed the protocol over to the Linux Foundation's new Agentic AI Foundation, with AWS, Google, Microsoft, OpenAI, Bloomberg, and Cloudflare all backing the move. That's the moment MCP stopped being "Anthropic's thing" and became shared infrastructure that competitors are willing to build on together.

Enterprise numbers confirm it. Eighty percent of Fortune 500 companies are running AI agents in production today, and 28% have specifically implemented MCP servers to support them. The protocol is settled enough to build real systems on, and the ecosystem is big enough that you can't treat every server the same way. What follows is the category map I'd hand to anyone starting that work.

The three MCP primitives that determine how a tool behaves in an agent workflow

The spec defines three core building blocks, and each one comes with a different answer to a basic question: who's allowed to pull the trigger, and does a human need to say yes first?

Tools are model-controlled. These are functions the AI calls on its own, based on whatever the task in front of it requires. They break down into four flavors that matter for how you'd sort servers into categories: data retrieval (running a query, hitting an API), action (writing a record, kicking off a workflow), computation (crunching numbers, transforming data), and system-level operations (touching files, running code).

The 2025 spec update added tool annotations, which is a small change with big consequences. A readOnlyHint tells the host it's safe to auto-approve a call, while a destructiveHint tells the host to stop and get a human to confirm before anything happens. This is the part worth sitting with: governance isn't just something you bolt on at the orchestration layer above the agent. It gets encoded directly into the tool definition itself.

Resources are application-controlled. These are read-only data sources the host makes available; the AI reads from them for context but can't trigger anything through them. Each one has a URI, and the protocol supports listing, reading, templating, and subscribing to them. If you want an agent to know something without being able to act on it, this is the primitive you reach for.

Prompts are user-controlled. These are reusable templates that bake in domain expertise, and a person has to select them on purpose. The model doesn't trigger them, and the host doesn't either. Most deployments barely use this primitive, which is a missed opportunity, because it's exactly the right fit for compliance-heavy workflows, like a legal notice or an HR decision, where you want a human to be the one who starts the sequence.

There's also sampling, which lets a server hand inference back to the client instead of running its own model. Because the client already owns the model and the credentials, the server never needs its own API keys, and in a multi-server setup, that keeps the number of places holding sensitive credentials as small as possible.

None of this is a style choice, since the primitive you pick decides how big the blast radius gets when something goes wrong, and it tells your governance team exactly what to watch.

Data access servers: connecting agents to the records enterprises actually run on

This category covers MCP servers that give agents read, and sometimes write, access to the data enterprises actually run on: databases, data warehouses, BI tools, CRM systems, ERP records. The job here is usually answering questions, building reports, checking records for problems, or pulling context before doing something in a different system.

A few examples I've seen work well: a financial analyst agent that queries Snowflake or Redshift directly, pulls spend data, and flags anomalies, no SQL required from the analyst. A sales agent that reads Salesforce records before drafting an outreach email. A FinOps agent that pulls billing data across AWS, GCP, and Azure and, according to SuperAGI's 2025 industry research, typically cuts cloud spend by 15 to 25%.

The primitive that fits best here is usually a resource, since it's read-only context, or a retrieval tool tagged with readOnlyHint. That annotation is what makes auto-approval defensible; without it, you're trusting the agent on faith.

Here's the tension nobody talks about enough: this is the category where the credential problem bites hardest. An agent querying a production database has exactly the access rights of whoever set up its credentials, no more, no less, so if that person had broad access, the agent does too. Scope creep here doesn't announce itself; it just sits there quietly until something goes wrong.

Fintech leads MCP adoption overall, at 45% as of early 2026 data, and that's driven directly by how many systems a fintech company needs an agent to touch at once. Data access servers are the backbone behind that number.

Communication and collaboration servers: agents that participate in how work gets coordinated

This category connects agents to Slack, Teams, email, calendars, project trackers like Jira, Linear, and Asana, and document tools like Notion and Confluence. The job is coordination: notifying people, summarizing threads, scheduling, assigning work, escalating problems, moving a decision made in one system into an action required in another.

A hiring agent that screens applicants in Greenhouse or Lever, surfaces the strong ones to a hiring manager in Slack, and logs the outcome back to the ATS. SuperAGI's 2025 research puts the screening time savings at 50%. An incident response agent that watches for alerts, opens a Jira ticket, pages the on-call engineer through Slack, and drafts the first pass of a postmortem. A customer success agent that reads a support ticket, checks the CRM for account history, and drafts a reply for a human to review before it goes out.

The Asana incident is worth knowing about, because it's the clearest real-world case of what can go wrong in this category. In June 2025, a bug in an MCP-powered Asana feature let customer information leak into other customers' MCP instances, and Asana pulled the integration offline for two weeks. Cross-tenant leakage is a risk specific to this category, because collaboration tools are full of sensitive organizational context by design; that's their whole purpose.

The action-taking tools here, sending a message, assigning a ticket, inviting a user, are exactly where destructiveHint annotations and human confirmation gates matter most. An agent that can post to a channel or send email at scale needs someone checking its work before it fires. And this is the category where prompts, the underused primitive, actually earn their keep: encoding a compliance-sensitive workflow, like client-facing communication or an HR decision, as something a person has to deliberately trigger stops the agent from acting on its own in the wrong moment.

Code and developer tooling servers: where MCP adoption is densest and the attack surface is largest

This category connects agents to source control like GitHub and GitLab, CI/CD pipelines, IDEs, code review tools, dependency managers, cloud infrastructure APIs, and container registries. Software development is the sector where MCP adoption is thickest, and early movers like Zed, Replit, Codeium, and Sourcegraph are all using it to give agents a fuller picture of a codebase than a single open file ever could.

A DevOps agent that watches a CI pipeline, spots a failing test, pulls the relevant commit history, and drafts a fix for an engineer to review. A security scanning agent that checks a pull request against a vulnerability database before the merge gate opens. An infrastructure agent that reads current Terraform state, proposes a change, and waits for explicit approval before applying anything.

Why does this category carry the most risk? Developer environments pull MCP packages from npm and PyPI with barely any vetting, so supply chain exposure here is direct and immediate, not theoretical. CVE-2025-6514 is the case in point: a critical flaw, CVSS score 9.6, in the mcp-remote npm library let attackers run remote code through OS commands hidden in OAuth discovery fields, and over 437,000 developer environments were compromised before it was caught.

Secrets sprawl compounds the problem. GitGuardian's State of Secrets Sprawl 2026 report found roughly 24,000 secrets sitting in MCP configuration files on public GitHub, and commits made with AI assistance leaked secrets at roughly double the rate of commits made without it. Then there's the ClawHub marketplace compromise in early 2026: 824 malicious skills got uploaded to a registry that had over 135,000 GitHub stars, and more than 40,000 internet-exposed instances ran those packages before anyone caught it.

The fix isn't complicated to state, even if it's hard to do: credentials inside CI/CD pipelines should be issued just-in-time and scoped to the single task at hand, not handed out as long-lived service account tokens that sit around for months. And every tool call in a deployment pipeline needs a log entry that can't be quietly edited after the fact.

Business operations servers: agents that run or assist core enterprise processes

This category covers ERP systems, financial platforms, legal document management, procurement tools, ITSM platforms, and customer service systems. The work is transactional: processing, routing, classifying, drafting, approving. It's high-volume, repetitive enough to hand to a machine, and sensitive enough that every step needs a paper trail.

In financial services, a fraud review agent pulls flagged transactions from Stripe, cross-checks risk databases and CRM history, and hands back a recommendation. SuperAGI's 2025 research reports 25% reductions in fraud losses from that exact workflow in live deployments. In healthcare, a prior authorization agent reads a clinician's order, checks it against payer rules, and drafts the authorization request; the HIPAA Security Rule governs every step of that, and the Business Associate Agreement with whoever runs the MCP gateway has to spell out that it covers agent-mediated access to protected health information, not just human access.

In legal, contract review agents classify clauses, flag anything that isn't standard language, and route the document for an attorney to review, without ever exposing the full contract to a model outside the firm's control. In ITSM, an agent triages incoming tickets, assigns priority and an owner based on how similar tickets were handled before, and escalates on its own once it crosses a threshold someone set in advance.

PwC research puts the broader picture at 79% of organizations now using AI agents in some form, 66% reporting productivity gains they can actually measure, and 62% expecting returns exceeding their investment. Business operations is where that number gets cashed out into something real.

There's a gap worth naming here too: a legal or finance employee doesn't have a developer's workflow for wiring up a new MCP server, and what they need is something already configured and already governed, sitting behind a UI they'd recognize. The access model and the interface matter just as much as the server code underneath.

Gartner's projection is that up to 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% today. Most of that growth lands in this category.

Security and identity servers: the category that makes every other category trustworthy

This last category isn't a workflow on its own. It's the control plane, meaning it decides whether any of the other four categories can be trusted at all inside a regulated company. It covers OAuth flows, SSO, SCIM provisioning, credential vaulting, audit logs, and real-time threat detection across agent sessions.

Start with the credential picture across the ecosystem, because it's not good. Of the 3,012 servers listed in the official MCP registry, 91.5% still run on static API keys, personal access tokens, or nothing at all, and only 8.5% use OAuth, according to research from digitalapplied.com. In the first quarter of 2026, 42,000 MCP servers were sitting exposed on the open internet, leaking API keys, Slack credentials, and full chat histories to anyone who went looking. Researchers identified 492 publicly reachable servers with no real authentication or encryption in place.

There's a structural gap here that the current spec doesn't close on its own. When an agent authenticates to an MCP server, the company's identity provider sees a user logging in, not an agent making a connection, and whatever the agent does next is invisible to the identity and access management system the company already relies on for everything else.

The spec does require something real: OAuth 2.1 with mandatory PKCE and Resource Indicators, laid out in RFC 8707, has been mandatory for protected remote servers since mid-2025, and that closes off a real class of token misuse. What it doesn't give you is SSO integration, SCIM-based provisioning, just-in-time credentials scoped to one task, or policy checks at the level of an individual tool call.

The threats are specific to this protocol, too, not generic security problems wearing an MCP costume. Tool poisoning is the sharpest example: malicious instructions get embedded inside a tool's definition where the AI reads them but a human reviewing the code never sees them. Invariant Labs demonstrated this by compromising a getfactoftheday() function and using it to extract SSH keys and chat history, from a tool that sounded completely harmless. Add prompt injection through tool responses and intent drift across long agent sessions, and you've got exfiltration paths that look like ordinary tool calls right up until they aren't.

This is the gap Runlayer is built to close. SSO and SCIM tie every agent action back to a real identity instead of a generic login, credentials get issued just-in-time, scoped to the task, and expire when the task ends, and policy enforcement happens at the level of the individual tool call, not the whole session, which is the only granularity fine enough to catch the kind of quiet misuse described above.

Five categories, one shared foundation: data access, communication, dev tooling, and business operations are where the value shows up, while security and identity is what decides whether an enterprise can trust any of it enough to leave it running unattended.