Skip to main content
MCP lets your assistant use StateSet tools to inspect records, configure agents, run workflows, and review results. Each server exposes a particular system; connecting one does not connect all of your business data or authorize every operation. New here? Follow Manage Agents & Workflows with MCP for connection steps and copyable first-task prompts. To understand the systems behind the tools, read Rust engines and MCP.

​
Which server do I want?

Tool counts change and may be filtered by authorization or profile. Discover the actual catalogue through tools/list; a number in a guide is not evidence that your credential can call a particular tool.

​
Start with one of three connections

For portal-provisioned services, the MCP screen provides client-specific configuration and connection requirements. For direct service access, follow the server’s guide. OAuth, workspace keys, and service-specific API keys are different paths; use one the deployed server actually accepts.

​
Two transports

stdio: your host launches a local server process and exchanges MCP messages with it. The process might operate a local database or act as a bridge to a remote API. Local transport does not imply that all tool execution is offline. Streamable HTTP: your host connects to a server URL using that service’s authentication. Response and Workstream expose MCP through their deployed services; an additional MCP process is not required on those servers. Use your client’s supported connection format. If it needs a stdio bridge to a remote server, follow the client/server setup instructions rather than putting an HTTP URL in a command field. Exported environment-variable placeholders must be resolved by the host; they are not credentials by themselves. Some server guides describe repository builds as well as packaged installation. Follow the available distribution path and check version requirements before assuming an npx command exists for every service.

​
Verify the connection before making changes

Success: a real tool result identifies the expected data source. An HTTP connection or a visible tool list alone does not prove that a business operation succeeded. When a connection fails, distinguish an invalid credential, missing scope, unavailable service, and a tool error. Do not replay a failed write just to test connectivity.

​
Scoping access

Choose credentials and tool policies that match the task. A prompt asking for read-only work does not revoke write permissions from a key. Use server-side controls and the host’s approval settings together. For iCommerce, follow the server’s explicit write configuration; the starter connection is preview-only for mutations. For other servers, inspect the actual capabilities and policies rather than assuming the same default.

​
A useful operating loop

  1. Read the current records, configuration, and evidence.
  2. Propose one task or change tied to a business outcome.
  3. Validate the inputs, permissions, and expected effect.
  4. Execute only the authorized operation, retaining its returned IDs.
  5. Read back state and inspect the downstream result.
  6. Preserve a failed example or corrected answer as a future check where supported.
Use the first-week guide to apply this loop to live support and workflow operations. Use NSR MCP when your design needs a separate policy decision and proof; a decision does not itself execute the business action.

​
Building your own

To expose your own service to agents, start with the MCP integration guide. Define the input/output contract, authorization, replay behavior, and result-verification path alongside the tool itself.
Last modified on September 20, 2026