What is an MCP Server: Connecting AI to External Systems

TL;DR — An MCP (Model Context Protocol) server exposes tools, data, and prompts to AI applications through one open protocol. An AI agent connects through an MCP client, discovers what the server offers, and calls it, so a single integration works across models and agent frameworks instead of custom glue code per tool.

Artificial intelligence models have become incredibly powerful at understanding language and generating content. Yet their ability to act, by searching a database, calling an API, or running code, depends on integrations that each tool needs separately. Each new tool or data source requires custom integration, turning potential into “glue code” maintenance.

The Model Context Protocol (MCP) addresses this with one open standard for connecting AI applications to external systems. An MCP server is the piece that exposes a system through that standard.

How Model Context Protocol (MCP) servers work

The Model Context Protocol defines three roles. The host is the AI application the user interacts with, such as a chat assistant, an IDE, or an agent runtime. The host runs one MCP client per connection, and each client talks to one MCP server, which wraps a system: a database, a SaaS product, a file store, or an internal service.

An MCP server exposes three kinds of capabilities:

• Tools: Functions the model can decide to call, each described by a name, a natural-language description, and a JSON Schema for its arguments. Searching documentation, creating a ticket, or running a query are typical tools.
• Resources: Read-only data the application can load into the model’s context, such as files, records, or API responses.
• Prompts: Reusable templates the server offers for common tasks, which the user or the application can select.

Messages follow JSON-RPC 2.0. A local server runs as a subprocess and communicates over standard input and output (stdio); a remote server is reached over Streamable HTTP, which replaced the earlier HTTP with Server-Sent Events transport in the 2025 specification. When a client connects, it negotiates capabilities with the server, lists the available tools, and the host passes those tool descriptions to the model. When the model chooses a tool, the client sends the call and returns the result to the model.

One point is often misunderstood: the server does not hold the conversation. The host keeps the chat history and decides what goes into the model’s context; the server only answers the requests it receives. That separation is what lets one server be reused by many different AI applications.

Kestra works on both sides of the protocol. The Kestra MCP server exposes flows as tools that AI agents can call, and Kestra flows can also act as MCP clients, as shown below. For the broader picture of coordinating many servers and agents, see MCP orchestration.

MCP as the “USB-C for AI”

The most effective analogy for MCP is “USB-C for AI.” Before USB-C, connecting devices required a tangled mess of proprietary cables for power, data, and video. USB-C replaced this fragmentation with a single, universal standard.

MCP aims to do the same for software. Instead of writing custom API wrappers and parsers for every database, SaaS application, or internal service an AI needs to access, you expose them through a single, standardized MCP interface. This dramatically simplifies the process of giving AI new capabilities. An AI agent only needs to know how to speak MCP to gain access to a world of tools, just as a laptop only needs a USB-C port to connect to countless peripherals. Anthropic introduced MCP as an open standard in November 2024, and it has since been adopted by the major model providers and agent frameworks, which is what makes the USB-C comparison hold: the value comes from everyone using the same port. Kestra’s AI tools follow the same standard.

Why AI needs a standardized tool interface

Traditional APIs are built for predictable, programmatic interactions between applications. They are rigid and require developers to know the exact endpoints, methods, and data schemas in advance. This model breaks down when dealing with autonomous AI agents, which need to dynamically discover and decide which tools to use based on a high-level goal.

A standardized interface like MCP offers several benefits:

• Grounds answers in live data: A model that can fetch the current record or document has less reason to guess.
• Enables Complex Reasoning: Access to external tools allows an AI to break down complex problems into smaller, executable steps, such as searching for information, performing calculations, and then synthesizing a result.
• Enhances Flexibility: New tools can be added to the MCP server without changing the AI agent’s core logic. The agent can discover and use new capabilities on the fly.
• Concentrates access control: Tool calls go through servers you choose to deploy, which gives you one place to log calls, scope credentials, and decide which actions an agent may take.

Kestra’s AI plugin provides a rich set of tasks for building these kinds of agentic workflows.

Orchestrate AI tool calls with a Kestra MCP client: real-time documentation access

