MCP Server

1Security ships a built-in MCP server (Model Context Protocol) so an AI assistant - Claude, a SOC copilot, or any agent framework that speaks MCP - can query your tenant's security data directly. It exposes the same read-only data as the REST API, as typed tools: an assistant connected to it can answer "which detections opened this week?", pull the audit trail for a user, or fetch the compliance status document, without you writing any connector code.

The MCP server and the REST API are one surface. Same API keys, same scopes, same plan gate, same rate limit, same response shapes. A tool call and the matching REST request return byte-identical payloads.

EndpointCopy Anchor Link

The server speaks the MCP Streamable HTTP transport and is stateless - each call is a self-contained request-response cycle, with no session to establish.

Only POST is supported. There is no server-initiated notification stream (GET returns 405), which is exactly what stateless MCP clients expect.

AuthenticationCopy Anchor Link

Authenticate with the same per-tenant API key the REST API uses, sent as a bearer token:

Authorization: Bearer 1sec_live_…

Keys are created in the dashboard under Settings → API. The key's scopes decide which tools the server registers: tools/list only ever shows what the key can actually call, so a logs-only key presents a logs-only server.

In the demo tenant the MCP snippets under Settings → API → MCP already embed the demo's shared read-only key - paste them into your client as-is to try the tools against the demo dataset.

Connecting a clientCopy Anchor Link

For Claude Code:

claude mcp add 1security --transport http https://api.1security.ai/api/v1/mcp \
  --header "Authorization: Bearer $ONESEC_API_KEY"

For clients configured with JSON (Claude Desktop via mcp-remote, agent frameworks, custom hosts):

{
  "mcpServers": {
    "1security": {
      "type": "http",
      "url": "https://api.1security.ai/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer 1sec_live_…"
      }
    }
  }
}

Then ask the assistant to call ping - it returns the tenant, key name, and scopes the key maps to, which rules out the usual setup mistakes before you rely on it.

ToolsCopy Anchor Link

Each tool mirrors one REST endpoint - same parameters, same fields, same pagination. The REST endpoint reference documents every parameter and response field in detail.

All tools are annotated read-only (readOnlyHint), so MCP hosts that gate write-capable tools behind approval can auto-approve them safely. Nothing the MCP server exposes can change anything in 1Security or in your Microsoft 365 tenant.

Pagination and filtersCopy Anchor Link

List tools return the same envelope as the REST API:

{
  "data": [ … ],
  "pagination": { "nextCursor": "eyJvIjo1MH0", "hasMore": true, "limit": 50 }
}

To fetch the next page, the assistant passes nextCursor back as the cursor argument. Filters that accept several values take a comma-separated string ("severity": "high,critical"), timestamps are ISO-8601 UTC - identical to the REST query parameters, so everything the API reference says about filtering applies verbatim.

Every list tool also tells the assistant what it can pass: each argument description ends with the values the server accepts (or what a free value looks like) and an example, and the tool description ends with worked examples such as {"severity":"high,critical","from":"<24 hours ago, ISO-8601>"}. They are the same examples and allowed values the API reference shows under each endpoint and the dashboard playground offers as presets - one catalog on the server feeds all three.

LimitsCopy Anchor Link

• Read-only. There are no write tools; remediation stays in the dashboard and in policies.
• Same rate limit as REST. Tool calls and REST requests draw from the same 600 requests/minute budget per key.
• Stateless. No subscriptions or push notifications - an assistant that wants fresh data calls the tool again.
• One tenant per connection. A regular key is bound to its tenant. An organization-wide key (MSSP) works here too: add an X-Tenant-Id header next to the Authorization header in the client configuration - one MCP server entry per tenant, each pointing at the same endpoint with a different tenant id (list_tenants shows the ids).

NextCopy Anchor Link