jump to content

the platform MCP server

Introduces the the platform MCP server, covering how connections authenticate, the 293 available tools, read-only testing, and the MCP Inspector.

View as Markdown

The the platform MCP server lets AI assistants and developer tools work with your the platform data through the open Model Context Protocol. A connected client can discover the platform tools, inspect their input schemas, and—with your authorization—read or change organization-scoped records.

Use MCP when you want to:

  • Ask questions that require live context from the platform.
  • Review risks, controls, evidence, audits, and other compliance records.
  • Create or update records from an AI assistant.
  • Build an agentic workflow without implementing each the platform API operation.
  1. Your MCP client connects to the regional or self-hosted the platform endpoint.
  2. the platform authenticates the connection with interactive OAuth or a scoped OAuth token.
  3. During initialization, the client discovers the tools available from the server and their JSON schemas.
  4. The client selects a tool based on your request and asks for approval when its policy requires it.
  5. the platform checks both the token scopes and the underlying user’s permissions before running the operation.

MCP does not bypass the platform’s access controls. A token can only access an organization and perform an operation when both its granted scopes and its user’s permissions allow it.

Choose the endpoint for the deployment that contains your data:

DeploymentMCP endpoint
the platform UShttps://us.probo.com/api/mcp/v1
the platform EUhttps://eu.probo.com/api/mcp/v1
Self-hostedhttps://<your-host>/api/mcp/v1

The /api/mcp/v1 path is required. the platform serves MCP over Streamable HTTP; it does not expose REST-style routes for individual tools.

Most interactive clients discover the platform’s OAuth configuration and open a browser authorization flow. For a client that requires static configuration, create a scoped OAuth token in the platform and send it as a bearer credential.

After connecting a client, confirm the identity and organization boundary before asking it to change data:

Use Probo to list the organizations I can access. Do not change anything.

Then include an organization in a narrow request:

For organization org_xxx, summarize open high-priority risks and cite the
record names and IDs. Do not change anything.

Explicit organization IDs remove ambiguity when an account can access more than one organization. Treat all IDs and pagination cursors as opaque strings.

When you are ready to test a write, state the intended result and ask the client to show the proposed arguments before invoking the tool:

Prepare a new third party named Acme Corp for cloud hosting in organization
org_xxx. Show me the tool and arguments first; do not create it until I approve.

The exact approval experience depends on the MCP client.

the platform currently exposes 293 tools generated from its server specification. They cover organizations, risks, controls, frameworks, evidence, documents, audits, findings, privacy, third parties, access reviews, webhooks, cookie consent, and other compliance workflows.

Each tool advertises:

  • A name and description used by the client to select it.
  • JSON input and output schemas.
  • Behavior hints such as read-only, destructive, and idempotent.

Behavior hints help clients present safer approvals, but they do not replace reviewing the tool arguments. The generated reference reflects the current server specification:

Use the MCP Inspector to explore the the platform MCP Server interactively:

export PROBO_OAUTH_TOKEN="your_oauth_token"
npx @modelcontextprotocol/inspector --cli \
  https://us.probo.com/api/mcp/v1 \
  --transport http \
  --header "Authorization: Bearer $PROBO_OAUTH_TOKEN" \
  --method tools/list

The command lists the tools available through the server. Replace the endpoint for the EU region or a self-hosted deployment. The Inspector can also browse schemas, call tools, and expose protocol errors while troubleshooting.

  • Give each client or environment its own token so access can be revoked independently.
  • Grant only the scopes required by the workflow.
  • Keep credentials out of source control, logs, shared configuration, and prompts.
  • Require explicit approval for write and destructive tools.
  • Paginate list operations until next_cursor is absent when a complete result set is required.
  • Revoke exposed or unused credentials promptly.

Ultima actualizare: