What Is Model Context Protocol (MCP)? A Developer's Guide

Model Context Protocol (MCP) is an open protocol that lets an AI application connect to external tools and data sources through one standard interface. A server implements it once; any compatible client can discover what the server offers and call it, with no integration code written for that particular pairing. This guide explains how the protocol works, how it differs from REST and function calling, and what to check before you build on it, including how NeuralVerge exposes its own tools over MCP.

The short version

• —What it is: a standard way for an AI application (a chat client, an IDE, an agent) to discover and use tools, readable content and prompt templates that a server exposes. It standardizes the connection, not the model.
• —What it replaces: the pile of custom integrations you would otherwise write for every tool-and-application pairing. It does not replace REST or function calling; it sits at a different layer.
• —Who it is for: teams building agents or assistants that need to reach several tools, and teams that own a capability and want any compatible client to be able to use it.
• —What it costs: the protocol itself is free to use. On NeuralVerge, a tool call costs the same points as the matching REST call: 5 points for Search and AI extraction, 10 or 15 for a lookup that resolves, as the source pages list them.

What Model Context Protocol is

MCP is a standardized way for an AI application to discover and use external tools and data sources, without a custom integration for every pairing. A server implements the protocol once to expose its capabilities; any client that also implements the protocol can connect to it, see what it offers, and use it, the same way any USB device works with any USB port without a driver written for that one device-and-computer combination.

It is easiest to place against the two things people build instead.

MCP vs. a plain REST integration

Calling a REST API directly from your own code works fine when you are building one integration for one application: you write the request, parse the response and move on. The friction shows up at the second, third and tenth integration. Each new tool means new code, and each new AI application that wants an existing tool means writing that integration again, because a REST API on its own does not describe itself in a way an AI application can discover and use automatically. MCP servers expose their capabilities in a standard, discoverable form so that connecting a new client does not mean writing new integration code.

MCP vs. a model's own function-calling schema

Most model providers support function calling: a way for a model to request that a specific function be invoked, with arguments, inside that provider's own API. It is a real and useful capability, but a different layer. Function calling is how a model expresses "call this tool" once the tool is already available to it. MCP is how that tool became available in the first place. An MCP client typically takes a connected server's tools and translates them into whatever function-calling schema the underlying model expects, so the model-facing mechanics stay the same even as the set of connected servers changes.

MCP vs. calling a capability directly: two modes, not a replacement

Exposing a capability over MCP does not replace calling it from backend code. They are two integration modes for the same capability, and most real systems use both. Calling it directly fits a fixed pipeline that already knows a step belongs at a specific point in a flow. Exposing it over MCP fits an agent that has to decide for itself, mid-task, whether and when to reach for it. Neither is objectively better; the fit depends on whether the calling logic is fixed in advance or decided dynamically by the agent's own reasoning.

Why it matters more for agents than for a chat window

A conversational assistant answering one question at a time benefits from MCP, but the case sharpens for an autonomous agent working a multi-step task. An agent's information needs are not fully known in advance: what it needs to look up depends on what it has already found, so the set of tools available to it matters more than in a single-turn exchange. A host that can connect to any MCP server lets an agent's tool set grow, with a new data source or a new capability, without rebuilding the agent's reasoning loop or the host. Custom integration per tool per agent framework does not scale the same way once a task might need any one of a dozen capabilities depending on how it unfolds.

How MCP works

MCP defines a small number of roles and message types, and the same pattern repeats regardless of what the server does underneath.

1. Host and client

The host is the application a person actually uses: a chat interface, an IDE, an agent runtime. Inside the host, a client manages one connection to one server and handles the protocol-level back-and-forth. A single host can run several clients at once, each connected to a different server, which is what lets one application reach many unrelated tools without a separate integration for each.

2. Server

A server exposes a set of capabilities (tools, resources and prompts) over the protocol. It can be a local process, launched and communicated with over standard input and output, or a remote service reachable over HTTP. Either way it speaks the same protocol, so a client needs no different logic depending on where the server runs.

3. Discovery

When a client connects, it asks the server what it offers, and the server answers with a structured list: each tool's name, description and accepted parameters; each resource's identifier and type; each prompt's template and parameters. This is the step that makes the system self-describing. Nothing about what a specific server offers has to be hard-coded into the client ahead of time.

