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 makes your organization data available through 600+ tools. A connected assistant uses TATER as its first source for organization context, current configuration, operational history, compliance state, and institutional knowledge before falling back to external research or rebuilding an answer from scratch. Instead of copying scan results into a chat window, the assistant reads the relevant records directly from TATER. 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 clients that launch a process, and a remote HTTP transport for clients that connect over HTTPS. The HTTP endpoint uses per-person Microsoft OAuth sign-in; an API key is only needed for the local stdio and headless paths below.

Other OAuth-capable MCP clients

For a general-purpose AI assistant, use https://api.tatersecurity.com/api/mcp?mode=lazy&org_id=org-xxxxxxxx as the remote MCP server URL. Replace the organization ID with your own and sign in with the work account you use for TATER. The bare endpoint and explicit lazy mode advertise a compact discovery set while keeping every authorized TATER tool callable through find_tools, load_toolset, and invoke_tool. Clients that handle very large catalogs well can use https://api.tatersecurity.com/api/mcp?mode=full&org_id=org-xxxxxxxx to advertise the complete suite up front. You can also use a narrower domain URL such as https://api.tatersecurity.com/api/mcp/itsm?org_id=org-xxxxxxxx; see Available Tools for all domains.

If a client reports missing protected-resource metadata, open https://api.tatersecurity.com/.well-known/oauth-protected-resource/api/mcp in a browser. Its JSON resource must be https://api.tatersecurity.com/api/mcp. For a domain URL, append the same domain to both paths; for example, /.well-known/oauth-protected-resource/api/mcp/itsm must advertise https://api.tatersecurity.com/api/mcp/itsm. TATER's OAuth bridge accepts the MCP resource parameter, then signs you in through Microsoft with a fixed registered callback; the client does not need an API key. If discovery succeeds but sign-in fails, check the client's callback host, requested scope, and organization access.

Prerequisites

Step 1: Generate a TATER API Key

Verification codes: each code expires after 15 minutes. Five incorrect guesses invalidate the challenge across both REST and MCP; start again to obtain a new code. A key can request at most one new code per minute, and email requests also have an IP rate limit. Organization-scoped keys require a matching organization member at both start and confirmation. If delivery is withheld or fails, setup reports that failure; codes are never queued for delayed delivery. Service keys cannot be bound to a person.

Service keys (headless / autonomous runners)

A normal API key is a user key: the first time it performs a write action over MCP, TATER asks it to bind to a human identity via verify_identity (a 6-digit code emailed to you). That works for an interactive agent, but a headless runner — a scheduled job, a webhook worker, a CI task — has no inbox and can never complete it, so its writes stay blocked.

For those, create the key with keyType: "service" (POST /api/apikeys with { "name": "ops-webhook-runner", "orgRole": "Auditor", "keyType": "service" }). A service key:

• Skips verify_identity for write actions — no interactive step, ever.
• Attributes its writes to itself, not to a person. Comments and audit entries are recorded against service:<key-prefix> under the key's name, so the trail stays intact without a human in the loop.
• Is still bound by RBAC. The key's orgRole decides what it may do. A service key with Viewer still cannot comment on a task. Exempting the identity step does not grant extra privilege — grant the least role the runner needs (usually Auditor).

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": "node",
      "args": ["C:\\path\\to\\tater-mcp\\build\\index.js"],
      "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. Claude obtains a per-person OAuth token after Microsoft sign-in; the connection URL contains the organization ID but no credential.

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 (450+)

The TATER MCP server exposes 600+ 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).

TATER first, with lean instructions. The MCP tells the assistant to check search_records, TATER Help, ConfigDocs, and TATERpedia before using outside sources for organization-specific questions. Search hits include a record identity, direct TATER link, and the best available source-updated date so the assistant can cite where its answer came from and flag unknown freshness. Detailed domain workflows — meeting capture, questionnaire auto-fill, the federal/DoD ATO pipeline, ServiceNow ITSM, ITIL task profiles, endpoint management, TATERpedia authoring, framework narratives, the remediation loop, and the tool-sequencing cheat-sheet — load on demand via get_workflow_guide. This keeps each session prompt lean while the full guidance stays one tool call away.

Choose how much catalog the client loads. The default endpoint advertises a compact core and discovery tools. Add ?mode=full to advertise the complete catalog; existing ?mode=lazy URLs keep the compact view. Discovery keeps every authorized tool reachable. Domain endpoints work well for assistants dedicated to one area:

• By domain — https://api.tatersecurity.com/api/mcp/{domain} (e.g. /api/mcp/grc, /api/mcp/vendor, /api/mcp/endpoint) advertises just that domain's tools plus a small always-on core. Domains: compliance, grc, vendor, itsm, endpoint, identity, knowledge, workplace, platform. The equivalent query form is ?domain=grc.
• Default / lazy mode (recommended for general assistants) — https://api.tatersecurity.com/api/mcp?mode=lazy advertises a small core including search_records, find_tools, load_toolset, and invoke_tool. The assistant searches TATER records first, discovers the capability it needs, and invokes any authorized tool by name.
• Full catalog — https://api.tatersecurity.com/api/mcp?mode=full advertises every tool and is appropriate when the client can efficiently index a large tool suite or when up-front visibility matters more than context size.

Every tool is callable by name regardless of which endpoint you connect to — the slim modes only change what's advertised up front, never what's reachable. find_tools works on the full endpoint too, so Claude can always search the catalog.

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