MCP is the agent-provider-neutral way to connect an AI client to SecurityTrackr. You give the client one server URL, it discovers the authorization flow, and a person approves the access it needs. No provider-specific plugin or long-lived API token has to be copied into a prompt. This guide covers the client capabilities, consent and lifecycle needed for a working connection.
Connect a compatible MCP client
Add this remote MCP endpoint to the client that hosts your agent:
https://app.securitytrackr.com/api/mcpYour client needs Streamable HTTP and the OAuth discovery flow described below, including Client ID Metadata Documents and PKCE. MCP access is available on Pay-per-use and Pro.
The client handles discovery and sign-in
A conformant MCP client can start with only the endpoint URL. When it makes its first unauthenticated request, SecurityTrackr answers with an OAuth resource-metadata challenge. The client follows that metadata to the authorization server and starts an authorization-code flow with PKCE.
- Discovery. The client follows the protected-resource metadata link and learns where authorization lives.
- Client identity. The client presents its Client ID Metadata Document. SecurityTrackr does not expose a Dynamic Client Registration endpoint.
- Authorization. The client uses authorization code plus PKCE with S256, then presents the resulting OAuth access token on each MCP request.
The important part is that the agent provider does not receive a SecurityTrackr password or an API secret. The client handles the redirect, and the person signs in through SecurityTrackr's normal account flow.
Consent is the permission boundary
The consent screen lists the scopes the client requested. Treat that list as a proposal, not a formality. You can remove scopes before approving, and the grant can never contain more than you accepted. The effective authority on every request is the intersection of your SecurityTrackr role and the scopes in the grant.
- Least privilege. A read-only client needs observations.read. Add write or progress scopes only when the workflow genuinely needs them.
- Role changes take effect. A grant never outlives your current role. The server recomputes effective permissions on every request.
- High-impact governance stays explicit. Risk acceptance and deletion scopes are default-off and require an acknowledgement at consent. Audit-log access is never grantable.
What the connected agent can do
The client discovers the current tool definitions from the server. Tools cover searching and reading findings, reviewed creation, mitigation progress, risk assessment, comments, relations and evidence handoff. Risk acceptance and deletion require the additional permissions approved at consent.
The available tool list is broader than any one grant. Seeing a tool does not mean the client is authorised to use it; the server checks the user's role and granted scopes on every call.
Duplicate review is mandatory
Creating an observation starts with an explicit review workflow. First, prepare_observation_ingest searches for existing findings that might cover the same concern. The client must dispose of every candidate before finalize_observation_ingest can create the observation. There is no direct create tool that skips that review.
An agent can suggest a disposition, but the server owns the final gate. That keeps duplicate detection and tenant scoping consistent across MCP and REST.
Wait for the completed result
Finalising an ingest, reassessing risk or progressing a recommendation can return a job. Use get_ai_jobwith the same connection to follow it to completion, then read the resulting observation or ingest attempt. A queued job is not a completed write. cancel_ai_job can cancel eligible active work.
Expiry, attribution, and revocation
OAuth access is deliberately temporary. A grant expires 60 days after approval, and reconnecting starts a new approval. Every connected client is visible under Account → Connected agents, where you can inspect its origin, granted scopes, and status.
Disconnect a client when it no longer needs access or whenever you suspect its environment is compromised. Revocation takes effect on the client's next request. MCP actions are recorded in the audit trail under the authorizing user, with the application recorded alongside them.
What to configure
- Use https://app.securitytrackr.com/api/mcp as the remote MCP server URL.
- Let the client follow the OAuth challenge and complete authorization code plus PKCE.
- Review the requested scopes and remove anything the workflow does not need.
- Keep the client connected to the same SecurityTrackr account that should own its actions.
- Check Account → Connected agents after the first connection and disconnect stale clients.
- Expect a 60-day grant lifetime and plan for a fresh consent flow when access expires.