4. Invocation

Once the client, and through it the model reasoning inside the host, knows what is available, invoking a tool is a structured request and response. The client sends the tool's name and arguments, the server does whatever work the tool represents, and the result comes back in a defined shape. The model decides when to invoke a tool and with what arguments; the protocol only defines how that invocation travels between host and server.

Tools, resources and prompts

MCP defines three kinds of capability a server can expose, and most real-world integrations lean heavily on one of them.

Tools are the primitive most agent-facing integrations are built around, since an agent's typical need is "do this thing and tell me the result." Resources fit content a host wants available to reason over, rather than something invoked for a result. Prompts let a host surface a well-crafted starting point instead of every user writing their own version of the same prompt.

A worked example: checking a company's registration status

Take a concrete, illustrative case: an agent mid-conversation needs to confirm whether Acme Oy (Finland) is currently an active, registered entity.

1. —The host's client is already connected to an MCP server that exposes corporate-registry tools, and during discovery it learned that the server offers a tool for looking up Finnish registry records by Business ID.
2. —The agent's reasoning recognizes it needs this fact and does not have it from the conversation alone, so it invokes the tool with the Business ID as an argument.
3. —The server runs the lookup against the registry and returns a structured result, with registration status, entity name and registered address, in the response.
4. —The client hands the result back into the model's context, and the agent continues with the fact available, as if it had been in the conversation from the start.

Nothing in this sequence required the host application to be built with knowledge of that registry lookup in advance. The tool became available the moment the client connected to a server that offered it.

REST and MCP

NeuralVerge is one example of a server that exposes a capability both ways, and it shows the pattern concretely. It runs a hosted remote MCP server at https://mcp.neuralverge.ai/mcp, speaking Streamable HTTP, so there is nothing to host yourself. You add the URL to Claude, ChatGPT, Cursor, VS Code or another client that supports MCP authorization and sign in through the browser; there is no key to copy into a config file. Step-by-step setup is in the MCP server for Claude guide.

Search, AI extraction and every source in the source catalog (company, enrichment, LinkedIn, marketplace and review lookups) map to a named tool an MCP client can discover and invoke. AI research and saved AI Agents run over REST only. MCP is one way in and REST the other; the platform behind them is the same, and each MCP tool is a thin wrapper around its REST endpoint with the same inputs and outputs.

A connected client sees a tool definition (a name, a description and its parameters) exactly as it would for any other MCP server. A reverse email lookup, for instance, is exposed as the run_email_enrichment tool. Once a client is connected, invoking it looks like this:

{
  "tool": "run_email_enrichment",
  "arguments": { "email": "jane.doe@acme.com" }
}

A Crunchbase company lookup follows the identical pattern under its own tool name, taking a Crunchbase company URL:

{
  "tool": "run_crunchbase_company",
  "arguments": { "url": "https://www.crunchbase.com/organization/acme-oy" }
}

General-purpose extraction for any standalone URL goes through a shared run_extract tool. It takes the target URL, plain-language instructions and a settings object; where a fixed shape is needed, a JSON Schema goes in settings.extract_schema_json as a string:

{
  "tool": "run_extract",
  "arguments": {
    "url": "https://example.com/company/acme",
    "instructions": "Extract data from the company profile",
    "settings": { "country_code": "us" }
  }
}

The pattern repeats across the catalog: one tool per data source, named consistently (tool names use underscores, REST paths use hyphens), taking the same arguments the equivalent REST call would take. An agent reasoning over its available tools does not need to know NeuralVerge's internal structure to use them correctly; the tool's name and description are enough to decide when it applies.

MCP support on its own is not a differentiator, since many research and search services offer REST and also ship an MCP server. The differences sit in what comes back and where it comes from. The full request reference is at docs.neuralverge.ai.

Permissions and cost

Capability access is a design decision

Nothing about MCP automatically decides which servers a given client should be allowed to connect to, or which tools within a connected server an agent may invoke. The protocol makes discovery and invocation possible; scoping is a decision the host application and whoever configures it has to make deliberately. A general-purpose chat assistant has good reason to be more conservative about which servers it connects to than a dedicated internal automation agent. Within one connected server, a client can choose to surface only a subset of its tools rather than everything by default.

