Skip to main content
Glama
Sign In
Nexus Relay

Nexus Relay

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

release_file_reservations

Release file reservations by ID, overlapping paths, or all held by an agent to free those files for other agents.

Instructions

Same as release, under the mcp_agent_mail name and parameters: your reservations with these ids, or those overlapping these paths, or all of yours.

Args: paths: release your reservations overlapping these absolute paths (optional). file_reservation_ids: release these reservations (optional). project_key: accepted for compatibility, ignored. agent_name: accepted for compatibility, ignored.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "release_file_reservations"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsNo
agent_nameNo
project_keyNo
file_reservation_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.7

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety bar is lower; the description still adds real value by disclosing that `project_key` and `agent_name` are silently ignored (a common source of agent confusion about scope). It does not disclose return values or what happens when no reservation matches, which are moderate gaps for a mutation tool.

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 identity/mode sentence, followed by a compact Args block with no filler. Minor redundancy in restating parameter names already visible in the schema, and the sentence break across 'those / overlapping these paths' reads awkwardly.

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 zero-required-parameter mutation tool with 0% schema coverage and no output schema, the description covers purpose, all four parameters, and the compatibility-alias quirk. The main unaddressed risk is that calling it with no arguments releases every reservation the agent holds, which is stated but not flagged as a cautionary default.

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 description coverage is 0%, so the description carries the full burden — and it documents all four parameters, including the critical fact that two of them are no-ops. It also adds format meaning ('absolute paths') missing from the schema. It does not clarify whether ids and paths are mutually exclusive or combined.

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?

Names the exact resource ('your reservations') and enumerates the three selection modes: by ids, by overlapping paths, or all of yours. It also explicitly identifies itself as a compatibility alias of the sibling `release`, which an agent can use to tell the two apart. It stops short of a standalone explanation of what releasing a reservation actually does, relying on the `release` cross-reference.

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?

Implies when to call it (release reservations you hold by id or path) and notes the default of 'all of yours' when nothing is supplied. However, it never states why an agent would pick this over the sibling `release`, or when a caller should prefer `cancel` / `reservations` instead — the choice is left as 'they are the same'.

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