MCP Model Context Protocol: What Recruiters Should Ask Vendors

The MCP model context protocol is an open standard that lets AI assistants connect to outside software through tools, resources, and prompts.

That matters because more vendors now claim their product supports MCP. Once you know how the protocol works, you can tell a useful connection from a marketing label.

How the MCP model context protocol works

MCP works by splitting a connection into a host, a client, and a server that talk in one shared format. The host is the AI app you type into. The client is a small connector inside that app. The server is the piece a software vendor builds to expose their product.

Each client links to one server. So if your AI app connects to your ATS and your email tool, it runs two clients, one for each server. The app can still use both in the same chat.

Think of it like a charger standard. MCP gives AI apps one plug shape, so a vendor builds one server and any MCP app can use it.

To buy well, you only need to know what a server offers once it's plugged in.

The three building blocks: tools, resources, and prompts

An MCP server can offer three kinds of capability, and each one does a different job. Tools let the AI do something. Resources let the AI read something. Prompts give you a ready-made task you can run on demand.

A server doesn't have to offer all three. That's fine, as long as the vendor says so plainly.

Tools

A tool is an action the AI can take inside another product when you ask for it. Examples include searching candidates, adding a note to a profile, or moving someone to the interview stage. Each tool has a name, a short description, and a list of inputs it needs.

The AI reads those descriptions and decides which tool fits your request. If you type "find backend engineers in Austin open to relocation," the AI might call a search tool with those filters filled in.

Resources

A resource is a piece of data the server lets the AI read, without changing anything. Good recruiting examples include the current candidate record, a job description, or the notes from a past call. Resources give the AI context so its answers rest on your real data.

The key detail here is that reading and acting are separate. A server could let the AI read every candidate record while offering zero tools that change them. That split matters for risk.

Prompts

A prompt is a saved task template that the server offers and you choose to run. Picture a menu item called "Write a submittal summary" that pulls the right fields and formats them the way your clients like. You pick it, fill in a candidate name, and the AI does the rest.

Prompts keep output consistent, so a new recruiter and a veteran get summaries in the same shape.

Who controls each building block

Each building block has a different default owner: the AI picks tools, the app or user picks resources, and the user picks prompts. That ownership tells you where a mistake could slip in.

Tools carry the most risk because the AI chooses when to call them. A well-built AI app asks you to approve an action before it runs, like sending an email to a candidate. If a vendor's server lets the AI send messages with no approval step, you want to know that before a bulk email goes out under your name.

Resources carry less risk because they only read data. The main question is scope. Can the AI see only the records you can see, or does it see the whole database?

Prompts carry the least risk because a person starts every one. They still shape output, so check that a prompt's template matches how your team writes.

Why a shared protocol matters for your recruiting stack

A shared protocol matters because it lets one AI app work across many of your tools without a custom build for each one. Recruiters juggle an ATS, a sourcing tool, email, a calendar, and a CRM. Today, getting an AI assistant to touch all of them means a separate connection for every pair. The MCP model context protocol cuts that down to one server per product.

Analysts expect this shift to speed up. Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. That forecast covers enterprise software broadly, not recruiting alone.

If that forecast holds, more MCP claims will show up in vendor decks as part of your wider AI recruiting evaluation. The building blocks below let you judge each claim on its merits, not on how current the term sounds.

What to ask before you trust a vendor's MCP claim

Ask a vendor which building blocks their server exposes, what each one does, and how they control access. Those three answers separate a working server from a renamed set of API docs. Bring these questions to your next demo:

• Building blocks: Which tools, resources, and prompts does your server offer today? Can you show me the list?
• Actions: What can each tool change? Can it send email, edit records, or delete anything?
• Approval: Does the AI app ask me to confirm before a tool runs? Can my admin require that?
• Access scope: Does the server respect my user permissions, or can the AI read records I can't?
• Live status: Is the server live for all customers now, or is it in beta or on the roadmap?
• Compatibility: Which AI apps have you tested it with, and what broke?

Ask the vendor to show you a live demo, not a slide. A real server lets them connect an AI app in front of you and run a tool on test data. If they can't do that, treat the claim as a plan.

Red flags that show a gap in an MCP claim

The clearest red flag is a vendor who can't name the specific tools or resources their server offers. If the answer stays at "we support MCP" with no list behind it, the support may be thin or missing.

Watch for a few other warning signs during the demo:

• No tool list: They describe the server in general terms but can't show the actual tools by name.
• Read-only surprise: They say "full integration," but the server only offers resources and no tools.
• No approval story: They can't explain how actions get confirmed before they run.
• Roadmap language: Words like "coming soon" or "in early access" mean you can't use it yet.

None of these rule a vendor out. A read-only server can still save you time. The goal is to know what you're buying before you sign.