Slab5Documentation

External MCP tools

External MCP tools let a workspace owner connect a remote MCP server so AgentGrid and App Studio can discover and use third-party or customer-hosted tools through Slab5's policy layer.

Use this when a team already has an MCP-compatible service for tools such as content publishing, CRM enrichment, internal search, reporting, or operational actions that are not native Slab5 modules.

What external MCP tools do

An external MCP connection is a workspace-scoped tool source. Slab5 can:

  • connect to a remote MCP endpoint
  • run live tool discovery
  • classify discovered tools by risk
  • require owner approval before execution
  • enforce allowed risk levels, denied tools, tool allowlists, and read-only policy
  • run approved tool calls through a Slab5 broker endpoint
  • write tool-call, audit, and usage records for execution
  • expose approved executable tools as App Studio context

External MCP tools are different from native Slab5 MCP tools. Native tools operate directly on Slab5 workspace records. External MCP tools call a remote MCP server after the workspace owner connects and approves that tool source.

Connection flow

Workspace owners manage external MCP connections from AgentGrid → Tools.

  1. Add a connection and choose External MCP endpoint.
  2. Enter a name and remote MCP endpoint URL.
  3. Add a secret reference for the credential used by the external server.
  4. Create and discover tools.
  5. Review the discovered tools in the connection details modal.
  6. Approve only the tools the workspace should allow.
  7. Expand allowed risk levels only when the owner is comfortable with those actions.
  8. Test approved tools with JSON arguments before using them in workflow or assistant contexts.

In production, external MCP endpoints must use HTTPS. Slab5 blocks localhost, private network, loopback, and DNS results that resolve to private or loopback IP addresses.

Approval and risk policy

Every discovered tool has an approval state:

StateMeaning
DiscoveredSlab5 found the tool, but it is not approved for execution.
ApprovedThe workspace owner has allowed this tool to run when policy permits it.
DeniedThe tool is explicitly blocked for this connection.

Slab5 classifies external tools into risk levels:

RiskTypical examples
readsearch, list, fetch, query, summarize
writecreate, update, upload, schedule
external_side_effectsend, post, publish, message, notify, comment
criticalpayments, invoices, deployments, credentials, admin changes
destructivedelete, remove, revoke, disable, drop

Connection policy has two important controls:

  • Allowed risks: read is the baseline. Owners can explicitly allow higher-risk classes such as write or external_side_effect.
  • Write policy: approval_required allows approved tools subject to risk policy and confirmation. read_only blocks all non-read tools even when they are approved.

Tool execution is denied when any of these checks fail:

  • the connection is not active
  • the connection is not in the current tenant and workspace
  • the tool was not discovered for that connection
  • the tool is not approved
  • the tool is denied
  • the tool is outside an allowlist
  • the tool risk is not allowed
  • the connection is read-only and the tool is not read
  • a write, critical, destructive, or external-side-effect tool lacks explicit confirmation

Testing tools

Owners can test an approved external MCP tool from the connection details modal.

The test call accepts JSON arguments and runs through the same Slab5 broker and policy checks used by workflow and App Studio execution. Test calls are useful for verifying:

  • credential references are configured correctly
  • the remote MCP server responds to tools/call
  • the tool input schema matches the expected JSON
  • the risk and approval policy blocks unsafe calls
  • audit, usage, and tool-call records are written

For side-effect tools, test with safe sandbox credentials or non-production targets first.

App Studio context

When App Studio is enabled for a workspace, approved external MCP tools can appear in the assistant's tool context. App Studio sees the connection name, approved executable tool names, risk level, descriptions, and schemas after Slab5 applies the connection policy.

App Studio does not get unrestricted access to the remote server. It can only request brokered execution of approved tools that pass tenant, workspace, approval, risk, and write-policy checks.

Security boundary

External MCP tools run through Slab5's workspace boundary:

  • connections are scoped to a tenant and workspace
  • only workspace owners can add connections, approve tools, or expand risk policy
  • endpoint validation blocks private network targets in production
  • clients cannot bypass the Slab5 broker by approving tools from App Studio
  • tool calls record audit events, usage events, request IDs, inputs, outputs, errors, and duration
  • raw secrets should be stored outside Slab5 and referenced through secret references

Keep third-party tool scopes narrow. A remote MCP server should expose only the operations that the workspace intends to use.

Current limitations

External MCP tools currently assume credentials or OAuth are handled outside Slab5 and exposed to the remote MCP server through a workspace-controlled secret reference.

Slab5 does not yet provide a curated connector registry, built-in OAuth consent flow for each third-party app, or managed token refresh for external providers. Those capabilities can be added later without changing the workspace approval model: discover the remote tools, score the risks, require owner approval, and execute through the Slab5 broker.

Was this page helpful?