Altr MCP Server

ALTR MCP Server

ALTR provides tag-based data masking, access governance, and classification for Snowflake, Databricks, and OLTP databases. This MCP server enables AI assistants (Claude, Cursor, and other MCP clients) to manage data security on the ALTR platform, covering database connections, tag masking, policies, classification, access management, audits, telemetry, and sidecar configuration.

New to ALTR? See the ALTR documentation for an overview of the platform, concepts, and supported data sources.

All tools return structured {success, data, error} responses and can run over stdio, SSE, or streamable-http transports.

Table of Contents

• Quick Start
• Getting Credentials
• Configuration
• Restricting Tools
• Running over HTTP
• Setup
• Claude Desktop
• Claude Code (CLI)
• Cursor
• VS Code (GitHub Copilot)
• Windsurf
• Running from Local Source
• CLI
• Tools
• Data Source Support
• Troubleshooting
• Development
• License

Quick Start

1. Install from PyPI:

   pip install altr-mcp

Or run directly with uvx (no install required):

   uvx altr-mcp

uvx is part of the uv Python package manager. Install it with pip install uv or see the uv installation guide.

1. Set the three required environment variables (see Getting Credentials for where to find each in the ALTR console):

   export ORG_ID=your-org-id

export MAPI_KEY=your-api-key export MAPI_SECRET=your-api-secret

1. Wire it into your AI client — see Setup for Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf. The same three env vars go into the client's env block.

1. Verify by asking your AI assistant to run a read-only tool:

• "List my ALTR databases" → calls get_databases
• "Show me the tags connected to ALTR" → calls get_tags
• "List the ALTR roles in my org" → calls get_roles

If these return data, your setup is working.

Getting Credentials

You need three values from the ALTR platform to configure this server. See Manage API keys for the full reference.

Configuration

Set the following environment variables before starting the server:

MAX_RETRIES counts total attempts, not retries on top of the first, so 1 disables retrying without disabling the retry path. Backoff is exponential with jitter; a Retry-After response header overrides it, clamped to MAX_RETRY_AFTER so a server cannot park a call indefinitely.

What gets logged

Every tool call is logged to stderr at INFO with its arguments, which is what makes a session traceable. An argument is redacted when its value is a credential or user-supplied free text — values, text, comment, comments, attestation, justification, statement_text_contains, filters, filter_tree, content, content_base64, connection_string, connection_properties, the bare credential names (password, secret, credentials, passphrase, private_key, api_key, auth_token, access_key), and anything ending _password, _secret, _credential, _credentials, _private_key or _passphrase. Identifiers, enums and pagination cursors are logged in full.

An argument can also reach a log by travelling in a request URL, which redaction keyed on argument names cannot see. httpx's per-request line is therefore held at WARNING, so it does not appear at the default INFO.

Dictionary keys survive, so a line reads values={'ssn': ' ', 'email': ' '}: you keep which fields were sent and lose the data. Tokens are not redacted — a token exists to be handled freely, and ALTR's own Shield audit log is keyed by token.

Redaction covers the invocation line, tracebacks, and the argument-coercion error returned to the caller.

LOG_FORMAT applies to dependency output as well as this server's own — under json, every line on the stream is a JSON object, and dependency lines carry the correlation_id of the tool call they occurred inside. See Logging.

Upgrading from 0.6.0 or earlier? Arguments were not redacted before

0.7.0. Treat any credential passed as a tool argument as exposed in your

logs and rotate it — in practice database_password and

connection_string. Those logs may also hold plaintext passed to the

tokenize tools, so review who can read them and how long they are kept. Log

output also changed shape; see the 0.7.0 entry in the

CHANGELOG.

Endpoint overrides

Every ALTR service endpoint can be pointed elsewhere, which is useful against a non-production ALTR environment. All are optional — leave them unset in normal use.

The eight per-service endpoints are derived from your ORG_ID as https:// . .live.altr.com, five of them with a path appended (a version, or /v1/dam-alerting). An override replaces the whole value, so it must include that path where the default has one — see the table.

Restricting Tools

Use RESTRICTED_TOOLS to hide specific tools from MCP clients. Restricted tools are removed from the tool list and blocked if called directly.

Names must match the registered tool name exactly. An entry that matches nothing restricts nothing, and is logged as a warning the first time a client lists tools. Note that 11 tools were renamed from delete_* to disconnect_* in 0.4.0.

For example, to give a team read-only access without any destructive operations:

RESTRICTED_TOOLS=disconnect_database,delete_policy,delete_rule,disconnect_tag,disconnect_tag_by_details,delete_classifier,delete_collection,disconnect_sc_repo,disconnect_sc_sidecar

Or in the Claude Desktop config:

{

"mcpServers": { "altr": { "command": "uvx", "args": ["altr-mcp"], "env": { "ORG_ID": "your-org-id", "MAPI_KEY": "your-api-key", "MAPI_SECRET": "your-api-secret", "RESTRICTED_TOOLS": "disconnect_database,delete_policy,delete_rule,disconnect_tag" } } } }

This is an operator-level safety net — it prevents accidental or unwanted tool usage but is not a substitute for proper API key permissions.

Running over HTTP

With the default stdio transport, your AI client starts the server as its own subprocess, so nothing else can reach it. With MCP_TRANSPORT=sse or streamable-http, the server listens on a port, and every tool call runs with your organization's API key. So:

• The default address is loopback. MCP_HOST defaults to 127.0.0.1, so only clients on the same machine can connect, and no token is needed. Without a token, the server also rejects any request whose Host or Origin header is not a loopback name (localhost, 127.0.0.1 or [::1]), so a web page open in a local browser cannot use it. Pages served from this machine are trusted, whatever their port, so local tools such as the MCP Inspector keep working.
• Any other address needs a token. To accept connections from other machines, set MCP_HOST (for example 0.0.0.0) and MCP_AUTH_TOKEN. The server refuses to start with a non-loopback MCP_HOST and no token. Clients send the token as Authorization: Bearer , and a request without it gets 401. The token may contain only letters, digits and -._~+/, with = only at the end. A reverse proxy on the same machine should also use a token, since it sends its own Host header.
• Use TLS. The server speaks plain HTTP, and a bearer token sent in the clear can be read on the network. Put it behind a reverse proxy or gateway that terminates TLS.
• Or let a gateway authenticate. If a gateway in front of the server checks every request itself, for example with your identity provider, set MCP_ALLOW_UNAUTHENTICATED=true instead of a token. This also turns off the Host and Origin check on a loopback address, so a gateway on the same machine that passes those headers through keeps working. The server logs a warning at startup, since it then accepts any request that reaches it.

Generate a token with:

python3 -c "import secrets; print(secrets.token_urlsafe(32))"

For exam