Describe the smallest business function
Instead of a universal API query, a first server might expose “read order status.” Inputs are limited to an allowed identifier, and the response contains status, its timestamp and permitted next steps. MCP describes tools through names and schemas. The business contract must also specify unknown identifiers, missing permissions and stale data.
Check authentication and data access separately
For protected HTTP access, the MCP specification describes an OAuth-based flow with server-bound tokens. The server still has to verify whether the signed-in user may see a particular order. A valid service token does not authorize every record. Test tenant separation using at least two accounts with different data.
Make writes explicit and repeatable
Use separate read and write tools. A write identifies its target and intended new state, which the application shows before approval. A stable operation key detects repeated requests. A timeout must not create a second order. After the action, read the actual state and compare it with the intended outcome.
Test both connection and business effect
A successful tool list proves only connectivity. Acceptance covers valid and invalid input, other tenants’ records, expired authentication, bounded output and errors without secrets. A targeted end-to-end test then proves that an authorized user receives exactly the intended data. Add further functions only after that evidence.
Keep it verifiable
Primary sources
- MCP tools specification, 2025-11-25Source checked:
- MCP authorization specification, 2025-11-25Source checked:
