How do I use i3X-MCP-Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@i3X-MCP-Server What's the current state of pump-101?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

i3X-MCP-Server

by cesmii

Overview Schema Related Servers Score Discussions

TypeScript

Remote

i3x-mcp

A bridge that lets Claude (and any other MCP client) talk to your manufacturing data through the i3X standard — so you can ask plain-English questions about your plant and get real answers.

"What equipment is on the production line?" "What's the current state of pump-101?" "Show me the temperature trend for tank-201 over the last hour." "What feeds into the assembly line?"

Install (5 minutes, no coding required)

1. Install Node.js (if you don't already have it)

Open a terminal and run:

node --version

If you see a version number ≥ 18 (e.g. v20.0.0), you're set. If not, download and install from nodejs.org — pick the "LTS" version.

2. Open Claude Desktop's config file

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

If the file doesn't exist, create it.

3. Add the `i3x` server

If the file is empty, paste this whole thing:

{
  "mcpServers": {
    "i3x": {
      "command": "npx",
      "args": ["-y", "i3x-mcp@latest"]
    }
  }
}

If the file already has stuff in it, add only the "i3x": { ... } block inside mcpServers (and add the mcpServers block if missing). Mind the commas between JSON keys — that's the #1 reason Claude Desktop reports an invalid config.

4. Restart Claude Desktop

Fully quit (⌘Q on Mac, right-click tray → Quit on Windows) and reopen. The first time you use it, npx downloads i3x-mcp from npm — takes 10-20 seconds.

5. Tell Claude which i3X server to talk to

Start a new chat and say:

"Use the i3x connect tool with baseUrl https://api.i3x.dev/v1"

(That's the public CESMII demo server. For your own deployment, substitute your URL.)

Claude will verify the connection and confirm. From there you can ask normal questions:

"What equipment is at the top of the hierarchy?" "Find anything with 'pump' in the name." "What's the current value of pump-101 and its components?" "Get the last hour of history for pump-101-state, averaged every 5 minutes."

Related MCP server: Industrial MCP Agent Platform

Connecting to a private / authenticated server

If your i3X server requires authentication:

"Connect i3x to https://i3x.mycompany.com/v1 with authScheme bearer and token eyJhbGc..."

Supported auth schemes:

none (default)
bearer — uses Authorization: Bearer <token>
apikey — uses a custom header (default X-API-Key, override with the apiKeyHeader argument)

Connections live for the duration of a Claude Desktop session. To switch servers mid-session, just call connect again.

Persisting connection info via environment variables

If you'd rather not type the connect command each time, pre-set the connection in your Claude Desktop config:

{
  "mcpServers": {
    "i3x": {
      "command": "npx",
      "args": ["-y", "i3x-mcp@latest"],
      "env": {
        "I3X_BASE_URL": "https://i3x.mycompany.com/v1",
        "I3X_AUTH_SCHEME": "bearer",
        "I3X_TOKEN": "eyJhbGc..."
      }
    }
  }
}

What Claude can do

Tool	What it does
`connect`	Point the server at an i3X instance. Validates against `/info`.
`connection_status`	Show current baseUrl, auth, and catalog state.
`server_info`	Capabilities of the connected i3X server (query/update/subscribe).
`search_objects`	Find equipment by name (fuzzy/substring). The main "where is X" tool.
`list_root_objects`	Top of the equipment hierarchy.
`refresh_catalog`	Re-fetch the object list after new equipment is added.
`get_object`	Detailed info on one or more objects (type, parent, relationships).
`read_current_value`	Latest value + quality + timestamp, with engineering units when known.
`get_history`	Time-range history with optional `avg`/`min`/`max`/`count` aggregation and `bucket` (e.g. `5m`). Accepts relative times like `"last 1h"`.
`find_related`	Graph traversal. Returns related objects grouped by relationship.
`describe_type`	ObjectType schema + per-field units (helps Claude interpret raw values).
`watch_values`	Bounded live-data window. Internally manages an i3X subscription.

Writes (update_value, write_history) are off by default. See "Enabling writes" below.

Time inputs

Anywhere a time is accepted (get_history), you can use:

RFC 3339: 2026-06-12T10:00:00Z
Relative: 1h, 30m, 7d, last 30m
Keywords: now, today, yesterday

For startTime, a bare duration means "that long ago." For endTime, the default is now.

Enabling writes (advanced)

Setpoint writes can affect live equipment. Writes are off by default. To enable them, modify your Claude Desktop config to pass --enable-writes:

"args": ["-y", "i3x-mcp@latest", "--enable-writes"]

This exposes update_value and write_history. Both are marked as destructive — Claude will request explicit confirmation before invoking them.

Tuning (environment variables)

Env var	Default	Purpose
`I3X_BASE_URL`	unset	Optional pre-set baseUrl. If unset, use the `connect` tool from chat.
`I3X_AUTH_SCHEME`	`none`	`none`, `bearer`, or `apikey`.
`I3X_TOKEN`	—	Required when `I3X_AUTH_SCHEME` is `bearer` or `apikey`.
`I3X_APIKEY_HEADER`	`X-API-Key`	Header name used when `I3X_AUTH_SCHEME=apikey`.
`I3X_WATCH_MAX_SEC`	`300`	Hard cap on `watch_values` duration.
`I3X_RAW_HISTORY_MAX_POINTS`	`500`	Cap on raw VQT points returned per element by `get_history`.

Troubleshooting

Claude Desktop says "MCP i3x: Server disconnected"

Check the claude_desktop_config.json is valid JSON (commas, braces).
Confirm Node.js 18+ is installed and node is on your PATH.
Open the developer logs in Claude Desktop's "Settings → Developer" panel for details.

Tools return "Not connected to an i3X server"

Call the connect tool: "Connect i3x to https://..."
Or set I3X_BASE_URL in the config's env block and restart Desktop.

Connection fails on connect

The error message will say what failed (e.g. DNS, 401 Unauthorized). Re-check the baseUrl and auth.
The baseUrl must include the version path, e.g. https://api.i3x.dev/v1.

For developers

Run from source

git clone <this-repo> i3x-mcp
cd i3x-mcp
npm install
npm run build

Point Claude Desktop at the local build:

{
  "mcpServers": {
    "i3x": {
      "command": "node",
      "args": ["/absolute/path/to/i3x-mcp/dist/index.js"]
    }
  }
}

Project layout

src/
  config.ts          # env + CLI parsing
  connection.ts      # connection lifecycle (connect / disconnect / state)
  i3x-client.ts      # HTTP client + i3X types
  catalog.ts         # cached object/type index + fuzzy search (fuse.js)
  time.ts            # relative time parsing
  aggregation.ts     # raw/avg/min/max/count bucketing
  units.ts           # unit extraction + value enrichment
  tools.ts           # all MCP tool registrations
  index.ts           # entry point

Smoke test

node smoke-test.mjs

Spawns the server, walks through connect → search_objects → get_history against the public demo.

Publishing to npm

You'll need an npm account with publish rights to i3x-mcp. Then:

# Patch release (0.1.0 → 0.1.1):
npm run release:patch

# Minor release (0.1.0 → 0.2.0):
npm run release:minor

# Major release (0.1.0 → 1.0.0):
npm run release:major

Each script:

Bumps version in package.json.
Creates a git commit and tag.
Runs prepublishOnly (which builds via tsc).
Publishes to the public npm registry.

Push the tag after with git push --follow-tags.

License

MIT — see LICENSE.

Available Tools

12 tools

connectConnect to an i3X serverA

Point the MCP server at an i3X instance. Required before any data tool will work (unless I3X_BASE_URL was set in the env). Validates by calling /info on the target. Switching connections at any time is fine — call this again.

ParametersJSON Schema

Name	Required	Description
`token`	No	Required when authScheme is "bearer" or "apikey".
`baseUrl`	Yes	Versioned base URL, e.g. https://api.i3x.dev/v1
`authScheme`	No	Default "none".
`apiKeyHeader`	No	Header name for apikey auth (default "X-API-Key").

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, so description is the sole source. It mentions validation via /info and reconnection behavior, but lacks details on failure states, authentication side effects, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no filler, front-loaded with the core purpose and essential usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers prerequisites, validation, and reconnection, but could clarify behavior when environment variable is set and interaction between optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already well-documented. Description adds only a brief example (e.g., URL format) but does not provide new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool connects to an i3X instance, uses the verb 'point', and distinguishes it from sibling data tools by noting it is a prerequisite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says it is required before data tools work and that switching connections is fine, but does not discuss when not to use or provide alternative connection methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

connection_statusShow current i3X connectionA

Returns whether an i3X connection is active, the baseUrl, auth scheme, and catalog snapshot.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, so description must fully disclose behavior. It describes the output (active, baseUrl, auth scheme, catalog snapshot) but does not explicitly note it's a read-only operation. However, for a status query, this is largely transparent and expects no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that directly states what the tool returns. No filler, front-loaded with key information. Perfectly concise for a status-check tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides a reasonable summary of return fields (active, baseUrl, auth scheme, catalog snapshot). It does not detail data types or pagination, but for a simple status tool it is sufficiently complete. Sibling tools like 'server_info' suggest additional nuance, but this description stands alone well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters (0 params, schema coverage 100%). With no parameters, the baseline is 4. The description does not need to add parameter info, and it doesn't, making it adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns connection status including active flag, baseUrl, auth scheme, and catalog snapshot. It uses a specific verb 'returns' and uniquely identifies the resource (i3X connection), distinguishing it from siblings like 'connect' which establishes a connection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool or when to avoid it. While it's implied as a status check, there is no mention of alternatives or context like 'use before other operations'. Given the simplicity, a score of 3 is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

describe_typeDescribe ObjectTypeA

Returns the JSON Schema and per-field units for an ObjectType.

ParametersJSON Schema

Name	Required	Description	Default
`typeElementId`	Yes	ObjectType elementId.

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states what is returned (JSON Schema and units) but gives no information about side effects, permissions, or read-only nature. For a read-only metadata tool, basic details are present but insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the key action and result. No extraneous words, making it highly efficient for an AI agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (1 param, no output schema, no annotations), the description covers the essential information. Minor gaps exist (e.g., what 'per-field units' means, or any restrictions), but it is largely complete for a straightforward reflection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter typeElementId is described in the schema as 'ObjectType elementId'. The tool description adds context by linking this parameter to the ObjectType being described, reinforcing its purpose. Since schema coverage is 100%, the description adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns the JSON Schema and per-field units for an ObjectType. The verb 'Returns' and specific resource 'ObjectType' make the purpose unambiguous, distinguishing it from sibling tools like get_object or search_objects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you need schema and units for a type) but provides no explicit guidance on when not to use it or alternatives among siblings. This is adequate for a simple tool with a single parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_relatedFind related objectsC

Objects related to the given ones via the i3X relationship graph. If relationshipType omitted, groups by type.

ParametersJSON Schema

Name	Required	Description
`elementIds`	Yes	Start element IDs.
`includeMetadata`	No	Include descriptions (default false).
`relationshipType`	No	Optional: a RelationshipType elementId or displayName.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It only reveals that omitting relationshipType causes grouping by type. There is no information about destructive actions, authentication requirements, rate limits, output format, or side effects. The description is insufficient for an agent to anticipate tool behavior beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at two sentences, with no redundant words. The key behavioral aspect (grouping if type omitted) is front-loaded. Every word carries weight, making it an efficiently written description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a graph traversal tool with three parameters and no output schema, the description is notably incomplete. It fails to explain the return format, pagination, error conditions, or performance implications. An agent would lack crucial context for correct invocation and response handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema: it clarifies that omitting relationshipType triggers grouping by type, but does not elaborate on elementIds format or includeMetadata details. Overall, it does not significantly enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds objects related to given ones via the i3X relationship graph, specifying the grouping behavior when relationshipType is omitted. While it identifies the operation and resource, it does not explicitly differentiate itself from sibling tools like search_objects or get_history, but the graph-specific language implies uniqueness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or comparison with sibling tools. The sole usage hint is the grouping behavior, which is more of a functional detail than usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_historyGet historical valuesA

Historical values over a time range with optional server-side aggregation. Times accept RFC 3339, relative durations ('1h', 'last 30m'), 'now', 'today', or 'yesterday'. For long ranges use aggregation='avg'|'min'|'max'|'count' with a bucket like '5m' or '1h'.

ParametersJSON Schema

Name	Required	Description
`bucket`	No	Bucket interval, e.g. '30s', '5m', '1h'.
`endTime`	No	End of range. Default 'now'.
`maxDepth`	No	Composition depth (default 1).
`startTime`	Yes	Start of range. RFC 3339 or relative duration.
`elementIds`	Yes	Element IDs.
`aggregation`	No	How to aggregate (default 'raw').

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It discloses time format flexibility and aggregation behavior but does not declare that the operation is read-only, nor mention any destructive effects, rate limits, or authorization needs. Lacks explicit safety traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey purpose and key parameter guidance. Front-loaded with the core task, then additional details about time formats and aggregation. No extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 6 parameters (2 required) and no output schema. Description covers time handling and aggregation, which are the main complexities. However, it does not describe the return format (e.g., array of values with timestamps) or pagination. Still, it is sufficient for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining accepted time formats (RFC 3339, relative durations, 'now', etc.) and providing usage context for aggregation and bucket parameters beyond schema descriptions. This helps an agent correctly format requests.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Historical values over a time range with optional server-side aggregation', specifying both the verb (get) and resource (historical values). This distinguishes it from sibling tools like read_current_value (present value) and get_object (object metadata).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implicitly suggests when to use aggregation ('For long ranges use aggregation...'), but does not explicitly contrast with sibling tools like read_current_value or get_object for simpler queries. No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_objectGet object detailsA

Detailed info for one or more objects: type, parent, composition flag, declared relationships.

ParametersJSON Schema

Name	Required	Description	Default
`elementIds`	Yes	Element IDs to look up.
`includeMetadata`	No	Include descriptions and full relationship graph (default true).

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes returned fields but does not explicitly state it is a read-only operation or mention error handling, performance, or effects on the system. With no annotations, more disclosure is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key purpose and attributes. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool, description adequately explains return content (type, parent, composition flag, declared relationships). Lacks mention of handling multiple objects or potential limitations like pagination, but still reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters have descriptions). Description adds no additional semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves detailed info for objects including type, parent, composition flag, and relationships. It distinguishes from siblings like 'find_related' and 'list_root_objects' by specifying exact attributes returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives such as 'find_related', 'get_history', or 'read_current_value'. No context for prerequisites or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_root_objectsList root objectsA

Returns top-level objects in the i3X hierarchy (no parent). Good entry point for unfamiliar plants.

ParametersJSON Schema

Name	Required	Description	Default
`includeMetadata`	No	Include descriptions and relationships (default false).

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the scope (top-level, no parent) but lacks details on auth, rate limits, or pagination. Adequate for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the core purpose and use case. No redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional param and no output schema, the description covers essential behavior. Could mention return format but not critical given context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'includeMetadata' fully described in schema (100% coverage). Tool description adds no extra meaning beyond schema, meeting baseline but not compensating further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns top-level objects with no parent, and positions it as an entry point for exploration. Distinguishes from sibling tools like search_objects or get_object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Indicates use case as a good entry point for unfamiliar plants, implying initial exploration. Lacks explicit when-not-to-use or alternatives, but context is clear given sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_current_valueRead current valueA

Latest value (with quality and timestamp) for one or more objects. Set maxDepth>1 to include composed sub-components. Values are enriched with engineering units when the ObjectType schema declares them.

ParametersJSON Schema

Name	Required	Description	Default
`maxDepth`	No	Composition depth. 1=this object only (default), 0=infinite, N=N levels.
`elementIds`	Yes	Element IDs to read.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that values include quality and timestamp, and are enriched with engineering units when available. It explains maxDepth behavior clearly. Could mention idempotency or error handling, but overall sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. First sentence states the core purpose, second adds crucial usage detail about depth and units. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read operation with two parameters and no output schema, the description covers the return fields (value, quality, timestamp) and parameter behavior. It is complete for this complexity level, though an example would be extra.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds meaning: 'latest value' implies freshness, and 'maxDepth>1' clarifies composition beyond the schema's generic description. This provides context not available from schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads the latest value with quality and timestamp for one or more objects, using the verb 'read' and specifying the resource. It distinguishes from siblings like 'get_history' (historical) and 'get_object' (metadata) by mentioning current values and composition depth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It guides on using maxDepth>1 to include sub-components, implying this tool is for current snapshots. However, it never explicitly says when not to use it or names alternatives, though the sibling context suggests differences from 'get_history' and 'watch_values'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refresh_catalogRefresh catalogB

