Skip to main content
Glama
Sign In
idm-mcp

idm-mcp

by Isotel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Idm Get Value

idm_get_value

Read a single parameter from an ISOTEL IDM gateway by specifying device and parameter path. Optionally force a fresh device query or return allowed values, type, and limits.

Instructions

Read a single parameter, e.g. device="device0", parameter="ec/E".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "device": "<device>",
      "parameter": "<parameter>"
    },
    "name": "idm_get_value"
  }
}

Input Schema

NameRequiredDescriptionDefault
freshNoforce a new query to the device instead of returning the gateway's last stored sample (costs a device round-trip).
deviceYesroot, full name or unambiguous substring.
optionsNoalso return the gateway's options for the parameter - `type` (enum/numeric), `allowedValues`, `readOnly`, min/max.
parameterYesparameter path. The `data/` container that `idm_list_parameters` may show is accepted and stripped.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 carries the full burden. 'Read' implies a non-mutating operation, but it says nothing about the stored-sample-vs-fresh-query behavior (left entirely to the schema), error handling when a parameter is missing, or required permissions.

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

Conciseness4/5

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

A single front-loaded sentence with no wasted words. It is efficient, though so terse that it edges toward under-specification rather than being genuinely complete.

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?

An output schema exists, so return values need not be explained. However, for a tool with 4 parameters and no annotations, the one-line description leaves the agent without selection guidance or behavioral context, which is a meaningful gap.

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 all four parameters are already documented, giving a baseline of 3. The description adds a useful worked example ('ec/E', 'device0') that illustrates path format, but does not explain fresh or options beyond what the schema says.

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?

States a specific verb and resource: 'Read a single parameter', with a concrete example showing device/parameter usage. It implicitly contrasts with the plural siblings (idm_get_parameters, idm_list_parameters) by saying 'single', but never names them explicitly.

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?

There is no guidance on when to use this versus idm_get_parameters, idm_list_parameters, or idm_get_history. The example hints at a single-value read, but the agent must infer the choice of tool from the name alone.

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

Deploy Server

Other Tools