nexterm-mcp

Overview Schema Source Related Servers Discussions Admin

nexterm_update_entry

Update selected fields on an existing Nexterm entry without overwriting unmodified configuration fields. Specify the entry ID and only the values to change.

Instructions

Update typed fields on an entry while preserving unmodified Nexterm config fields.

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": {
      "entry_id": "<entry_id>"
    },
    "name": "nexterm_update_entry"
  }
}

Input Schema

Name	Required	Description	Default
`ip`	No
`icon`	No
`name`	No
`port`	No
`vmid`	No
`entry_id`	Yes
`protocol`	No
`renderer`	No
`folder_id`	No
`node_name`	No
`entry_type`	No
`mac_address`	No
`identity_ids`	No
`rdp_security`	No
`jump_host_ids`	No
`keyboard_layout`	No
`organization_id`	No
`monitoring_enabled`	No
`wake_on_lan_enabled`	No
`wol_broadcast_address`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 29, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, open-world, so the safety profile is carried structurally. The description adds the genuinely useful partial-update behavior, but leaves the critical ambiguity unexplained: with 20 nullable/default-null parameters, does null mean 'leave unchanged' or 'clear the field'? It also says nothing about failure modes or auth.

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

Conciseness3/5

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

A single sentence with no filler and the key behavior front-loaded, but for a 20-parameter mutation tool this is under-specification rather than concision. No structure (no enumeration, no caveats) to help an agent scanning the definition.

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?

A complex mutation with 20 parameters at 0% schema description coverage, no output schema, and no return-value documentation. Given the annotations only cover the safety profile, an agent still cannot call this correctly without guessing how nulls are treated and whether entry_type is mutable on the server.

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

Parameters2/5

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

Schema description coverage is 0% across 20 parameters, so the description must compensate and does not: 'typed fields' names no field, and semantics for entry_type, vmid (int-or-string), identity_ids, or the nullable defaults are never touched. The one sentence does imply that omitted fields are preserved, which is the most valuable semantic available, but it is not precise enough to resolve the null-vs-omitted question.

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 (update fields on an entry) and adds a meaningful modifier: unmodified Nexterm config fields are preserved, implying partial-update semantics. It does not name or differentiate from siblings like nexterm_create_entry or nexterm_get_entry, but the operation itself is unambiguous.

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 statement of when to use this versus nexterm_create_entry, nexterm_get_entry, or nexterm_duplicate_entry, and no prerequisites (e.g., must the entry be fetched first, is there a permission requirement). The only usage signal is the implied PATCH-like behavior, which the agent must infer.

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

Deploy Server