Claude MCP Integration

Connect Claude Desktop or claude.ai directly to your TATER compliance data using the Model Context Protocol (MCP). Query scan results, explore failing controls, create risk acceptances, log change requests, write framework narratives, and assign work — all through a natural conversation.

What Is the MCP Integration?

The TATER MCP server exposes your compliance data as 61 tools that Claude can call in real time. Instead of copying scan results into a chat window, Claude reads them directly from your TATER API. You can ask questions like:

• "Which controls are failing for Exchange Online right now?"
• "Create a risk acceptance for the SMTP AUTH control with a 90-day expiry."
• "Show me all Critical findings from last week's scan."
• "Assign the DMARC control to Sarah and set a due date of May 1st."
• "Summarize our CIS Section 1 posture and write the framework narrative."
• "Log that I just disabled legacy auth — impact is High."
• "What's our compliance score across all frameworks?"

The MCP server supports two connection modes: a local stdio transport for Claude Desktop, and an HTTP transport for claude.ai or remote connections.

Prerequisites

Step 1: Generate a TATER API Key

Setup: Claude Desktop

Claude Desktop supports two ways to add MCP servers: a built-in UI and manual config file editing. Both work — use whichever you prefer.

Option A: Connectors UI (recommended)

Option B: Config file (advanced)

For local stdio mode (runs a Node.js process on your machine, no inbound ports required), edit the config file directly:

{
  "mcpServers": {
    "tater": {
      "command": "npx",
      "args": ["-y", "@tater-security/mcp-server"],
      "env": {
        "TATER_API_BASE": "https://api.tatersecurity.com",
        "TATER_API_KEY": "your-api-key-here",
        "TATER_ORG_ID": "org-xxxxxxxx"
      }
    }
  }
}

Setup: claude.ai (Remote HTTP)

The HTTP transport lets claude.ai connect to the TATER MCP server over HTTPS without installing anything locally. Authentication credentials are embedded directly in the connection URL.

How Claude Works: Default Behavior

When you connect to the TATER MCP server, Claude receives mandatory working instructions automatically at session start. These instructions define a consistent, audit-quality workflow — you do not need to prompt Claude to follow it.

The 8-Step Mandatory Workflow

Available Tools (55)

The TATER MCP server exposes the following tools to Claude:

Reading Data

Context & Collaboration

Writing & Acting

Example Conversations

Reviewing failing controls

You: What are the top failing controls from my most recent scan?

Claude: I'll check your latest scan results now.
[calls list_scans, then get_failing_controls with status=Fail]

⚠ Risk Summary: Your most recent scan from April 3rd shows 24 failing controls.
The top 5 by severity are:

1. EXO — DMARC Policy Enforced (High) — No DMARC record found for your domain
2. DEF — Safe Links Policy (High) — URL rewriting is disabled
3. ENT — Idle Session Timeout (Medium) — No timeout configured
4. SPO — External Sharing Restricted (Medium) — Sharing set to Anyone
5. EXO — External Forwarding Blocked (Medium) — Auto-forward rules permitted

The two High severity findings represent active phishing risk — DMARC absence
means attackers can spoof your domain, and disabled Safe Links means malicious
URLs are not inspected in email.

Would you like me to work through these? I'll load context on each control
before taking any action.

Working a specific control end-to-end

You: Let's handle the DMARC control.

Claude: [calls get_control_context for EXO_DMARC_Control]

Context loaded. I can see:
- No prior team notes or threads for this control
- No existing risk acceptance
- No change history

This is a first-time review. Here's the risk:
DMARC absence means anyone can send email that appears to be from your domain.
This enables phishing, brand spoofing, and BEC (Business Email Compromise) attacks.
The risk of not fixing this is High — I'd recommend remediation over acceptance.

How would you like to proceed?

You: We have a marketing tool that blocks DMARC enforcement. Accept the risk,
90-day expiry, and note the compensating control is SPF + DKIM alignment.

Claude: [calls create_risk_acceptance with audit-quality justification]
[calls create_change_request with impact=Medium]
[calls add_thread_post to notify the team]

Done:
- Risk acceptance created (expires July 5, 2026)
- Change logged in change control (auto-approved, Medium impact)
- Thread post added so the team can see the decision rationale