This matters because a tool with a real side effect (sending an email, modifying a record, executing a payment) is a different risk from a tool that only reads and returns data. Treating every MCP tool as equally safe to call without confirmation is a choice worth making deliberately, not a default to accept because the protocol allows it.

What it costs

MCP itself has no price; you pay for the work the tools do. On NeuralVerge, billing is per resolved lookup regardless of whether REST or MCP triggered the call:

• —Search and AI extraction: 5 points per call. A call on an input that does not resolve can still be billed (AI Extract on a dead URL returned null and cost 5 points), so do not assume an empty result is free.
• —Email enrichment: 10 points per result, charged only on a match.
• —Crunchbase company: 15 points per lookup, charged only when a profile resolves.
• —AI research: priced by tier, from 20 points for Lite to 400 for Ultima, and available over REST only.

Those figures come from the pricing page and the source pages at the time of writing; check the source catalog for the current cost of any other tool. One practical limit: the hosted server lists all its tools in one response, and some clients cap how many tools they load, so you may need to enable only the ones you want.

How to decide

Standing up one real MCP server for a tool you already have, and connecting it to a client you already use, is a faster way to judge fit than reading the specification alone. Before you build, check:

• —Does your host application support MCP, or would you build client support yourself? Not every application speaks the protocol natively yet; confirm before assuming it works out of the box.
• —Does the server you need already exist? A growing ecosystem of MCP servers covers common tools and data sources; check before committing engineering time to a new one.
• —Local process or remote service? A local, stdio-based server is simple for development; a remote, HTTP-based server fits a shared, multi-user deployment better.
• —Are you exposing tools, resources, or both, and does that match what the capability is? An action framed as a resource, or content framed as a tool, works technically but reads oddly to a client reasoning over what is available.
• —Does the capability behave identically whether called directly or through MCP? If a REST call and an MCP tool call return different shapes, that is two integrations to maintain instead of one.
• —Does the use case fit the dynamic mode? MCP pays off for connecting an agent to internal tools and data, standardizing several AI applications on one server per data source, extending an IDE or coding assistant with project-specific tools, and giving research and enrichment agents live data access mid-task. A fixed pipeline with a known step is often simpler as a direct call.
• —Who decides which tools are exposed, and which need confirmation? Settle this before connecting a server whose tools have side effects.

Frequently asked questions

Is MCP the same thing as function calling?

They're related but not the same layer. Function calling is how a model itself requests that a tool be invoked, inside a single model provider's API. MCP is a protocol for how an application discovers and connects to tool and data servers in the first place — an MCP client typically turns a connected server's tools into the function-calling schema a model actually sees.

Do I need to use MCP, or can I just build my own tool integrations?

You can always build a direct, custom integration for one specific application and one specific tool — nothing requires MCP. The tradeoff is that a custom integration only works for that one pairing, while an MCP server works with any MCP-compatible client without either side writing code specific to the other.

What's the difference between a Tool, a Resource, and a Prompt in MCP?

Tools are actions a client can invoke that do something or return computed data. Resources are readable content a server exposes, like a file or a record, that a client can pull into context without it being an action. Prompts are reusable, parameterized templates a server offers for common interactions. Most agent-facing integrations lean heavily on tools.

Does MCP require a specific transport, like HTTP?

No — the protocol defines the message format and interaction pattern, not one required transport. A local server commonly communicates over standard input and output; a remote server commonly communicates over HTTP. Both speak the same underlying protocol either way.

Is MCP specific to one AI provider or model?

No — it's an open protocol, not tied to a single model or vendor. Any client that implements the protocol can connect to any server that implements it, regardless of which model is doing the reasoning on the client side.

Does MCP decide which tools an agent is allowed to use?

No — the protocol makes discovery and invocation possible, but scoping which servers a client connects to and which tools it surfaces from a connected server is a design decision made by whoever configures the host application, not something MCP enforces on its own.

Can I use NeuralVerge over MCP?

Yes. NeuralVerge hosts a remote MCP server at https://mcp.neuralverge.ai/mcp, and Search, AI extraction and every source in the catalog are available as MCP tools, with the same inputs, outputs and cost as the matching REST calls. AI research runs over REST only.