MCP Server

Connect AYAsec to AI agents through MCP tools for security scans, report retrieval, target management, and posture checks.

AYAsec speaks MCP (Model Context Protocol) - point an MCP client at your account and query targets, scans, findings and alerts, or trigger a scan, from inside Claude Code, Claude Desktop, Cursor, or any other MCP-compatible tool. It uses the same bearer token as the rest of this API - there's no separate OAuth flow to set up.

Endpoint

The server is a single Streamable HTTP endpoint, reachable at your AYAsec origin:

Requests are stateless - every call is authenticated independently by its Authorization header, the same way every other v1 API request is. There's no separate MCP-specific credential; generate or reuse a token from Settings → API Access (see Authentication ) and pass it straight through.

Connecting a client

Every client below needs the same two things: the endpoint ( ) and a bearer token from Settings → API Access .

Codex CLI doesn't take a header flag - point it at the URL, then add the bearer token as an environment variable in its own config, as shown in its tab above. Claude Desktop and Cursor both accept the same HTTP-plus-header shape as Claude Code, configured through whichever settings screen that client currently uses for remote MCP servers.

Scopes decide what a client can do

There's no separate permission model for MCP - every tool call re-checks the same scopes your token already has, and a tool your token isn't scoped for returns a clean error rather than failing silently or crashing the connection. That means the token you hand to an AI client is the entire safety boundary:

• Give it targets:read , scans:read , findings:read , alerts:read , and stats:read for a client that should only look things up.
• Add scans:run if you want it able to queue a scan, or alerts:write if you want it able to acknowledge or resolve alerts on your behalf.

There's currently no per-call confirmation step before a write tool executes - client-side confirmation support for that is still inconsistent across MCP clients. If you don't want an assistant able to change anything, don't put write scopes on the token you give it.

Tools

Every tool wraps the exact same logic as its REST equivalent in the Endpoints reference - an MCP client and a direct API call never see different data or behave differently for the same request.

Workspace scoping

A token bound to specific workspaces only ever sees those workspaces' data through MCP too - the same binding you set up under Settings → API Access applies here without any extra configuration. An unbound, org-wide token can ask an assistant something like "which targets need attention across every client workspace" in one query - useful if you manage more than one workspace and want a single point to ask from.