labgrid-mcp

by onurcelep

Overview Schema Source Related Servers Discussions Admin

Python

Remote

reservation_wait

Block-and-poll a reservation until it allocates a place, or times out.

Instructions

Block-and-poll a reservation until it allocates a place, or times out.

        ``timeout_s`` is clamped to at most 25.0 (PlaceSession.reservation_wait,
        §11.14), like ``wait_for_change``. Only an *acquired* reservation
        auto-refreshes coordinator-side -- polling here IS what keeps a
        merely-``waiting``/``allocated`` reservation's TTL alive, so the
        reservation still needs an ``acquire_place`` (or another ``reservation_wait``/
        ``cancel_reservation``) soon after this returns, or it expires
        ~60s after creation regardless of the outcome reported here.
        Returns ``{"reservation_id", "state", "allocations", "changed"}``
        plus the deprecated ``token`` mirror of ``reservation_id`` --
        ``changed`` is True iff the reservation is allocated by the time
        this returns; a dead reservation (expired/invalid/unknown) or a
        genuine timeout both report ``changed=False`` without raising.
        Non-destructive but not idempotent (each call keepalive-polls).
        ``reservation_id`` is required; ``token`` is its deprecated alias.

Input Schema

Name	Required	Description
`token`	No	Deprecated alias of reservation_id; pass reservation_id instead.
`timeout_s`	No
`reservation_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.5Oct 14, 2026

addedInput schema / properties / reservation_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Reservation Id"
+}

addedInput schema / properties / token / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / token / default
```
Added value: +null
```
addedInput schema / properties / token / deprecated
```
Added value: +true
```

addedInput schema / properties / token / description

Added value: +"Deprecated alias of reservation_id; pass reservation_id instead."

removedInput schema / properties / token / type
```
Removed value: -"string"
```
removedInput schema / required
```
Removed value: -[
-  "token"
-]
```

First observedv0.1.0Aug 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds far more than the annotations convey: timeout clamped to 25.0s, the TTL/keepalive consequence of polling, the exact return keys, the meaning of `changed`, and that dead reservations and timeouts both return changed=False without raising. It also states 'non-destructive but not idempotent', consistent with readOnlyHint=false, destructiveHint=false, idempotentHint=false.

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?

The blocking/TTL semantics are front-loaded and every clause carries information, but the RST markup and backtick-heavy phrasing add visual noise, and the return-shape sentence duplicates the output schema.

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 blocking, TTL-sensitive call with a non-empty output schema, the description covers the timeout cap, the keepalive obligation, and negative outcomes. The one loose end is the mismatch it introduces by calling reservation_id 'required' while the schema lists zero required params and defaults it to null.

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 only 33% (timeout_s and reservation_id are undocumented in the schema), and the description compensates by stating timeout_s is clamped to 25.0, that reservation_id is required, and that token is its deprecated alias. Only the default/timeout-unit nuance is left implicit.

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?

Opens with a precise verb+resource+scope: 'Block-and-poll a reservation until it allocates a place, or times out.' This cleanly distinguishes it from siblings like reserve, acquire_place, and wait_for_change, and the blocking/polling semantic is stated up front.

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?

Gives real usage context: timeout is clamped like wait_for_change, and the caller must follow up with acquire_place (or another reservation_wait/cancel_reservation) or the reservation expires ~60s after creation. It stops short of an explicit 'prefer X over Y when' rule against the many sibling reservation tools, so it is clear context rather than full routing guidance.

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