Six months into the Model Context Protocol boom, teams keep wrapping APIs and calling the result an AI integration.
A thin wrapper gives the model a list of endpoints. It also makes the model handle pagination, tool selection, permissions, ordering, and recovery. API designers assume a developer understands the system around each endpoint.
Consider this request:
Find failed logins from suspicious IPs.
A basic server exposes list_logs() and get_log(). The model has to fetch pages, choose filters, correlate addresses, and avoid returning data outside the user's permissions. The wrapper puts an orchestration problem inside a probabilistic loop.
start with the job
Design a tool such as investigate_suspicious_logins() around the user's task. Put the safe defaults, required filters, and domain checks inside the implementation. Return the evidence the model needs for the next decision.
A useful abstraction may combine several API calls because the server owns the domain mechanics and leaves the model to handle user intent.
I work at Auth0, and my first Auth0 MCP server wrapped APIs. Users wanted higher-level tasks such as "set up auth for my project." I rebuilt the tools around those jobs, and users could finish the workflow.
a quick test
Review each tool and answer two questions:
- Does the name describe a user job or an API operation?
- Does the implementation carry the domain rules the model would otherwise have to infer?
Measure success by workflow completion.
Build MCP servers around the work users came to finish, then expose the minimum tool surface that supports it.