What is MCP?

MCP stands for Model Context Protocol—an open standard for connecting AI hosts and agents with tools, readable resources, optional prompts, and (when you build an MCP App) embedded UI served over the same protocol.

What MCP defines

Hosts and servers speak JSON-RPC over HTTP (or other transports, depending on the stack). Discovery and use typically follow these operations:

That gives models and hosts a stable contract: what can be invoked, what can be read, and how arguments are shaped—without each integration inventing a one-off HTTP API.

MCP Apps (embedded UI)

An MCP App is still an MCP server, but one that also exposes UI as resources—usually HTML returned from resources/read. The host loads that content in an embedded surface (for example an iframe) and keeps using tools/call for actions.

In practice, MCP Apps combine:

• Tools — Drive behavior and return data; tools/list may include _meta that points at a resource URI for the UI that goes with a tool.
• Resources — resources/list / resources/read deliver the widget bundle or HTML shell; content _meta can carry embedding hints and CSP-style rules (allowed origins for scripts, connect-src, and similar) so the UI can safely talk to your API and the host.
• Widget runtime — UI code (for example via @modelcontextprotocol/ext-apps) often calls callServerTool so the iframe can invoke MCP tools the host exposes—names and arguments must match what the host actually publishes after any upstream mapping.

MCP allows extensible _meta on tools, resources, and resource contents; hosts may define vendor-specific keys for templates and security—those are conventions on top of the core protocol, not a separate wire format.

For implementers, the formal reference is MCP App (widgets) metadata and MCP server metadata.

How Agentsyx uses MCP

Agentsyx sits between the AI host and your MCP servers:

Upstream connectors

Upstream connectors expose the MCP endpoint the host calls. End users reach your product through your SaaS and/or the host’s chat or agent UI. An upstream connector:

• Publishes tools (and, for MCP Apps, resources / prompts you choose to expose)
• Applies authentication, billing, and usage for that surface
• Routes each tools/call (and related MCP methods) to the right downstream implementation according to your tool mapping

Downstream connectors

Downstream connectors are the MCP server URLs (and credentials) that do the work Agentsyx forwards to. Examples:

• Your own MCP server — Domain logic, databases, APIs
• MCP App server — Tools plus resources/read for widget HTML (often deployed alongside a separate “data” MCP server; see Multi-connector architecture)
• Zapier, Make, or n8n MCP — Tools backed by those platforms’ integrations; see Integration platforms

The flow

1. The end user uses your product via your web app and/or an AI host
2. The host calls MCP methods on your upstream endpoint (Agentsyx)
3. Agentsyx applies auth, billing, and routing
4. Agentsyx calls the mapped downstream MCP server (for example your API MCP or an integration platform)
5. Results return through Agentsyx to the host and the user—including resource payloads when the host loads an MCP App UI

Why this matters

• One protocol for tools, optional resources and prompts, and MCP App UI—hosts and proxies can support many products the same way.
• Composable backends — Mix custom MCP servers with integration platforms; remap tools in Creator without changing the host’s view of your upstream catalog.
• Operational control — Agentsyx adds org-aware routing, injected context, and monetization on top of standard MCP.

Next steps

• Learn about Key Features
• Get started with Getting Started Guide
• See How to Create a Downstream Connector
• Deep dive: MCP Integration Reference