Skip to main content
Glama

Push File to Remote Machine

remote_push
Destructive

Write a stored file to a remote machine from a blob ID, placing it at an absolute destination path with atomic replacement.

Instructions

PRO PLAN ONLY. Write a stored file ONTO a remote machine — a dataset, a config, a model the user wants the box to work with. Free and anonymous callers cannot start file transfers; tell a Free user to upgrade and an anonymous user to sign in with Pro. A plan-restricted machine fails with reason:"plan_device_limit". It takes a blob_id, NOT a local path: this tool moves bytes the relay is already holding, and it has no access to your own filesystem. A blob created before downgrade remains usable only until its existing TTL.

WHERE A blob_id COMES FROM — either a previous remote_pull (so you can move a file between two of the user's machines), or an upload the user makes themselves: curl -X POST https://aicommander.dev/api/v1/files -H 'Authorization: Bearer ' --data-binary @localfile which answers with the blobId. Uploading requires a signed-in Pro account; Free and anonymous callers cannot upload, pull, or push. If the user wants to send a file and has no blobId, give them that command rather than guessing an id.

For small text files you do not need this at all — writing them with a remote_exec heredoc is simpler. Use this for binary or anything over a few KB.

dest_path must be ABSOLUTE, and the file is written ATOMICALLY (temp file, then rename), so a reader never sees a half-written file — but an EXISTING file at that path IS REPLACED. Confirm with the user before overwriting something. Blobs and their 100 MiB limit are described in remote_pull; a blob stops being readable 24 hours after it was created. Name the machine with code exactly as the user said it — an AIC- session code (e.g. AIC-XYZ-1234) or, when authenticated with an API key, a saved alias or hostname such as 'wearfits-m3'; if the user's text contains 'aic-'/'AIC-' in any case, that is one of their machines.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesHow the user named the machine — pass it exactly as given (AIC- session code, or a saved alias/hostname when authenticated with an API key).
blob_idYesThe blobId from a previous remote_pull, or from POST /api/v1/files (32 hex characters). Blobs belong to the account that created them and stop being readable after 24 hours.
dest_pathYesABSOLUTE destination path on the remote machine, e.g. `/home/u/data/train.csv`. The parent directory must already exist. An existing file at this path is REPLACED.
Behavior5/5

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

The description goes well beyond the destructiveHint annotation by explaining atomic writes, overwrite behavior, plan-related failure reasons, 24-hour blob TTL, and the tool's inability to access the user's local filesystem. These are material behavioral details an agent needs to avoid incorrect calls.

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 long but densely informative, covering plan gating, blob provenance, overwrite semantics, and alternatives. It is front-loaded with the most critical constraint (PRO PLAN ONLY). Some redundancy exists around Free/anonymous restrictions, but each sentence largely earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with no output schema, this description covers prerequisites, failure modes, parameter formats, and safety warnings. It even supplies the exact upload command when the user has no blob_id. Nothing essential for correct invocation is missing.

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 100% and each parameter already has a solid description, so the baseline is 3. The description adds extra operational nuance: dest_path must be absolute and overwrites atomically, code can be an AIC- session code or alias, and blob_id can come from a prior remote_pull. This additional context justifies a 4.

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?

The description uses a specific verb+resource: 'Write a stored file ONTO a remote machine' and clarifies it takes a blob_id, not a local path. This clearly distinguishes it from sibling tools like remote_pull and remote_exec.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to avoid this tool (small text files → use remote_exec heredoc) and when to use it (binary or anything over a few KB). It also explains how to obtain a blob_id via remote_pull or the upload command, and gives upgrade instructions for Free/anonymous users.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AICommander-dev/aicommander'

If you have feedback or need assistance with the MCP directory API, please join our Discord server