Logistics Route Optimization: Guide in 2026
April 29, 2025
- BLOG
How AI Agents Use MCP to Access Real-World Data and Services
Published: October 22, 2026
Table of Contents
A language model on its own can’t tell you whether a driver is stuck behind a road closure, which depot is closest to a customer, or what an order costs today. It knows what it absorbed during training, and that stops at some point in the past. Ask it about the real world right now and it either guesses or admits it can’t help.
AI agents are meant to close that gap, and the Model Context Protocol (MCP) is the standard most of them now use to do it. Instead of building a custom integration for every system, an agent finds and uses outside tools and data through one common interface.
Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Those agents all need a dependable way to reach real systems, which is why MCP AI agents keep coming up in architecture discussions.
This guide covers how MCP AI agents work under the latest spec, what happens during an actual request, which services they reach through it, and what to settle on security before going live. We’ll use NextBillion.ai MCP as a worked example, because location is one of the hardest kinds of real-world context for an AI to get right.
What Is MCP (Model Context Protocol)?
MCP is an open standard for connecting AI applications to external systems. Anthropic open-sourced it on November 25, 2024, pitching it as a single protocol to replace the fragmented, one-off connectors that sat between assistants and the places data lives. A year later, it moved to neutral ground.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. The project’s governance model stayed as it was.
The numbers Anthropic published at that point give a sense of scale: more than 10,000 active public MCP servers, adoption in ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, and over 97 million monthly SDK downloads across Python and TypeScript.
The common comparison is USB-C. One connector replaced a drawer full of proprietary cables, and MCP does something similar for AI. You build a connection to a system once, as an MCP server, and any MCP-aware application can use it. One boundary is worth knowing: the MCP documentation is clear that the protocol only covers how context gets exchanged. It doesn’t dictate how an application uses its model or manages that context.
Why AI Agents Need MCP
Anthropic’s launch post described the problem plainly. Even strong models are cut off from the data they need, and every new data source used to require its own custom implementation. With N applications and M systems, that’s up to N × M integrations, each with its own authentication quirks and failure modes. A shared protocol turns that into N plus M: each application builds a client once, and each service builds a server once.
Two practical benefits follow for teams building MCP AI agents.
- Fresher answers: An agent that queries the source system directly stops relying on stale training data or pasted snapshots. NextBillion.ai makes the same point about location: models limited to training data struggle with fast-changing conditions, and MCP gives them a standard, secure route to specialized services such as geospatial data.
- Portability: Because the protocol is open and now vendor-neutral, you can swap the model or the host application and keep your servers.
How MCP Works: Hosts, Clients, and Servers
The Model Context Protocol is an open standard that lets AI applications connect to outside tools and data through one consistent interface. Knowing which part does what makes the rest of the protocol much easier to follow. According to the official architecture docs, MCP has three participants:
- Host: the AI application, such as a coding assistant, a chat app, or a custom agent.
- Client: a component inside the host that keeps a dedicated connection to one server. A host talking to five servers runs five clients.
- Server: the program that exposes data or actions. It can run on your own machine or on a remote platform.
The protocol has two layers. The data layer is a JSON-RPC 2.0 exchange that defines discovery, the core primitives, and notifications. The transport layer handles the connection itself, and there are two options. Stdio launches a local server as a subprocess, which suits desktop tools.
Streamable HTTP serves remote servers over the network and supports standard authentication, with OAuth the recommended way to get tokens. The older HTTP+SSE transport is now formally deprecated.
One thing to flag if you’ve read older explainers: MCP is now stateless. Under the 2026-07-28 spec revision, the initialization handshake and protocol-level sessions are gone.
Every request carries its protocol version and client capabilities in a _meta field, so a server can process each one on its own. Servers must implement a server/discover request that advertises their versions, capabilities, and identity, and clients can call it first or skip straight to the request they actually want. The response is cacheable, so discovery doesn’t need to run every time.
Local vs Remote MCP Servers
The word “server” misleads people at first, because an MCP server doesn’t have to live anywhere special. The official docs draw the line by transport. A local server uses stdio, runs on the same machine as the host, and typically serves a single client.
A remote server uses Streamable HTTP, runs on a platform somewhere else, and typically serves many clients at once. The reference filesystem server is the usual local example, while Sentry’s hosted server is the remote one the docs use.
The difference matters for planning. Local servers are easy to try, keep data on the device, and need little more than a launch command and, often, an API key. Remote servers suit shared tools that a whole team or customer base will use, and they’re where OAuth, per-user consent, and audit logging earn their keep.
NextBillion.ai MCP sits on the local side: it launches through npx over stdio, so a developer can add location tools to a coding agent with a single configuration entry. When the same capability has to reach many users in production, the design shifts toward a remote deployment with proper authorization.
The Primitives: Tools, Resources, and Prompts
Servers offer three kinds of capability, and each has */list methods so a client can see what’s available.
Tools are executable functions, like running a database query, calling an API, or creating a record. Each has a name, a description, and a JSON Schema for its inputs, which is what lets the model decide when and how to call it. Resources are data sources that provide context, such as file contents, database records, or API responses. Prompts are reusable templates that structure an interaction, like system prompts or few-shot examples.
On the client side, the main primitive is elicitation, which lets a server ask the user for more information or confirmation mid-task. Sampling, Roots, and Logging still work but are deprecated as of the July 2026 revision, and new implementations are told not to adopt them. Longer jobs can use the optional Tasks extension, which hands back a durable handle so the client can poll for the result.
Live Updates and Long-Running Work
Real operations don’t stand still, and MCP has a few mechanisms for that. Tool lists can change while a connection is open, for example when new functionality becomes available, or a tool becomes temporarily unavailable. Clients that want to hear about those changes opt in by opening a long-lived subscriptions/listen stream and naming the notification types they want, and the server confirms which ones it will honor.
The docs add one caveat worth repeating: delivery is best effort, so clients should still poll now and then to keep results fresh. That is also why list results now carry a ttlMs freshness hint.
Longer jobs are handled by the optional Tasks extension. Instead of holding a connection open, the server returns a durable handle, and the client checks back for status and the final result. And when a server needs a human in the middle of a job, such as confirming an action or supplying a missing detail, it uses elicitation.
The latest spec delivers elicitation through a multi-round-trip pattern: the server replies that it needs input, and the client retries the original request with the answer attached. Together, those three pieces give an agent a workable way to keep going while conditions change underneath it.
What Happens When an Agent Uses MCP: A Walkthrough
Here’s one request from start to finish. A dispatcher asks an agent: which available technician can reach this customer fastest, and what’s the route? The agent is connected to a location server such as NextBillion.ai MCP.
- Discovery: The host connects to its configured servers. The client can call server/discover, then tools/list, and gets back each tool’s name, description, and input schema. The list comes with a freshness hint (ttlMs), so the host can cache it instead of asking again on every turn.
- Reasoning: The model reads the request and the tool descriptions. It sees it can’t answer from language alone: it needs coordinates, then real travel times.
- Geocoding: The model asks the client to call a geocoding tool such as geocode_forward with the customer’s address. The server returns coordinates.
- Travel times: The model calls distance_matrix with the technicians’ positions as origins and the customer as the destination. Road-based travel time is what matters here. NextBillion.ai points out that nearby doesn’t mean reachable, since one-way roads, restricted turns, and bridges can make a close location slow to get to.
- Route: For the fastest technician, the model calls directions, and optionally static_route_map to produce a visual.
- Answer: The model summarizes the result for the dispatcher in plain language.
Two details are worth noticing. The model never touches the mapping service directly. It produces structured requests, and the client and server do the work. And because each request carries its own metadata, the server doesn’t have to remember anything between calls.
Real-World Data and Services Agents Reach Through MCP
Most MCP servers fall into a few families:
- Business and productivity tools: Anthropic’s launch shipped reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, and the ecosystem has grown well past that.
- Databases and data warehouses: Read-only query access so answers come from live records.
- Developer tools: Repositories, issue trackers, CI pipelines, and error monitoring. The MCP docs use Sentry’s remote server as an example.
- Local files and resources: Served over stdio so nothing leaves the machine.
- Location and logistics services: Geocoding, routing, travel-time matrices, and optimization.
Finding the right server used to mean searching GitHub. The project now maintains an official MCP Registry for discovering published servers.
NextBillion.ai MCP: Location Reasoning for AI Agents
Location is a good test of why MCP matters. A language model can understand “find the nearest service point,” but it can’t compute drive time on a real road network. NextBillion.ai MCP fills that gap by exposing location capabilities as tools an agent can pick and combine:
- Forward and reverse geocoding
- Autocomplete and autosuggest
- Places and POI search, including search along a route
- Routing and directions
- Distance matrix
- Isochrones, which show everywhere reachable within a set travel time
- Static route maps
Setup is lightweight. The server runs locally over stdio through npx, needs Node.js and an API key, and can be added to clients such as Claude Code, Cursor, and Codex CLI. In production, the API key should stay on the server side, never in browser code. Practical builds include AI route planners, fleet management copilots, field service assistants, and delivery planning agents.
For heavier jobs, agents lean on the routing stack behind those tools. NextBillion.ai’s Route Optimization API can handle up to 10,000 stops in one request across 50-plus constraints, and the Distance Matrix API scales to 5,000 x 5,000 points. In that model, the API is the engine, and the agent is the coordinator that decides when to call it.
Read more: Build Location-Reasoning AI Applications with NextBillion.ai MCP
Where Location Tools Make Agents More Useful
NextBillion.ai’s location-reasoning guide shows how much a handful of location tools change what an agent can answer. A few of its examples:
- Delivery feasibility: Geocode the customer’s address, then check it against an active delivery zone or an isochrone, the area reachable within a set travel time.
- Fulfillment assignment: Use a distance matrix to compare travel times from several facilities, then weigh inventory and processing capacity before choosing one.
- Field service dispatch: Compare realistic journey times for available technicians, confirm each works within the customer’s service territory, and check how a new job would disturb existing appointments.
- Detour-aware search: Find restaurants along a route and rank them by detour time, which is the travel time via the restaurant minus the direct-route time, dropping any that add more than a set limit.
The pattern is the same each time. The model works out what the person wants, the tools do the geography, and the application applies its own business rules on top. At no point does the model need to know anything about road networks.
MCP vs Function Calling
MCP doesn’t replace function calling. Function calling is how a model expresses an intent to use a tool. MCP standardizes how that tool is described, discovered, hosted, and executed across applications.
In practice, an agent uses both: the model emits the call, and MCP supplies the definitions and carries it out. For a handful of functions inside one app, plain function calling is simpler. Once tools need to be reused across apps, owned by different teams, or swapped without rewrites, MCP starts earning its keep.
Security: What to Settle Before Going Live
Connecting agents to real systems raises the stakes, so these are the risks that matter most.
- Prompt injection: OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications and says it’s unclear whether any foolproof prevention exists. Content an agent reads from a web page, email, or ticket can carry hostile instructions, so treat tool output as data, never as commands.
- Token passthrough: The MCP security guidance forbids servers from accepting tokens that weren’t issued to them and forwarding them downstream, because it breaks audit trails and trust boundaries.
- Confused deputy attacks: Proxy servers that use a static client ID with third-party APIs must collect per-client consent.
- Local server risk: A one-click local server runs commands on your machine. Clients should show the exact command and ask for approval, and sandboxing is advised.
- Over-broad scopes: Start with minimal permissions and escalate only when needed.
- SSRF: Clients that fetch OAuth metadata URLs should block private and link-local IP ranges.
Keep a person in the loop for irreversible actions. NextBillion.ai describes the same human-in-the-loop idea for dispatch, where approval stays in place for high-value, compliance-sensitive, or hazardous deliveries.
Read more: Route Optimization with AI Agents (Beyond Static APIs)
Common Mistakes When Adopting MCP
- Exposing too many tools: Loading every tool from every server up front bloats context and makes selection harder. The client best-practices docs describe progressive tool discovery for hosts that connect to many servers.
- Over-granting scopes: Publishing every scope and letting clients request all of them widens the damage from a stolen token. The security guidance recommends a minimal starting scope, with step-up requests when a risky operation is first attempted.
- Ignoring caching: List results now include freshness hints, so re-fetching them on every turn wastes calls and context.
- Skipping the human: A tool that can send, pay, or delete shouldn’t run without approval.
- Building what already exists: Check the MCP Registry before writing a server from scratch.
Checklist Before You Adopt MCP
- Does a maintained server already exist, or will you build one?
- Can it run with least-privilege credentials and read-only access?
- Which transport fits your setup, local stdio or remote Streamable HTTP?
- How are authentication, rate limits, and errors handled?
- Can you log and audit every tool call?
- Does your host support approval for sensitive actions?
- How many tools does the server expose? Dozens of overlapping tools eat context and confuse selection, so fewer, clearer tools usually work better.
Final Thoughts
AI agents are only as useful as what they can reach. Without live data and the ability to act, they stay clever conversationalists. MCP is what makes that reach consistent, and it now has the backing of a neutral foundation and most major AI vendors. The standard is still moving, as the July 2026 changes to statelessness and deprecations show, so build against the current spec and expect revisions.
For teams working with location, routing, and dispatch, MCP AI agents are already practical: an agent can geocode, compare travel times, and plan routes through tools like NextBillion.ai MCP instead of guessing.
Frequently Asked Questions
MCP AI agents are AI agents that use the Model Context Protocol to reach outside tools, data, and services. Instead of relying only on training data, they discover a server’s tools, call them with structured requests, and use the live results to complete a task. This is how an agent can check real travel times, query a database, or look up a record as it works.
Anthropic created MCP and open-sourced it in November 2024. In December 2025, it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. The governance model stayed the same, so the project’s maintainers still run a community-driven, transparent process, but the standard no longer belongs to a single vendor.
No. Although Anthropic created it, MCP has been adopted by ChatGPT, Gemini, Microsoft Copilot, Cursor, and Visual Studio Code, among others. Because the protocol is open, a server built once works with any compatible client. NextBillion.ai MCP is a good example, since it can be added to coding agents such as Claude Code, Cursor, and Codex CLI using the same stdio setup.
Not strictly. Agents can reach external systems through custom code or plain function calling, and for a single tool inside one application that may be simpler. MCP earns its place as the number of systems grows. It standardizes how tools are described and discovered, lets you reuse the same server across several applications, and makes it easier to swap models or hosts without rebuilding every integration.
The protocol includes OAuth-based authorization, and the project publishes detailed security best practices. Real-world safety still depends on how you deploy it. Use least-privilege credentials, trust only vetted servers, and keep a human approval step for irreversible actions. Treat everything a tool returns as untrusted data, because prompt injection is a risk for any agent that reads outside content.
Get a free API key from NextBillion.ai, make sure Node.js is installed, and add the NextBillion.ai MCP server to a compatible client such as Claude Code, Cursor, or Codex CLI. Then ask a location question, for example, the fastest driving route between two addresses, and watch the agent chain geocoding, routing, and map tools. Keep the API key in an environment variable or secret manager, not in client-side code.
