i3X-MCP-Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 3.9/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![i3X-MCP-Server MCP server](https://glama.ai/mcp/servers/cesmii/i3X-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/cesmii/i3X-MCP-Server)

Score Badge

Copy to your README.md:

[![i3X-MCP-Server MCP server](https://glama.ai/mcp/servers/cesmii/i3X-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/cesmii/i3X-MCP-Server)

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