Get Started
What is Model Context Protocol (MCP)?
A practical guide to MCP — what it is, why it matters, how it differs from APIs, and how teams use MCP servers with registries and governance. Includes diagrams, a concise API vs MCP table, and links to Quickstart, Marketplace, and Platform Overview.
What is Model Context Protocol (MCP)?
Model Context Protocol (MCP) is an open standard that lets applications and agents discover and invoke capabilities exposed by MCP servers. Where APIs assume a developer reads docs and hand codes a client, MCP gives clients a uniform way to enumerate tools, understand schemas, authorize safely, and call actions—without bespoke glue for every service. MCP is protocol first and client agnostic. It works for LLM chat, IDEs, backend jobs, and multi agent systems - any client that speaks MCP.Quick answer — An MCP server publishes tools (capabilities) with machine readable schemas and auth. Any compliant client can discover those tools and invoke them over supported transports (stdio, SSE/HTTP).
MCP in simple terms
Before MCP, every integration was a one off, each client needed its own custom connector, schema, and auth flow: With MCP, those same actions are exposed once on a server. Any MCP-capable client can discover and use them safely, without bespoke glue.What is an MCP server?
An MCP server is a process that makes one or more tools available to clients.Tools are self describing units of capability. They tell a client what the action does, how to call it, and what the response looks like. Because tools are discoverable, a client can connect and start using them without custom SDKs or ad hoc parsing.
What does a tool include?
| Field | Purpose |
|---|---|
| Name and description | Human readable summary of the action |
| Input schema | Defines the required arguments and their types |
| Output schema | Describes the structure of the response |
| Transports and auth | Lists supported connection types and authentication methods |
What can servers expose?
- Internal systems such as finance, ticketing, or data warehouses
- SaaS platforms like GitHub, Slack, or CRM tools
- Custom business logic built for your team
How is MCP different from an API?
APIs expose endpoints for human developers. MCP exposes discoverable tools for autonomous clients that must understand capability boundaries, schemas, and context.| Aspect | Traditional API | MCP server |
|---|---|---|
| Primary user | Developer reading docs | Client that can discover and act |
| Discovery | Docs and sample code | Self describing tool list with schemas |
| Contract | Per vendor conventions | Consistent inputs and outputs across servers |
| Auth | Varies by service | Declared methods such as OAuth 2.1, API key, or JWT |
| Error handling | HTTP codes and ad hoc payloads | Structured errors designed for recovery |
| Context | Often stateless | Session and context aware when needed |
| Client surface | Custom SDKs | Any MCP capable client |
How MCP works
When a client connects to a server, it follows a simple sequence: connect, discover what is available, authorize, and then invoke tools. Registries and governance features layer on top to make this safe and consistent at scale.- Connect with stdio for local use or HTTP/SSE for remote servers
- Discover the manifest of tools, schemas, and supported authentication methods
- Authorize using OAuth 2.1, API key, or JWT as declared by the server
- Invoke tools with validated inputs and receive structured results or errors
- Govern usage through registries, version pinning, RBAC, and audit logs
Transports at a glance
| Transport | When to use | Notes |
|---|---|---|
| stdio | Local tools and IDE integrations | Simple setup for single user workflows |
| HTTP | Shared servers and services | Works well with standard gateways |
| Server sent events | Streaming outputs and long running work | Pairs with HTTP for production use |
What you can do with MCP
MCP is useful anywhere you want consistent, governed actions across systems. Instead of each integration being bespoke, clients can discover and combine tools from multiple servers to create safe workflows.Common scenarios
Developer and platform workflowsPlatform teams expose internal actions such as create repo, provision database, and roll back deployment as tools. Engineers discover and use them from IDEs or internal agents with consistent authorization and audit. New hires join the registry and inherit the same curated toolset. Operations and back office
Finance or HR teams can publish tools for tasks like submit invoice, reconcile payout, or approve expense. Agents can chain these actions while approvals remain human in the loop. Reporting and scheduled jobs
Instead of exposing raw databases, a team publishes reporting tools that return predefined metrics or views. Agents or schedulers invoke these safely on a schedule, producing consistent reports without direct database access. SaaS orchestration
Servers that expose Slack, GitHub, or CRM actions let agents and IDEs call them with the same interface. One registry environment can combine multiple SaaS and internal servers into a single workflow.
Composing tools across servers
Because MCP tools are self describing, clients can discover and chain them together across servers. A workflow might use one server for finance, another for ticketing, and another for communication, all governed by the same registry.Registries, versions, and environments
As usage grows, teams need a control plane. Registries provide it. Private registries curate which servers are visible to a team or project. Version pinning keeps CI, IDEs, and agents consistent. Approvals ensure new servers and versions are reviewed before rollout. Audit and usage metrics give one place to understand cost and latency. Use Pylee to create private registries, pin versions, set role based access, and manage the server lifecycle across teams. Start with Platform Overview and Pylee MarketplaceSecurity and governance
MCP enables consistent application of your security model. Authentication is declared by the server so clients follow the same flow across vendors. Scope tokens to specific tools or servers to enforce least privilege. Apply role based access so only the right people can see and invoke sensitive tools. Record server lifecycle and tool invocations for compliance and incident response. Enterprise rollout guidance lives in Platform ImplementationDeployment options
| Option | Typical use | Ownership |
|---|---|---|
| Local stdio | Development and single user tools | Developer or team |
| Remote HTTP and SSE | Shared team servers and production | Platform team |
| Hosted on Pylee | Managed auth, secrets, versions, and rollback controls | Pylee hosts, your team governs |
| Your VPC or on prem | Sensitive data and workflows | Your team. Available upon request. Contact sales. |
Example workflow from idea to governed rollout
- A team wraps an internal finance action as a tool named create_invoice
- They publish the server to a staging registry and request approval
- Security reviews scopes, auth, and logging, then approves version 1.0 to production
- Platform pins version 1.0 for all users in the production registry so CI and IDEs update in a predictable way
- Usage and latency appear on dashboards. If a problem appears, roll back to the prior version
Where to go next
Learn the why: Why Build MCP ServersTry servers today: Quickstart and Pylee Marketplace
Plan the rollout: Platform Overview and Enterprise Implementation
FAQs
Is MCP a network protocolIt is an application layer protocol that runs over transports such as stdio and HTTP with server sent events. The focus is capability discovery, safe invocation, and consistent authorization. Do I need an LLM to use MCP
No. MCP is client agnostic. Back end services, web apps, IDEs, and agents can all be clients. Can I keep my existing APIs
Yes. Many teams wrap key APIs with MCP servers to gain uniform discovery and governance for internal users, IDEs, and agents while keeping public APIs for partners. Does Pylee lock me in
No. MCP is an open standard. Pylee provides a registry, version pinning, role based access, and a vault so you can govern usage across teams. Your servers remain portable. How do I avoid excess privilege
Expose the smallest useful tools, scope credentials, apply role based access per environment, pin versions, and require approvals for new servers and versions.