Commissioning an MCP server: supplier requirements

A custom MCP server becomes relevant when AI applications need access to internal systems without a suitable standard connector. The deliverable is more than a protocol endpoint. Define the data scope, permitted actions and responsibility for their consequences. A controlled first release might contain read-only tools, such as retrieving the status of a business case.

Starting point and project boundaries

• Define the business function an assistant should read or execute. A tool that reads order status is easier to scope than unrestricted database access.
• Separate information retrieval from changes to customers, agreements or orders. Write operations need accountable ownership and, where appropriate, approval.
• Map each intended client to real user identities and business roles; a shared technical account can obscure the required permissions.

Every tool needs a clear input schema and server-side authorisation. Authentication alone does not establish access to a specific record. Roles, organisations and confidentiality must also apply to nested relationships. Write actions need business validation, understandable results and protection against unintended repetition. Consequential steps should require explicit approval or a separate business workflow.

• MCP and REST should call the same business services for validation, authorisation and state changes.

Transport adapters translate the respective protocol.

• Validate the intended audience of an access token and the user's identity.

Do not pass tokens to downstream services without proper validation.

• Bound results and related objects.

Use targeted detail requests and pagination rather than recursively embedding entire datasets.

In this project, GSWE operates a Symfony backend with REST and MCP access. The code includes public API content, authenticated MCP access, role checks and an additional confidentiality permission. This internal technical foundation provides a concrete starting point for discussing implementation. It does not replace assessment of an individual customer’s requirements and system boundaries.

Practical acceptance scenarios for the first release

• The same user reads an order through REST and MCP. Visible fields, organisation boundaries and business status agree.
• A tool receives an unknown property or an invalid status transition. Both interfaces reject it using the same business rules.
• A client repeats a write action after a timeout. The system recognises the transaction instead of silently applying the change twice.

Request functional tests for public, authenticated and unauthorised users. Tests must cover execution and returned data, not just tool discovery. Partial updates should preserve omitted fields. Bounded field sizes, actionable validation messages and documented incremental steps help AI clients maintain structured content reliably.

Start by commissioning one narrowly scoped tool with limited consequences. Acceptance testing should distinguish anonymous access, authenticated users without business permissions and users without confidential-data clearance. Test partial updates: changing one text field must not erase unrelated content. Write tools also need business validation and a clear result describing which action was actually performed.

Separate read-only queries from actions with business consequences when approving tools. Input validation, explicit confirmation and audit records are particularly relevant for write operations. Acceptance testing should demonstrate that a publicly reachable endpoint does not expose protected records or tools when parameters are manipulated. Test both authenticated and anonymous callers.

A checklist for commissioning the work

• Request a tool inventory with input schemas, business purpose, required role and possible side effects.
• Agree on REST and MCP contract tests using identical example data, including missing permissions and invalid input.
• Check client compatibility, protocol version and disconnect handling in the intended environment; a local demonstration does not establish production reliability.

For a comparable proposal

• Identify the MCP client, source system and required read or write actions.
• Define inputs, permissions, returned data and confirmations for each tool.
• Include denied actions, invalid inputs and business-system outages in acceptance.

A sound MCP brief describes business functions and security boundaries. Quality includes ensuring that a user receives only the intended data and actions across both REST and MCP. A small, tested tool set can be a more useful starting point than broad access without dependable permission enforcement.

Assess the benefit and control further expansion

• Measure whether users can complete a business workflow reliably and how often manual correction is needed.
• Add tools only when roles, logging and failure handling are defined for the new actions as well.
• Treat MCP as an additional interface to business software, rather than establishing a second and divergent implementation of business rules.

Outline the action your AI client should perform in the business system. GSWE translates it into a bounded MCP tool scope with permissions and verifiable inputs and outputs.

Commission a custom MCP server: MCP server for AI integration and tool access.