An MCP server should not expose hundreds of raw actions as separate tools. A compact surface works better: list what exists, inspect the schema, run approved actions, return history, and preserve clear gates for risky execution.

Why this is not generic advice

This page is written from Pullmesh source-package behavior, buyer handoff boundaries, and the actual operational controls described on the product page: capability numbers, export surfaces, approval gates, provenance, and exclusions.

Key takeaways

  • Keep the MCP surface small even when the local registry is large.
  • Let agents discover actions before calling them.
  • Return risk and required confirmation details before execution.
  • Use local logs as the durable audit layer.

Do not turn every action into a tool

A registry can contain hundreds of actions. Exposing each as a separate MCP tool creates a noisy interface and makes policy harder to inspect.

The Pullmesh workflow kit uses the opposite shape: a compact MCP layer with 10 tools over a registry of 196 local actions. The agent can list, inspect, run, and review without seeing a chaotic tool list.

Make discovery first-class

Agents need a way to ask what actions exist, which inputs are required, whether the action is read-only, and what risk tier applies.

Discovery output should be concise enough for model context and specific enough for safe planning. It should include IDs, categories, modes, risk, required inputs, and confirmation requirements.

Treat execution as a controlled gateway

The run tool should validate input, enforce confirmation rules, execute the action, and return a compact result. For long or sensitive outputs, return a pointer or summary while writing the full redacted record locally.

This makes the MCP server useful for agents without turning it into an uncontrolled browser remote-control layer.

Expose workflow-level tools when they are real

Once a sequence becomes common, it deserves a higher-level tool. The Pullmesh kit includes a recruiter workflow prototype that can source, enrich, plan, ask for review, and write outcomes to a local CRM shape.

That is the level where agents become useful: not a bag of clicks, but a governed loop with memory and review points.

MCP action-surface checklist

  • List actions by category, mode, risk, and required inputs.
  • Show action details before execution.
  • Run only through one validated execution gateway.
  • Expose confirmation and force requirements in responses.
  • Persist redacted run history locally.
  • Add workflow-level tools only for coherent multi-step loops.

pullmesh package

Professional-network workflow kit

This article maps to the working source package rather than a generic content campaign. Review the product scope, proof points, exclusions, and handoff path.

Open product

FAQ

Why use a compact MCP surface?

It reduces tool noise, makes planning easier, and keeps risk logic in one execution path instead of scattering it across many small tools.

What should an MCP tool return after execution?

A compact status, useful output fields, risk/approval context, and a reference to local redacted history when the full result is large or sensitive.

Can MCP replace the CLI?

Not completely. The CLI remains valuable for operators, smoke tests, local debugging, and explicit manual runs. MCP is the agent-facing layer over that foundation.