# Use the MCP bridge safely

> Distinguish workspace authoring from live-call MCP tools, scope both connections, and verify discovery, credentials, drafts, and runtime behavior separately.

{/* Generated by scripts/sync_docs_handbook.mjs from the preserved in-app docs. */}

Menace Voice participates in the Model Context Protocol (MCP) in two directions. The Menace Voice MCP server lets an implementation assistant work on your workspace. An MCP Server tool attached to a workflow lets the live voice agent call a different remote MCP server during a conversation. They use different endpoints, credentials, permissions, and verification steps.

## Workspace authoring MCP

- Endpoint: the hosted or self-hosted Menace Voice backend at /api/v1/mcp/.
- Authentication: X-API-Key using an organization-scoped Menace Voice API key.
- Purpose: browse Menace Voice docs and workspace resources, discover node schemas, create reusable tools, and create or edit workflows.
- Mutation boundary: new workflows are created as published version 1; edits to existing workflows are saved as drafts for human review.
- Operational rule: use a dedicated key, keep it outside the repository, verify the selected organization, and revoke it when no longer needed.

## Live-call MCP Server tools

- Endpoint: a remote Streamable HTTP MCP URL configured as a reusable Menace Voice tool.
- Authentication: the credential required by that remote server, commonly a saved Bearer Token credential.
- Purpose: expose selected remote functions to the model during a Web Call or phone conversation.
- Runtime behavior: Menace Voice discovers and caches the catalog, opens a live session for the attached server, namespaces functions, forwards selected calls, and returns results to the model.
- Failure behavior: if the remote server is unavailable, the conversation can continue without those functions; the node prompt still needs an honest fallback.

## Apply least privilege at every layer

- Confirm the remote server owner and exact URL before saving it; use separate development and production credentials.
- Filter the discovered catalog at server level, then select the smallest function set at each node.
- Give the remote credential only the permissions those functions need and document its owner and rotation path.
- Keep the model-facing description about capability and invocation, not about tokens or internal authorization details.
- Review function name, arguments, duration, and result in a real run without copying secrets or sensitive payloads into logs.

> **Discovery is not authorization**
>
> A successfully discovered remote function is only available to the model. The remote server must still authenticate the request, authorize the underlying resource, validate arguments, and make state-changing operations safe against duplicates.

## Verify each boundary separately

- Authoring MCP: verify the client can list the intended workspace, read current workflow code, and perform a read-only docs query.
- Tool creation: verify create_tool returns created: true and the expected tool UUID and discovered catalog.
- Workflow draft: verify save_workflow returns saved: true and that the published version is unchanged.
- Live call: verify the intended utterance invokes the allowed remote function with supported arguments and handles unavailability without inventing a result.

Finish with the [Production checklist](/handbook/agents/production-checklist) before an implementation-agent change is published to real traffic.