Key facts
| What MCP is | Protocol for exposing tools, resources and prompts to compatible clients |
| Topology | Host application runs clients; each client connects to one or more servers |
| Transports | Local stdio for trusted processes; HTTP for remote services |
| Discovery | Servers advertise tools and resources; clients expose them to the model as callable functions |
| Security controls | Least-privilege scoping, authentication, allow-lists and argument validation |
| Invocation | Function calling is live on Plugsky chat models; MCP supplies the tool surface |
| Models | 30+ models behind one OpenAI-compatible API; tool support varies by model |
| Free tier | Free plan with 2 free AI models, no card required |
TL;DR
- MCP is plumbing: it moves tool definitions and results, not decisions.
- Treat every MCP server as a privilege boundary and scope it tightly.
- Prefer stdio for local tools and authenticated HTTP for remote ones.
- Validate arguments and log every call with a trace id.
- Never grant a server more access than the narrowest useful task requires.
How it works, step by step
- Inventory the tools agents need and group them into servers by trust level and data domain.
- Choose a transport: stdio for local processes, authenticated HTTP for shared services.
- Implement each server with least-privilege credentials and read-only defaults where possible.
- Expose only the tools required, with strict JSON schemas and clear descriptions.
- Wire the client into the agent and convert discovered tools into function-calling schemas.
- Log calls, review usage, and rotate credentials on a schedule.
Try it yourself
Open the MCP server config generator →
MCP architecture in practice
Three roles: the host application (your agent or IDE), clients that maintain connections, and servers that expose capabilities. A server advertises tools for actions, resources for readable data and prompts for templates. The client discovers them and presents tool definitions to the model, which selects one via function calling. The client routes the call to the server and returns the result to the model. Keep servers small and domain-specific — one for issue tracking, one for the database, one for documentation.
Threat model for MCP
- Over-privileged servers: a database server with write access when the task only reads.
- Prompt injection through tool output: untrusted content instructs the agent to call another tool.
- Remote server trust: an HTTP endpoint you do not control can return anything.
- Credential sprawl: long-lived tokens embedded in config files.
- Silent data exfiltration: a server with network access and read access to secrets.
Address each with least privilege, egress control, validation and logging.
Secure configuration patterns
Run local servers as separate processes under a dedicated user with filesystem access limited to what they need. Prefer read-only credentials and escalate through a separate, auditable tool. For remote servers, require authenticated transport, pin endpoints, and review what the server logs. Validate every argument against the schema before execution, set timeouts and idempotency keys, and require human confirmation for destructive actions. These are the same controls as any tool-calling integration — MCP just standardizes where they live.
Building the agent side on Plugsky
The agent side is a function-calling loop. Discover MCP tools at session start, convert them into function schemas, and send them with the chat completion request through Plugsky's OpenAI-compatible endpoint. Use a capable model for tool selection, cap loop iterations, and log the full trace. Because 30+ models share one API, you can test tool reliability across models and route production traffic to the one that handles your tool set most accurately.
Honest comparison
| Concern | Safe baseline | Common mistake | Impact if ignored |
|---|---|---|---|
| Permissions | Read-only by default | Admin credentials for convenience | Data loss or exfiltration |
| Transport | stdio locally, authenticated HTTP remotely | Unauthenticated remote HTTP | Unauthorized tool calls |
| Tool surface | Minimal schemas, clear descriptions | Everything enabled | Wrong tool selection |
| Arguments | Schema validation before execution | Pass-through execution | Injection and malformed calls |
| Auditability | Trace ids and call logs | No logging | Unrecoverable incidents |
Frequently asked questions
Does Plugsky support MCP?
MCP is a client-side protocol. Plugsky supports the function calling that MCP tools ultimately rely on, and MCP-compatible agents work against Plugsky's OpenAI-compatible endpoint.
What is the difference between MCP and function calling?
MCP standardizes how tools and resources are exposed to clients; function calling is how a model requests a tool with structured arguments. Agents typically use both.
Is stdio or HTTP the safer transport?
stdio is generally safer for local, trusted tools because there is no network exposure. Remote HTTP requires authentication, transport security and endpoint pinning.
How do I prevent prompt injection through tools?
Treat tool output as untrusted, validate all arguments, restrict which tools can be chained, and require confirmation for destructive actions.
Should every integration be an MCP server?
No. If a single application needs a tool, direct function calling is simpler. Use MCP when multiple clients or teams share the same capabilities.
How many tools should one server expose?
Group by domain and trust level, and expose the minimum set. Smaller servers are easier to scope, audit and revoke than one large server.