Creating a risk acceptance

You: Create a risk acceptance for the SMTP AUTH control. Legacy application
dependency. Expiry in 90 days.

Claude: [calls get_control_context — checks for existing overrides and team notes]

No prior risk acceptance found. Here is the security risk:
SMTP AUTH allows clients to authenticate with username/password instead of
modern OAuth flows, bypassing MFA. This is a known credential-stuffing vector.

Risk acceptance details:
- Control: EXO — SMTP AUTH
- Justification: Legacy application dependency requiring basic auth; MFA bypass
  mitigated by conditional access IP restriction to application server range
- Expiry: 90 days from today (July 5, 2026)
- Impact: Medium

Shall I proceed?

You: Yes

Claude: [calls create_risk_acceptance]
[calls create_change_request]
[calls add_thread_post]

Done. Risk acceptance, change log, and team thread all created.

Writing framework narratives

You: Review our CIS Section 1 (identity/authentication) posture and write
the framework narrative for it.

Claude: [calls get_framework_narratives for CIS_M365_v3 section 1]
[calls get_compliance_summary filtered to Entra ID]
[calls get_failing_controls filtered to ENT controls]

I found an existing narrative for section 1.1 from March. Here's what's
documented and what's changed since then...

[Reviews failing controls, existing risk acceptances, and team notes]

Ready to write narratives for sections 1.1–1.8. Here's a draft for 1.1:

"The organization enforces MFA for all users via Conditional Access policy
CA-001 (All Users – Require MFA). Legacy authentication protocols are blocked
at the tenant level (ENT_001 — Pass). One risk acceptance is active for SMTP
AUTH due to a legacy application dependency, expiring July 5, 2026, with
compensating controls in place (IP restriction via CA-014)."

[calls set_framework_narrative for CIS_M365_v3 section 1.1]

Section 1.1 narrative saved. Continue with 1.2 through 1.8?

Using configuration documentation

You: I just disabled SMTP AUTH on the tenant and restricted legacy auth
via Conditional Access. Document this for the team.

Claude: [calls search_config_docs for "SMTP AUTH" and "legacy auth"]

Found 1 existing doc: "Exchange Online Authentication Baseline" from 6 months
ago — notes that SMTP AUTH was enabled for a legacy application.

That application is no longer referenced in recent change requests or comments.
Here's the updated configuration state I'll document:

- SMTP AUTH: Disabled tenant-wide (EXO_028 now passing)
- Legacy auth: Blocked via CA-009 (Entra ID Conditional Access)
- Previous exception: Retired — legacy app dependency resolved

[calls upsert_config_doc, updating the existing Exchange Online auth doc]
[calls create_change_request with impact=High — queued for OrgAdmin approval]
[calls add_thread_post on EXO_028 for team visibility]

Done. The config doc is updated with the current state and links to the
change request. OrgAdmin approval needed for the change log (High impact).

Assigning controls to team members

You: Assign the top 5 failing Entra ID controls to Sarah and set a
due date of two weeks from today.

Claude: [calls get_failing_controls filtered to ENT prefix]
[calls list_people]

Found Sarah Chen in your team contacts — notes indicate she handles
Entra ID and identity policies.

Assigning 5 controls to Sarah with due date April 22, 2026:
[calls assign_control × 5]
[calls add_thread_post on each control so the team sees the assignment]

Done. Assignments visible in Assignments and on Sarah's "My Assignments" view.

Permissions and Safety

The MCP integration follows TATER's role-based access control:

Claude's built-in safety rules apply at all times. The MCP server does not expose destructive operations (delete, bulk overwrite). All actions taken via MCP are recorded in the TATER audit log with source: mcp for traceability.

Troubleshooting

Next Steps

1. Review the Settings Reference to learn about API key scopes and permissions
2. Explore the Dashboard Guide to understand the data Claude is reading
3. Set up Azure Runbooks so Claude always has fresh scan data to work with
4. Learn about Running Scans to keep your compliance data current
5. Open the Standards page in TATER to review framework narratives Claude has written
6. Check Change Control in the GRC section for any High/Critical changes awaiting OrgAdmin approval