Connhex MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONNHEX_PASSWORD | No | Password for credentials authentication. Required when CONNHEX_AUTH_TYPE is 'credentials'. | |
| CONNHEX_USERNAME | No | Username for credentials authentication. Required when CONNHEX_AUTH_TYPE is 'credentials'. | |
| CONNHEX_AUTH_TYPE | No | Authentication type. Options: 'credentials' (username/password), 'token' (bearer token), or 'session' (forwarded from client). | credentials |
| CONNHEX_BEARER_TOKEN | No | Static bearer token for token authentication. Required when CONNHEX_AUTH_TYPE is 'token'. | |
| CONNHEX_INSTANCE_URL | Yes | The base URL of the Connhex instance you want to connect to. |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoamiA | Returns information about the currently authenticated user. Use this to verify the connection and see user's identity (active Ory Kratos session). |
| read_channel_messagesA | Read messages from a Connhex IoT channel by its channel ID. Use this when you already have a channel ID. To go from a device's
business identifier (serial, etc.) to messages, prefer
|
| read_thing_messagesA | Read messages for a Connhex thing (device/edge), identified by its
thing ID. Resolves the thing's Resolving a user-facing identifier: If you only have a serial number or another business identifier, first use list_resources / list_manufacturing_resources to find the record, then look for a field named connhexId (or similar) — that value is the thing_id to pass here, not the record's own id. |
| get_modelA | Get a single device model by ID. |
| list_modelsA | List device models with optional filtering and pagination. |
| get_model_thingsB | List all things assigned to a specific device model. |
| get_schemaA | Schema of every resource type exposed by this Connhex JSON:API service for the current deployment. Shape:
Internal/system fields present on every type:
Read this resource before constructing filters, includes, or create/update payloads — it is the source of truth for valid types and field names. |
| list_resourcesA | List resources of a given type from a JSON:API service. Supports filtering, sorting, relationship includes, and pagination. Argument details are provided in the parameter schema. If available, call the |
| get_resourceA | Get a specific resource by its ID from a JSON:API service. Use If available, call the |
| create_resourceA | Create a new resource on a Connhex JSON:API service. Use schema fields for attributes and relationships. If available, call the |
| update_resourceA | Update an existing resource's attributes (partial update). Use schema fields for attributes. Only provided attributes are changed. If available, call the |
| delete_resourceA | Delete a resource. This action is irreversible. If available, call the |
| list_manufacturing_resourcesA | List resources of a given type from a JSON:API service. Supports filtering, sorting, relationship includes, and pagination. Argument details are provided in the parameter schema. If available, call the |
| get_manufacturing_resourceA | Get a specific resource by its ID from a JSON:API service. Use If available, call the |
| create_manufacturing_resourceA | Create a new resource on a Connhex JSON:API service. Use schema fields for attributes and relationships. If available, call the |
| update_manufacturing_resourceA | Update an existing resource's attributes (partial update). Use schema fields for attributes. Only provided attributes are changed. If available, call the |
| delete_manufacturing_resourceA | Delete a resource. This action is irreversible. If available, call the |
| list_rulesB | List rules from the Connhex Rules Engine. |
| get_ruleA | Get a single rule by ID from the Connhex Rules Engine. |
| create_ruleC | Create a new rule in the Connhex Rules Engine. |
| update_ruleB | Partially update a rule. Only the fields provided are changed. |
| delete_ruleA | Delete a rule. This action is irreversible. |
| list_rule_eventsB | List rule events (triggered rule occurrences). |
| get_thingA | Get a single thing by ID. |
| list_thingsC | List things with optional filtering and pagination. |
| get_things_statusA | Get current connectivity status for a batch of things by their IDs. Things that have never connected are omitted from the response. |
| get_things_status_summaryA | Get a fleet-wide connectivity summary: online, offline, never connected, active last hour. |
| get_things_flappingA | List devices with an excessive number of reconnections (flapping) within a time window. |
| get_thing_uptimeA | Get the connect/disconnect timeline and total uptime for a single thing within a time range. |
| get_thing_channelsB | List the channels connected to a specific thing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Connhex Resources schema | Schema of every resource type exposed by this Connhex JSON:API service for the current deployment. Shape: - Top-level keys are resource type names. Use them as the `resource_type` argument to the corresponding *_resource tools. - Each value is a dict of fields: - Entries with a `type` key are attributes (e.g. `String`, `Date`, `Object`). `isArray: true` indicates a list-valued attribute. - Entries with a `link` key are relationships. The `link` value is the related resource type — pass it (or a comma-separated list) as the `include` argument to fetch related records inline. `isArray: true` means a to-many relationship; `inverse` is the field name on the other side. Internal/system fields present on every type: - `tenants`, `createdAt`, `updatedAt` are managed by the platform. Do NOT include them in create/update payloads and do not surface them as user-facing data unless explicitly asked. Read this resource before constructing filters, includes, or create/update payloads — it is the source of truth for valid types and field names. |
| Connhex Manufacturing schema | Schema of every resource type exposed by this Connhex JSON:API service for the current deployment. Shape: - Top-level keys are resource type names. Use them as the `resource_type` argument to the corresponding *_resource tools. - Each value is a dict of fields: - Entries with a `type` key are attributes (e.g. `String`, `Date`, `Object`). `isArray: true` indicates a list-valued attribute. - Entries with a `link` key are relationships. The `link` value is the related resource type — pass it (or a comma-separated list) as the `include` argument to fetch related records inline. `isArray: true` means a to-many relationship; `inverse` is the field name on the other side. Internal/system fields present on every type: - `tenants`, `createdAt`, `updatedAt` are managed by the platform. Do NOT include them in create/update payloads and do not surface them as user-facing data unless explicitly asked. Read this resource before constructing filters, includes, or create/update payloads — it is the source of truth for valid types and field names. |
TDQS
Scored across 30 tools
There is significant overlap between generic resource tools (create_resource, delete_resource, etc.) and manufacturing resource tools (create_manufacturing_resource, etc.), with identical descriptions. This creates ambiguity about when to use each set. Other tools like read_channel_messages and read_thing_messages are more distinct.
Nearly all tools follow a consistent verb_noun pattern (e.g., create_resource, list_things, get_rule). The only slight outlier is whoami, but it is a common convention. Naming is highly predictable and uniform across domains.
With 30 tools, the server covers multiple domains (generic resources, manufacturing, rules, things, models, messages, user info). However, the explicit duplication of CRUD tools for generic and manufacturing resources inflates the count unnecessarily. The scope is broad but the count is borderline high.
The tool surface has notable gaps: things can only be read/fetched (no create, update, or delete), models lack CRUD beyond get/list, and channels only support reading messages. Full CRUD is only present for resources (generic and manufacturing) and rules. The absence of basic lifecycle operations for core entities (things, models) will likely cause agent failures.