Rebuilds the local object/type catalog from the i3X server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. While it states 'Rebuilds', it does not disclose any side effects, whether the operation is destructive, how long it takes, or what the result is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and conveys the essential action without any unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no parameters and no output schema, the description lacks context about return values, side effects, or when this operation is necessary. More detail would be beneficial for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline is 4 for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Rebuilds') and specifies the resource ('local object/type catalog from the i3X server'), differentiating it from sibling tools like connection_status or describe_type. It is not a tautology of the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool or when not to. It does not mention prerequisites, alternatives, or typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_objectsSearch objectsA

Fuzzy/substring search over the cached object catalog. Use this to find equipment, sensors, or processes by name. Returns elementId, displayName, type, and parent path.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 25).
`query`	Yes	Search text.
`typeFilter`	No	Optional: restrict to a specific ObjectType displayName or elementId.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It states the search is over a 'cached' catalog, implying non-destructive behavior and potential staleness, but does not disclose permissions, rate limits, or side effects. The information is adequate for understanding it is a read-only search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each serving a distinct purpose: defining the search type, suggesting usage, and listing return fields. No extraneous words or redundancy. Perfectly concise for its content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description adequately covers return values and the search scope. It mentions caching and name-based search. However, it does not clarify whether the search applies to all fields or only displayName, or discuss pagination beyond the limit parameter. Still sufficiently complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides (query, limit, typeFilter). The only extra information pertains to return fields, not parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs fuzzy/substring search over a cached object catalog, specifies that it finds equipment, sensors, or processes by name, and lists the returned fields (elementId, displayName, type, parent path). This distinguishes it from siblings like get_object (exact lookup) or list_root_objects (top-level listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Use this to find equipment, sensors, or processes by name,' which implies when to use it, but it does not explicitly state when not to use it or suggest alternatives (e.g., use get_object for exact ID lookup). The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

server_infoi3X server infoA

Returns the i3X server's capabilities, version, and supported features (query/update/subscribe).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It clearly indicates the tool is read-only ('Returns') and lists the output contents. While it does not mention side effects or auth, the existing information is sufficient for a simple info tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every word adds value, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema), the description is complete. It explains precisely what is returned (capabilities, version, supported features), which is sufficient for an agent to understand and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage (empty schema). According to guidelines, baseline for 0 params is 4. The description adds no extra parameter meaning, which is acceptable as there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the i3X server's capabilities, version, and supported features (query/update/subscribe). It uses a specific verb 'returns' and resource, and it is distinct from sibling tools like connect or get_object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With 11 sibling tools, the lack of usage context (e.g., 'use this to check server version before connecting') is a significant gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

watch_valuesWatch values for a bounded windowA

Monitor one or more objects for live changes over a bounded duration (max 300s). Creates an i3X subscription internally and cleans it up on exit. Returns per-element summary of all observed changes (count, first, last, min, max).

ParametersJSON Schema

Name	Required	Description
`elementIds`	Yes	Element IDs to monitor.
`durationSeconds`	Yes	How long to watch. Capped at 300s.
`pollIntervalSeconds`	No	Poll interval (default 2s).

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers important behaviors: creates and cleans up internal subscription, bounded duration (300s), and return format. However, it does not mention whether the tool blocks, error handling, or polling behavior (though pollIntervalSeconds is in schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each serving a distinct purpose: purpose, internal mechanism/cleanup, and return value. No unnecessary words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return format (per-element summary). However, it does not specify whether the tool is synchronous or asynchronous, if it blocks until duration completes, or what happens on errors or object deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents parameters. The description contextualizes parameters (e.g., 'bounded duration' for durationSeconds) but adds little beyond the schema, especially for pollIntervalSeconds which is not mentioned in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Monitor' with resource 'objects' and clearly states the bounded duration, internal subscription creation, cleanup, and return summary. It distinguishes from siblings like 'read_current_value' and 'get_history' by focusing on live changes over time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly state when to use it versus alternatives like 'read_current_value' or 'get_history'. There is no guidance on when-not-to-use or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv0.1.0Jun 25, 2026
- First observedconnect
- First observedconnection_status
- First observeddescribe_type
- First observedfind_related
- First observedget_history
- First observedget_object
- First observedlist_root_objects
- First observedread_current_value
- First observedrefresh_catalog
- First observedsearch_objects
- First observedserver_info
- First observedwatch_values

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose: connection management, schema browsing, object retrieval, search, history, and live monitoring. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., connect, describe_type, search_objects) with no mixing of conventions or vague verbs.

Tool Count5/5

12 tools cover the core operations of an i3X server—connection, browsing, searching, historical, and live data—without being excessive or too sparse.

Completeness4/5

The set covers all major data access patterns (current, historical, live, search, hierarchy) but lacks write/update/delete tools, which may be acceptable given the server's likely read-only focus.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
ContextfloOAuth
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1
Chat ThingOAuth
ai.chatthing
Build and manage AI-native customer support agents from Claude or any MCP client.
Customer Support Autonomous Agents AI & Machine Learning
2

Related MCP Servers

OpenText Process Automation
App Automation ERP Systems
amitagl27
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that lets Claude and any other MCP-compatible client work with an OpenText AppWorks Platform tenant in plain English.
Updated 2 months ago (2026-07-21 17:37 UTC)
MIT
Industrial MCP Agent Platformofficial
Agent Orchestration RAG Systems Knowledge & Memory
hoonapps
A
license
Not graded
quality
C
maintenance
MCP server for integrating manufacturing systems (MES/ERP/quality/maintenance) with LLM agents, enabling event ingestion, incident triage, approval workflows, and RAG-based knowledge retrieval.
Updated 3 months ago (2026-06-20 09:56 UTC)
MIT
HOOPS AI MCP Server
AI & Machine Learning Autonomous Agents
toshi-bata
A
license
Not graded
quality
B
maintenance
Bridges Claude Desktop to the HOOPS AI WebAPI, enabling 3D CAD analysis and interactive model operations through natural language.
Updated 2 months ago (2026-07-19 06:29 UTC)
MIT
industrial-mcp
Monitoring Autonomous Agents
brayangcastro
A
license
A
quality
C
maintenance
An MCP server that gives Claude (or any MCP-compatible AI host) read access to industrial sensor data and safety-gated control over motors and actuators.
Updated 2 months ago (2026-07-16 01:03 UTC)
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cesmii/i3X-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

i3x-mcp

Install (5 minutes, no coding required)

1. Install Node.js (if you don't already have it)

2. Open Claude Desktop's config file

3. Add the i3x server

4. Restart Claude Desktop

5. Tell Claude which i3X server to talk to

Connecting to a private / authenticated server

Persisting connection info via environment variables

What Claude can do

Time inputs

Enabling writes (advanced)

Tuning (environment variables)

Troubleshooting

For developers

Run from source

Project layout

Smoke test

Publishing to npm

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Industrial MCP Agent Platformofficial

Latest Blog Posts

MCP directory API

3. Add the `i3x` server