Most MCP traffic comes from interactive assistants, but the same servers are useful inside scheduled or event-driven workflows. A Kestra flow can call any MCP server directly, without a model in between, when the tool to call is already known. This is the deterministic counterpart to letting an agent decide.

The flow below connects to a documentation MCP server over Streamable HTTP, lists the tools it exposes, calls one of them, and logs the result.

id: mcp-client-documentation-search
namespace: company.team.ai

inputs:
  - id: question
    type: STRING
    defaults: How do I add a webhook trigger to a flow?

tasks:
  - id: list-tools
    type: io.kestra.plugin.ai.mcp.ListTools
    url: "{{ secret('DOCS_MCP_SERVER_URL') }}"
    headers:
      Authorization: "Bearer {{ secret('DOCS_MCP_TOKEN') }}"

  - id: search-docs
    type: io.kestra.plugin.ai.mcp.CallTool
    url: "{{ secret('DOCS_MCP_SERVER_URL') }}"
    headers:
      Authorization: "Bearer {{ secret('DOCS_MCP_TOKEN') }}"
    tool: search_docs
    arguments:
      query: "{{ inputs.question }}"

  - id: log-results
    type: io.kestra.plugin.core.log.Log
    message: |
      The server exposes {{ outputs['list-tools'].count }} tools.
      Answer: {{ outputs['search-docs'].result }}

What’s worth noticing in this flow:

• Discovery, then a call: ListTools returns the server’s tool catalog with each tool’s argument schema, and CallTool invokes one tool by name. Both default to the Streamable HTTP transport.
• No model in the loop: The tool and its arguments are fixed in YAML, so the call is repeatable and testable. When the choice of tool should be left to a model, attach the same server to an AI agent as a StreamableHttpMcpClient tool instead.
• Credentials stay in secrets: The server URL and token come from Kestra’s secret management rather than the flow definition.
• Usable downstream: The tool’s text answer is available as the result output, so later tasks can store it, post it, or pass it to another step in the same Kestra flow.

The reverse direction also works: the MCP Tool trigger exposes a Kestra flow as a tool, so an AI assistant can start a governed workflow instead of calling a production system directly. Kestra’s own MCP server also exposes plugins, blueprints, and documentation to coding agents.

MCP vs. traditional APIs: understanding the distinction

Building or choosing an MCP server

Many products now ship an official MCP server, so the first step is usually to check whether the system you need already has one. When it does not, SDKs for Python, TypeScript, and other languages let you wrap an existing API in a few dozen lines; frameworks such as FastMCP reduce this further. A few rules of thumb apply either way:

• Keep tools narrow. A tool called create_ticket with three arguments is easier for a model to use correctly than a generic call_api tool.
• Write descriptions for the model. The tool description is what the model reads to decide whether to call it, so it should say when to use the tool, not only what it does.
• Scope credentials per server. A read-only server for search and a separate server for write actions make it simpler to decide which agents get which capabilities.
• Put irreversible actions behind a workflow. Exposing a governed Kestra flow as the tool, rather than the raw production API, adds retries, logs, and an approval step where needed.

Where MCP servers pay off for AI orchestration

MCP servers are most useful where an AI application has to work with systems it does not own.

• Autonomous Data Analysis: An AI agent can use tools exposed by an MCP server to query databases, run statistical analyses, and generate visualizations to answer complex business questions.
• AI-Driven Infrastructure Management: An agent can interact with tools for Terraform, Ansible, or Kubernetes to provision, configure, or troubleshoot infrastructure based on natural language requests.
• Intelligent Customer Support: A support bot can use MCP tools to look up customer order information, process refunds, or escalate tickets within a CRM system.
• Content Generation Workflows: An AI can use tools to perform web searches for research, check facts in a knowledge base, and then write an article, all within a single, orchestrated AI agent workflow.

Related concepts

• What Is an AI Agent?
• Agentic Workflows
• Multi-Agent Systems
• Kestra MCP: Live Documentation Access for AI Coding Agents
• A Live Plugin and Blueprint Catalog for AI Coding Agents
• Context Engineering in Practice

MCP servers give AI applications a common way to reach tools and data. Orchestration decides what happens around those calls: when they run, with which credentials, and what is logged.