The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Teramind listing page.
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.
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.
| Env var | Description |
|---|---|
TERAMIND_ACCESS_TOKEN | JWT access token issued by the Teramind dashboard's Access Tokens menu. |
TERAMIND_INSTANCE_URL | The customer's Teramind instance base URL, e.g. https://yourcompany.teramind.co. |
MCP_TRANSPORT | stdio (default) or http. |
AUTH_MODE | env (default, reads the vars above) or gateway (credentials arrive per-request via X-Teramind-Access-Token / X-Teramind-Instance-Url, injected by the Conduit gateway). |
CONDUIT_S2S_SECRET | When set, the HTTP transport requires a valid X-Gateway-S2S header (Conduit sidecar auth) on every /mcp request. |
LOG_LEVEL | debug | info (default) | warn | error. |
teramind_list_computers - list monitored computers (hostname, FQDN, MAC/IP, OS, monitoring status).teramind_get_computer - get full detail for a single computer.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.teramind_list_departments - list departments (org-structure metadata).teramind_get_department - get full detail for a single department.teramind_list_alerts - list fired rule-violation events in a time window, optionally filtered by agent/computer/department.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.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.teramind_list_monitoring_profiles - list monitoring profiles (which data types are configured to be captured, and for whom).teramind_get_account - get the authenticated account's own settings (credential sanity check).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.
GETPer 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.
| Endpoint | Rationale |
|---|---|
GET /tm-api/agent/:id/avatar/:scale | Returns the agent's avatar/headshot image - biometric-adjacent photo content. |
GET /tm-api/activity/email/:id/info | Email-activity metadata (participants/subject) - content-adjacent; excluded alongside its two siblings below rather than judged separately. |
GET /tm-api/activity/email/:id/body-html-document | Returns the full captured email body as rendered HTML. Raw captured content. |
GET /tm-api/activity/email/:id/body | Returns the full captured email body. Raw captured content. |
GET /tm-api/player/settings | Session-recording player/playback settings for a specific agent+computer. |
GET /tm-api/player-tags | Annotations/bookmarks tied to recorded-session timelines. |
GET /tm-api/player-tags/timeline | Timeline tags for a specific agent/computer's recorded sessions over a period. |
GET /tm-api/player/export-video/status/:id | Status of a screen-recording video export job. |
GET /tm-api/player/available-video-data | Enumerates which recorded video segments exist for a computer/period - an inventory of available screen recordings. |
GET /tm-api/report/export/download/:id | Generic report-export download - the export could be of ANY report type this API supports, including keystrokes, emails, instant messages, or video, so it is excluded as a class rather than judged per export. |
GET /tm-api/report/export/status | Status of a report-export job - same generic content-bearing concern as the download endpoint above. |
GET /tm-api/short-token | Mints a new short-lived, live access token. Credential issuance, not content - held to the same bar as a credential-return endpoint in every other connector in this catalog. |
GET /tm-api/token | Lists the account's active JWT token IDs - credential/session-management data. |
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.
| Category | Why excluded |
|---|---|
| Activities (aggregated activity) | Activity/productivity data, not inventory or rule/alert metadata. |
| BI / BI Filter (37 ops) | All POST query/chart endpoints; several return captured content (keystrokes, emails, IM, social media, printed documents, web search, console commands). |
| Reports / Report settings / Reports batch (~55 ops) | All POST grid/settings endpoints; several return captured content (keystrokes, emails, IM, printing, social media, console commands, video export). |
| Video export (remaining 2 ops) | POST write actions that generate exports of screen-recording content. |
| Time Tracking Reports, Time tracker tasks, Tasks, Schedule | Employee clock-in/task/shift-scheduling features, unrelated to monitoring inventory or rule/alert data. |
| LDAP | Directory-service connection config - out of scope, and a plausible vector for exposing bind-account details even as a plain read. |
| SMTP, Ingestion | Single POST write actions (send test email, create VoIP events); no read surface. |
| Shared lists | Rule-input datasets (e.g. keyword/URL watchlists referenced by rules) of ambiguous sensitivity - excluded as a judgment call rather than included by default. |
Productivity Profile, instance/tma-categories | Productivity-classification taxonomy - arguably rule-adjacent, but not named in this connector's scope; excluded to stay tight rather than included as a stretch. |
instance/tma-state, time, license/usage | Generic utility/status endpoints, none of which fit computer/user/session inventory or rule/alert data. |
Every POST/PUT/DELETE/PATCH on Agent, Computer, Department, Behavior Policy, Anomaly Rule, Authorization, Monitoring Profile | Write, provisioning, enable/disable-monitoring, or account-mutation operations. Never implemented, regardless of verb. |
| Anomaly-rule / behavior-policy templates, tags-and-misc bundle, demo policy | Catalogs for AUTHORING new rules, not this org's actual configured monitoring - out of scope for a read-only inventory connector (teramind_list_anomaly_rule_tags is the one exception kept, as a simple, low-risk taxonomy lookup directly useful for interpreting teramind_list_anomaly_rules output). |
They can be added as a follow-up if there's demand, after a deliberate scope decision - not by default.
GET /tm-api/v1/agents[/:id] supports an optional fields query parameter that can return salary_type and default_wage (compensation data) and ldap_attrs (raw directory attributes) - HR/PII data well beyond "who is monitored." This connector's client.ts never passes that parameter, so only the default identity fields (agent_id, name, email_address, avatar, online) are ever returned, regardless of what a caller requests through the tool's input schema (there is no fields parameter exposed on teramind_list_agents / teramind_get_agent at all).
teramind_list_alerts is squarely in this connector's named scope ("rule/alert data"), and its response shape is documented by Teramind to include description/caption/values fields describing why a rule fired. Depending on the rule type, those fields may carry a short excerpt of the triggering context (e.g. a matched keyword, or a visited URL) rather than pure metadata - this is passed through as Teramind returns it, unmodified. This was judged in-scope because alerts are explicitly named in this connector's scope and the excerpt (if present) is bounded to what a human already configured a rule to flag, not raw unfiltered activity capture - but it is flagged here explicitly, per this task's instruction, rather than decided unilaterally as a closed question.
This is the single most important finding in this README. Two claims, deliberately kept at different confidence levels:
(1) STRUCTURALLY VERIFIED - this connector's own code never calls a content-capture, credential-issuance, or write endpoint. Confirmed against client.ts: exactly 16 functions exist, one per tool, each a literal GET against one of the endpoints listed in the Tools section above; there is no wildcard/passthrough/generic-request function anywhere in src/. This connector is read-only and non-content-capturing by construction.
(2) VENDOR-DOCUMENTED, NOT INDEPENDENTLY VERIFIED - whether the underlying access token itself can be restricted to a metadata-only scope is a separate question from what this connector's code calls, and the answer is more nuanced than a clean yes/no:
Net finding: by default, nothing about the Teramind access token credential itself prevents it from reaching every endpoint this connector deliberately excludes. The connector's own code is the actual control boundary (per point 1 above), not the credential. Recommendation for whoever operates Gate 3 review or advises customers connecting this vendor: consider documenting that customers should create the token under a dedicated Operational Administrator account rather than a full Administrator, as defense-in-depth against a differently-configured client reusing the same stored token - while treating this connector's own code (which never calls a content-capture endpoint) as the primary, verified control.