Teramind MCP Server

MCP server for Teramind's insider-threat/employee-monitoring API - computer inventory, agent (user) inventory, departments, alerts, anomaly-rule and behavior-policy configuration, and monitoring-profile metadata - for AI assistants and the WYRE Conduit gateway.

This connector is PII-dense by construction (insider-threat/employee-monitoring product) and requires security review before merge - see Scope and Credential scope below.

Authentication

Teramind authenticates with a JWT Access Token, self-generated per-account in the Teramind dashboard (User menu -> Access Tokens), sent as the x-access-token header. There is no OAuth flow.

Teramind's API is per-customer-instance (cloud or on-premise/private-cloud) - there is no shared multi-tenant base URL like most other connectors in this catalog. Every credential set also carries the customer's own instance URL (e.g. https://yourcompany.teramind.co). In gateway mode both arrive per-request via the X-Teramind-Access-Token / X-Teramind-Instance-Url headers; in local/stdio mode they're read once from TERAMIND_ACCESS_TOKEN / TERAMIND_INSTANCE_URL.

Configuration

Tools

Computers

• teramind_list_computers - list monitored computers (hostname, FQDN, MAC/IP, OS, monitoring status).
• teramind_get_computer - get full detail for a single computer.

Agents (users)

• teramind_list_agents - list monitored agents (Teramind's term for a monitored employee/user identity): id, name, email, avatar, online status.
• teramind_get_agent - get full detail for a single agent.

Departments

• teramind_list_departments - list departments (org-structure metadata).
• teramind_get_department - get full detail for a single department.

Alerts

• teramind_list_alerts - list fired rule-violation events in a time window, optionally filtered by agent/computer/department.

Anomaly rules

• teramind_list_anomaly_rules - list configured ML-based anomaly-detection rules (type, risk quotient, trigger conditions).
• teramind_get_anomaly_rule - get full detail for a single anomaly rule.
• teramind_list_anomaly_rule_tags - list the tags available to categorize anomaly rules.

Behavior policies

• teramind_list_behavior_policies - list behavior policies (what activity type each policy watches and its match conditions).
• teramind_get_behavior_policy - get full detail for a single behavior policy.
• teramind_list_behavior_policy_groups - list behavior policy groups (the containers that organize behavior policies).
• teramind_get_behavior_policy_group - get full detail for a single behavior policy group.

Monitoring

• teramind_list_monitoring_profiles - list monitoring profiles (which data types are configured to be captured, and for whom).

Account

• teramind_get_account - get the authenticated account's own settings (credential sanity check).

Scope

This is a deliberately narrow, read-only v1 surface, scoped MORE conservatively than this catalog's usual bar given the sensitivity of an insider-threat/employee-monitoring product. Teramind's documented API (fetched directly from its published Postman collection, apidoc.dev.teramind.co) has 239 operations across dozens of product areas (monitoring, BI reporting, time tracking, scheduling, productivity classification, LDAP, task management, scheduling). This connector implements 16: literal HTTP GET reads covering only computer/user/session inventory, department metadata, and rule/alert configuration. Every tool is classified isAdmin: true in the Conduit gateway regardless of verb, given the sensitivity of employee-monitoring data.

No literal GET endpoint exists for session inventory. Teramind's session data (Sessions report, Login session BI grid) is only reachable through POST query/grid-style endpoints, not a plain resource GET - documented here as a finding, not fabricated as a tool. Session data is out of this connector's v1 scope as a consequence, not a separate exclusion decision.

Hard-excluded: anything that returns actual monitored content, or mints/reveals a credential - by name, even where the verb is GET

Per this connector's scope boundary, the distinction is: metadata about monitoring (who is monitored, when, what rule fired) is in scope; the actual captured content of what was monitored, or a mechanism to obtain a live credential, is not, regardless of read/write verb.

No GET endpoint anywhere in Teramind's documented API returns raw keystroke logs, chat/IM content, printed-document content, or social-media activity content - those are exclusively reachable through the POST /tm-api/report/*/grid and POST /tm-api/wip/tma-query (BI) families, which this connector excludes as a category below. This connector's GET-only scope therefore rules out keystroke/screenshot/chat-content exposure by construction, not merely by the per-endpoint judgment calls above - see Credential scope for what this claim does and does not cover.

Excluded by category (out of the named scope: computer/user/session inventory + rule/alert data)