Teramind MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | Authentication mode: env (default, reads TERAMIND_ACCESS_TOKEN and TERAMIND_INSTANCE_URL) or gateway (credentials arrive per-request via X-Teramind-Access-Token and X-Teramind-Instance-Url headers). | env |
| LOG_LEVEL | No | Logging level: debug, info (default), warn, or error. | info |
| MCP_TRANSPORT | No | Transport mode: stdio (default) or http. | stdio |
| CONDUIT_S2S_SECRET | No | When set, the HTTP transport requires a valid X-Gateway-S2S header on every /mcp request. | |
| TERAMIND_ACCESS_TOKEN | No | JWT access token issued by the Teramind dashboard's Access Tokens menu. | |
| TERAMIND_INSTANCE_URL | No | The customer's Teramind instance base URL, e.g. https://yourcompany.teramind.co. |
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 | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| teramind_list_computersA | List computers under Teramind monitoring - hostname, FQDN, MAC/IP addresses, OS, monitoring status (is_monitored), and agent-software install/update state. Computer IDs from this response are required by teramind_get_computer. Inventory metadata only - never screen recordings or captured activity content. |
| teramind_get_computerA | Get full detail for a single monitored computer. Requires a computer ID from teramind_list_computers. |
| teramind_list_agentsA | List Teramind agents (Teramind's term for a monitored employee/user identity - not the software agent installed on a computer): id, name, email, avatar, online status. Agent IDs from this response are required by teramind_get_agent and are usable as filters on teramind_list_alerts. This connector never requests the underlying API's optional extended fields (salary_type, default_wage, ldap_attrs) - only these basic identity fields are ever returned. |
| teramind_get_agentA | Get full detail for a single monitored agent (user). Requires an agent ID from teramind_list_agents. Same field restriction as teramind_list_agents - no compensation or LDAP attribute data. |
| teramind_list_departmentsA | List departments configured in Teramind - org-structure metadata used to group agents/computers. Department IDs from this response are usable as filters on teramind_list_alerts. |
| teramind_get_departmentA | Get full detail for a single department. Requires a department ID from teramind_list_departments. |
| teramind_list_alertsA | List alerts (fired rule-violation events) in a time window - which rule fired, when, for which agent/computer, and the rule's own description/caption fields. periodStart and periodEnd are required (ISO 8601 datetime, e.g. 2026-01-01T00:00:00Z); optionally scope to specific agents/computers/departments (comma-separated IDs). NOTE: depending on the rule type that fired, a rule's description/caption/values fields MAY include a short excerpt of the triggering context (e.g. a matched keyword or URL) rather than pure metadata - this is Teramind's documented alert response shape, passed through as received. |
| teramind_list_anomaly_rulesA | List configured ML-based anomaly-detection rules (Teramind UI: "Anomaly Rules") - rule name, type/subtype, risk quotient, trigger conditions, and assignment scope. Rule CONFIGURATION metadata only - describes what is being watched for, never the captured activity that triggered a rule. Rule IDs from this response are required by teramind_get_anomaly_rule. |
| teramind_get_anomaly_ruleA | Get full detail for a single anomaly rule. Requires a rule ID from teramind_list_anomaly_rules. |
| teramind_list_anomaly_rule_tagsA | List the tags available to categorize anomaly rules. |
| teramind_list_behavior_policiesA | List behavior policies (Teramind UI: "behavior policy rule") - what activity type each policy watches (e.g. web/email/print), its match conditions, and configured actions/reactions. Rule CONFIGURATION metadata only - the condition a policy matches on, never the captured activity that matched it. Policy IDs from this response are required by teramind_get_behavior_policy. |
| teramind_get_behavior_policyA | Get full detail for a single behavior policy. Requires a policy ID from teramind_list_behavior_policies. |
| teramind_list_behavior_policy_groupsA | List behavior policy groups (Teramind UI: "Behavior policy") - the containers that organize behavior policies. Group IDs from this response are required by teramind_get_behavior_policy_group. |
| teramind_get_behavior_policy_groupA | Get full detail for a single behavior policy group. Requires a group ID from teramind_list_behavior_policy_groups. |
| teramind_list_monitoring_profilesA | List monitoring profiles - named configurations describing WHICH data types are captured (e.g. web activity, email, keystrokes) and for which agents, plus whether the profile is private. This is metadata ABOUT the scope of monitoring (what is configured to be watched, and for whom) - never the captured content itself. |
| teramind_get_accountA | Get the authenticated account's own settings (account name, timezone, currency) - a credential sanity check, not employee/agent data. Does not reveal what permission tier the access token's creating account holds; see this connector's README Credential scope section. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Each tool targets a distinct resource or operation: computers, agents, departments, alerts, rules, policies, groups, profiles, and account settings are clearly separated. The list/get pairs are unambiguous, and descriptions clarify potentially overlapping concepts like anomaly rules versus behavior policies.
All tools follow a consistent teramind_list_<plural> / teramind_get_<singular> pattern with snake_case throughout. Minor exceptions like teramind_get_account and teramind_list_alerts still fit the broader list/get convention and do not create confusion.
With 16 tools, the server is slightly above the typical 3-15 range, but each tool maps to a meaningful entity or lookup operation in the Teramind domain. The count is reasonable for the breadth of resources covered and does not feel bloated.
The read-only metadata surface covers the major Teramind entities: computers, agents, departments, alerts, anomaly rules, behavior policies, policy groups, and monitoring profiles. Minor gaps exist, such as no single-alert getter or monitoring-profile detail endpoint, but agents can accomplish core monitoring and configuration-discovery workflows without dead ends.