The short answer

AgentPlat MCP Runtime is an optional adapter that exposes Room operations to an MCP client using your deployment’s services and credentials. The host supplies identity, authorization, audit and durable idempotency; the adapter does not provide a shared hosted endpoint.

Choose operational access or documentation access

An assistant looking up an API and an assistant creating a Room task need different access. The MCP Runtime guide distinguishes the operational adapter from the optional read-only documentation MCP.

Use documentation access when the client only needs specifications and examples. Choose runtime access when it must work with an existing instance. Installing a documentation integration does not establish permission to operate that instance, and installing the runtime package does not create an AgentPlat-hosted account.

Compose the server with the real application boundary

The documented runtime composition takes a Room service, authenticated tenant and actor, an authorizer, an audit sink and an idempotency store. Transport and process lifecycle remain with the host.

For an illustrative internal assistant, resolve the signed-in employee and organization before exposing Room tools. Configure the authorizer to restrict both the operations and the Rooms they can address. A client able to connect to the transport should not automatically see every organization's work.

Treat mutation confirmation as one requirement

The runtime guide requires confirm: true and an idempotency key for its documented mutation tools. These include creating work, sending a message, submitting an artifact and requesting approval.

Those fields do not replace authorization or a human decision required by Room policy. A request to create an approval is not the approval itself. Preserve the operation key when retrying the same request, and use a durable store so a server restart does not erase the adapter's retry history.

Keep connector actions subject to their own controls

A tool that submits a draft into a Room and a provider that sends that draft externally cross different boundaries. The execution integration guide explains checkpoint enforcement and effect-specific reconciliation.

Review the path from MCP tool to Room service and then to any provider. A model's decision to invoke a tool should not bypass the deployment's task or action controls. The HTTP adapter is another transport surface around related services, not a reason to weaken the MCP boundary.

Verify the client with bounded operations

  1. Read a Room the principal is allowed to inspect.
  2. Attempt access to an unauthorized Room.
  3. Create one allowed task with the required confirmation and key.
  4. Repeat that operation after restarting the adapter.
  5. Inspect the retained task identity and audit record.

Use synthetic work for this integration check. Record the adapter version and host policy so the result explains what the configured client can actually do.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.