Drata MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DRATA_API_KEY | Yes | Your Drata API key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_controlsB | List ALL compliance controls with optional search. Args: search: Search term for control name/description only_issues: If True, only show controls with problems (not ready, no owner, no evidence) Returns: List of controls with their status and details |
| get_control_detailsA | Get detailed information about a specific control. Args: control_code: The control code (e.g., "DCF-71", "DCF-12") Returns: Full control details including linked monitors |
| list_controls_with_issuesA | Get controls that are NOT OK / have problems / need attention. Use this tool when user asks for:
Returns controls with status: NOT_READY, NO_OWNER, or NEEDS_EVIDENCE. Returns: Controls with compliance issues and their status |
| get_monitors_for_controlB | Get all monitors (tests) that affect a specific control. Args: control_code: The control code (e.g., "DCF-71") Returns: List of monitors linked to this control |
| list_monitorsC | List ALL automated monitoring tests. Args: status: Filter - PASSED, FAILED, NOT_TESTED Returns: List of monitoring tests with status summary |
| list_failing_monitorsA | Get all FAILED automated monitoring tests - critical for SOC2. Returns: List of failing tests that need remediation |
| get_monitor_detailsB | Get detailed information about a specific monitor/test. Args: monitor_id: The monitor ID Returns: Full monitor details including failure reasons and remediation |
| list_personnelB | List ALL personnel with compliance status. Args: employment_status: Filter - CURRENT_EMPLOYEE, CURRENT_CONTRACTOR, FORMER_EMPLOYEE, FORMER_CONTRACTOR Returns: Personnel list with compliance status |
| list_personnel_with_issuesB | Get personnel with compliance issues (failing devices). Returns: Personnel with failing device compliance |
| get_personnel_detailsB | Get detailed personnel compliance information. Args: personnel_id: Personnel ID Returns: Full personnel details with compliance checklist |
| list_policiesB | List all company policies. Args: limit: Max results Returns: List of policies with version info |
| list_pending_policy_acknowledgmentsC | Get policies pending user acknowledgment. Args: limit: Max results Returns: List of unacknowledged policy assignments |
| list_connectionsC | List all integrations/connections and their status. Args: limit: Max results Returns: List of connections with sync status |
| list_vendorsC | List all vendors. Args: limit: Max results Returns: List of vendors |
| list_devicesC | List all registered devices. Args: limit: Max results Returns: List of devices with compliance status |
| list_evidenceA | List ALL evidence in the evidence library. Returns evidence documents uploaded to Drata for compliance. Returns: List of evidence with details and versions |
| list_expiring_evidenceB | List evidence that hasn't been updated recently and may need renewal. Args: days: Consider evidence stale if not updated in this many days (default 30) Returns: Evidence that may need to be renewed |
| list_eventsA | List compliance events from the audit log. Note: Due to API limitations, events are returned in chronological order (oldest first). Args: limit: Number of events to return (default 50) category: Filter by category - PERSONNEL, CONTROL, MONITOR, CONNECTION, POLICY, VENDOR Returns: Events with details |
| list_assetsB | List all assets in the asset inventory. Args: asset_type: Filter by type - PHYSICAL, VIRTUAL, CLOUD, DATA, PERSONNEL Returns: List of assets with details |
| list_usersB | List all Drata users in your organization. Returns: List of users with their roles |
| get_compliance_summaryB | Get overall compliance dashboard summary. Returns: Aggregated view of compliance status across all areas |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| daily_compliance_check | Start your day with a compliance status check. |
| prepare_for_audit | Prepare a comprehensive audit readiness report. |
| investigate_monitor | Deep dive into a specific monitor/test failure. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| compliance_summary_resource | Current compliance status summary. |
TDQS
Scored across 21 tools
Tools are mostly distinct by resource, but list_controls_with_issues and list_failing_monitors duplicate functionality already available via filters on list_controls and list_monitors, creating overlap. Descriptions attempt to guide usage, but an agent may still struggle to choose the right tool for issue-focused queries.
Almost all tools follow a snake_case verb_noun pattern (list_* for collections, get_* for details). Minor deviation: get_monitors_for_control uses get_ for a list operation, and some list_* names include qualifiers, but the convention is predictable.
21 tools is at the upper end of reasonable for a compliance platform covering many resource types. However, the count is inflated by redundant issue-specific aliases, making the set feel heavier than necessary.
The server covers major compliance entities and includes detail endpoints for controls, monitors, and personnel. Yet many resources (policies, vendors, devices, evidence, assets, users) are list-only, and no mutation tools exist, leaving notable gaps for deeper investigation or remediation workflows.