Proximo

Overview Schema Source Related Servers Discussions Admin

proximo_plan

Read-only

Preview the governed verdict and schema for one Proxmox address before acting: returns tier, consent, and required parameters you lack. Read-only; resolves word paths and shows mutation targets.

Instructions

READ-ONLY, mutates nothing: the governed verdict (armed, tier, consent) for one address, with the parameters you gave and the required ones you lack; fields='name1,name2' or 'all' shows the vendor's full schema. A mutation's plan also reads the target: current, change, noop. Run before proximo_call. path may be words: one match is planned, several come back to pick from.

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": {
      "plane": "<plane>",
      "method": "<method>",
      "path": "<path>"
    },
    "name": "proximo_plan"
  }
}

Input Schema

Name	Required	Description	Default
`args`	No
`path`	Yes
`plane`	Yes
`fields`	No
`method`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.49.1Oct 27, 2026
- removedInput schema / properties / args / anyOf
```
Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / args / default
```
Removed value: -null
```
- removedInput schema / properties / args / title
```
Removed value: -"Args"
```
- addedInput schema / properties / args / type
```
Added value: +"object"
```
- addedInput schema / properties / fields
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / method / title
```
Removed value: -"Method"
```
- removedInput schema / properties / path / title
```
Removed value: -"Path"
```
- removedInput schema / properties / plane / title
```
Removed value: -"Plane"
```
- removedInput schema / title
```
Removed value: -"_planArguments"
```
Addedv0.46.2Oct 24, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true; the description reinforces it ('READ-ONLY, mutates nothing') and then adds substantial behavior: the verdict carries armed/tier/consent, missing required parameters are surfaced, fields='all' reveals the vendor's full schema, and mutation plans read the target as current/change/noop. It also discloses the fuzzy-path behavior (single match planned, multiple returned as candidates), which is exactly the kind of trait annotations cannot convey.

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?

Front-loaded with the most important guarantee (READ-ONLY) and packed with load-bearing clauses; nearly every phrase carries information. It is semicolon-dense and slightly run-on, which costs some immediate parseability, but there is no filler.

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 an output schema exists, the description needn't enumerate return fields, yet it explains the key verdict concepts and sequencing. Remaining gaps are the semantics of plane/method and how the 'required ones you lack' list should be acted on, which matter for a five-parameter planning 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 0% across five parameters, so the description must compensate. It does document fields (comma-separated names or 'all'), path (may be free words, with match/candidate semantics), and indirectly args ('the parameters you gave'), but plane (an enum) and method are never explained in the description or schema, leaving genuine gaps.

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 concrete job: return the governed verdict (armed, tier, consent) for one address, plus the parameters supplied and the required ones missing, plus optional schema expansion via fields. It also differentiates from proximo_call by naming it as the tool that must follow. It doesn't distinguish itself from proximo_find, whose name-resolution territory ('path may be words') it partially overlaps.

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?

"Run before proximo_call" gives an explicit sequencing rule, and 'several come back to pick from' explains what to do when a path is ambiguous. However, there is no when-not guidance (e.g., when to skip planning and call directly) and no routing versus proximo_find/proximo_read for resolution or inspection.

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

Deploy Server