Model Context Protocol

Model Context Protocol—usually shortened to MCP—is a standard way for an AI application to discover information and tools provided by another system.

An everyday analogy is a universal adapter. Instead of building a completely different connection for every AI application and business service, MCP gives them a common way to describe what is available and exchange requests.

MCP does not, by itself, decide what a business record means, who may change it, or whether an action needs approval. That remains the responsibility of the system behind the connection.

A simple example

Suppose an employee uses an AI workspace and asks:

Show me the open service cases assigned to my team and prepare a summary for tomorrow’s meeting.

Through an approved Paraline MCP connection, the AI application could discover a read tool for assigned cases, request the permitted records, and prepare the summary.

The AI application should not receive every customer record simply because a connection exists. Paraline still resolves the employee’s identity, workspace, team, field access, and tool permission.

If the employee then asks the AI to close a case, that is a separate business action with its own state, validation, and approval rules.

The basic parts of MCP

MCP uses a host, client, and server model.

Host

The AI application the user interacts with.

Client

The part of the host that maintains a connection to one MCP server.

Server

A program that exposes context or capabilities to compatible clients.

The protocol includes several useful primitives:

• Resources provide contextual information.
• Tools provide executable capabilities.
• Prompts provide reusable interaction templates.

The official MCP architecture documentation defines the protocol. Paraline’s documentation describes how that protocol could fit into the product, not a separate MCP specification.

Paraline as an MCP server

If Paraline acts as a server, an external AI application could discover approved workspace context and business tools.

Tools should express business intent. request_refund_review is clearer and safer than update_field. propose_workflow_change is more reviewable than unrestricted database or source-code access.

Paraline as an MCP client

Paraline agents could also connect to external MCP servers. That might let an agent retrieve approved documents, communicate through another service, or request work in a CRM or developer platform.

In this direction, Paraline decides which external server and capabilities an agent may use. The workflow should preserve:

• the connection and tool requested;
• the input supplied;
• the result returned;
• the identity and approval involved;
• and any error or uncertainty.

Connecting to a server does not make every tool on that server appropriate for every agent.

Connection is not the same as authority

Authentication may establish a connection. Business authorization still needs several scopes.

Connection scope

Which external or Paraline server can be reached?

Workspace scope

Which organization or client environment is involved?

Data scope

Which objects, records, and fields may be read?

Action scope

Which business tools may be requested?

Approval policy

Which otherwise valid requests must pause for a person?

A connection credential should not silently override a narrow agent role.

Tools should be understandable to people

Although an MCP tool is used by software, its name and description should make its business effect clear.

Inputs should distinguish required information from optional guidance. Errors should explain whether the problem is invalid input, missing permission, conflicting state, an unavailable dependency, or required approval.

High-impact work can use a proposal pattern:

1. create a structured proposal;
2. preview the expected effect;
3. obtain approval;
4. execute the approved action.

This prevents tool discovery from becoming authority to create an irreversible effect.

Long-running work needs state outside the connection

An MCP call may begin work that lasts longer than the client session. The tool can return a run identifier while Paraline preserves progress, waiting, retries, and outcome.

If the AI application disconnects, the business responsibility should still be visible. A person or later process should be able to see whether the work completed, failed, or remains open.

Keep the complete activity chain

One request may involve a person, AI host, agent, Paraline runtime, and external service. Each participant has a distinct identity and authority.

The history should show who initiated the request, which client and tool were used, what Paraline action ran, which approval occurred, and what result was recorded.

MCP is a strong fit for Paraline because it separates AI applications from the systems that provide context and capabilities. It does not remove the need for a data model, permissions, workflow state, or governance.

Paraline MCP server and client interfaces are planned. Public tools, resources, authorization flows, and transport choices are not yet versioned releases.