MCP best practices: security, design & performance

Security first

A hosted MCP server is a doorway into your business, so treat it like one. Three non-negotiables:

• Authenticate every request. Require a bearer token and reject anything else. No anonymous access, ever.
• Use HTTPS end to end. Tokens and data must never cross the wire in the clear.
• Validate every input on the server. The declared schema tells the model what to send; server-side validation is what protects you when it sends something else. Assume tool arguments are hostile.

Destructive or sensitive tools deserve an extra gate. Actions like sending email or launching an ad campaign should be approval-gated — the tool returns a "pending approval" result, and a human confirms before it executes. This keeps agents useful without handing them the keys.

Scope every tool

The blast radius of an MCP endpoint is the set of tools its token can reach. Keep that set small and intentional. Map each key to an explicit allowlist rather than exposing everything by default, and cap the total number of tools a single connection surfaces — too many choices degrades model accuracy as well as safety.

Think in terms of least privilege: a reporting agent needs read tools, not delete_contact. Issuing purpose-specific keys is cheaper than debugging why an agent mutated production.

Design tools for models

Models are not reading your source — they are reading your tool descriptions. Design accordingly.

• Name tools `verb_noun`: get_analytics, create_task, send_email. Predictable names help the model generalize.
• Write descriptions as instructions. State what the tool does and *when to use it*. "Get session and revenue metrics for a date range" beats "analytics endpoint".
• Keep inputs flat and typed. Prefer a handful of well-described scalar parameters over deeply nested objects.
• Return structured results. JSON the model can parse and an automation can consume beats free-form prose.
• Fail loudly and legibly. An error result should say what went wrong so the model can retry correctly.

Fewer, sharper tools beat a sprawling catalog. If two tools overlap, merge them; if one tool does five things, split it.

Rate limits & cost

Agents are tireless, which is a feature until it is a bill. Protect yourself on two axes:

• Rate limits per caller blunt abuse and runaway loops. Return proper limit responses so well-behaved clients back off.
• A per-run cost ceiling stops a single task before it spends more than you would allow. Track cumulative cost inside the loop and abort at the cap.

Metering matters too. Counting usage — events, tool calls, tokens — lets you price fairly and spot anomalies before they become incidents.

Observability

If you cannot see what your agents did, you cannot trust them. Log every tool call with the caller, arguments, result, latency, and cost. Keep a durable audit trail, not just ephemeral logs, so you can answer "who changed this and why" weeks later. Surface a live view of in-flight runs so a human can intervene. Good observability is what turns "the AI did something" into "here is exactly what happened".

What BusinessMCP handles for you

Running all of this yourself is real work. BusinessMCP bakes these practices in: Bearer mcph_* authentication on the endpoint, per-connection tool allowlists, a cap on connector tools, a per-run cost ceiling, event-based quotas, approval gates on sensitive actions, and a full log of every tool call. You get the governance of a hardened MCP server without building the harness. To go from here, see expose your MCP endpoint.