Skip to main content
Glama

gage_push

Sends a built bundle directory off the machine through the relay, sealed to the recipient, after explicit confirmation.

Instructions

Send a built bundle directory off this machine, through the relay, sealed to the recipient. Requires confirm: true -- the same gate as gage push --yes, because this is the moment something leaves. Separate from gage_send because the CLI separates them.

Input Schema

NameRequiredDescriptionDefault
toYes
dirYes
confirmNomust be true; states that you meant to send this off the machine

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that data leaves the machine through a relay and requires an explicit confirmation gate, but it omits permissions, return behavior, post-send state, and error conditions.

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 description is short and front-loads the action and confirmation gate. The final sentence about gage_send is low-value because it explains CLI separation rather than tool-choice semantics, but it does not make the definition bloated.

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?

For a send-off-machine operation with no annotations and no output schema, the description provides enough to understand the action and confirmation gate. It remains incomplete about recipient format, permissions, success/failure behavior, and how this tool relates operationally to gage_send and gage_buddies.

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 only 33%, and only confirm is documented in the schema. The description compensates somewhat by clarifying dir as a built bundle directory and to as the recipient, but it does not explain acceptable recipient formats, path expectations, or how to obtain recipient values.

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?

The description states a specific verb and resource: send a built bundle directory off the machine through a relay, sealed to a recipient. It acknowledges the sibling gage_send, but only says they are separate because the CLI separates them, which does not functionally distinguish the two tools for an agent.

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?

It gives a clear prerequisite: confirm must be true because this is the moment something leaves the machine. It implies the tool is for built bundle directories rather than general sends, but it does not explicitly say when to choose gage_push over gage_send or other siblings.

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