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 277 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 once you've opted in.

Session Opt-In Gate

The 8-Step Mandatory Workflow (in TATER mode)

Available Tools (277)

The TATER MCP server exposes 277 tools to Claude across the categories below. The tables here highlight representative samples; the live, complete list is in api/src/functions/mcp.ts (HTTP MCP) and mirrored in tater-mcp/src/index.ts (stdio MCP).

The Three-Doc Rule (mandatory pattern)

Every diagnostic / troubleshooting / remediation session your AI assistant runs MUST produce three durable artifacts before completion:

1. Ops task via create_tasker_task or update_tasker_task - the lifecycle record (who reported, status, root cause, resolution)
2. ConfigDoc via upsert_config_doc - this org's specific configuration state at conclusion
3. TATERpedia wiki page via create_wiki_page or update_wiki_page - the generic playbook for the next session

All three cross-link. The same root cause never bites twice. Enforced via the MCP server's INSTRUCTIONS - agents that skip these get reminded by the next message.

Help-Desk Session Pattern

When triaging user-reported symptoms ("user can't…", "OneDrive is acting weird", "MFA prompt won't go away"), the agent follows a strict 4-step workflow:

1. Search Ops first via list_tasker_tasks with requester email + symptom keywords - load existing task and continue, don't duplicate
2. If no match, create_tasker_task immediately with the user's reported symptom verbatim
3. Append findings throughout the session - don't overwrite the original description
4. At resolution, populate root cause + bulk-link all touched entities (controls, ConfigDocs, wiki pages, change requests, risks, vendors, applications)

Questionnaire Auto-Fill Pattern

When asked to "fill out this vendor questionnaire" / "draft answers for the SIG" / "respond to this RFP security section", the agent follows this MCP-first workflow (TATER runs no internal LLM - your AI does all synthesis):

1. list_questionnaires (filter: in-progress, not-started) - find the one to work on
2. get_questionnaire - pull the question list and current drafts
3. For each question:
   • search_questionnaire_kb FIRST - prior answers to similar questions are highest-signal. Inspect verificationStatus + lastVerifiedAt on each hit.
   • If verification is missing or >90 days old, call verify_kb_entry BEFORE reusing.
   • Fall back to search_config_docs, search_wiki, get_control_info, list_policies, get_compliance_summary for fresh context.
   • draft_questionnaire_answer - writes the draft, always sets status to in-progress (humans approve complete). Cite ConfigDoc ids, wiki slugs, control IDs verbatim.
4. update_questionnaire_status when all drafted (submitted is rejected - requires explicit human sign-off via full upsert).

Ingestion sub-pattern: when a user uploads historical questionnaires (PDF / DOCX / XLSX), the agent reads the file using its own file-read capability and bulk-imports Q&A pairs via import_questionnaire_kb. TATER does no server-side file parsing.

KB answer verification

Prior answers go stale. The agent calls verify_kb_entry to cross-check each KB hit against current state: re-fetches the latest scan and verifies each mappedControl is still passing, checks whether cited ConfigDocs have been updated since the answer was written, flags entries over 1 year old with no verifiable evidence. Writes verificationStatus back to the entry so subsequent searches surface staleness at a glance.

Verification statuses: current (safe to reuse) · stale-evidence (mapped controls now failing - do NOT reuse as-is) · stale-doc (cited config docs updated since answer) · stale-age (>1 year old) · unverifiable (no evidence to check against).

Tool categories (with sample tool names)

For the canonical list, run grep -c "^\s*name: '" api/src/functions/mcp.ts against the live source.

Original tool tables follow for reference:

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