Skip to main content
Glama

Pethost

by dev.pethost
OverviewDiscussionsAdmin

CreateTransfer

Destructive

A one-request URL moving one file straight between you and the machine: run command in a shell, or send http_method to url yourself, before expire_time.

  • upload_archive: the project's directory, packed, for CreateProject's or DeployProject's upload_id once the PUT answered 200 with what it holds.

  • upload_file: one file into a container or volume, replacing any file there (replaces), creating parents.

  • download: a file, or a directory as a .tar (file_name).

  • download_database: a database project's dump, made as it downloads: Postgres's for pg_restore (roles are not in it), Valkey's .rdb. One at a time per database. Plain-text answers: 404 used or expired URL, 409 FAILED_PRECONDITION, 413 archive over 2 GiB, 422 unsafe archive (a reason per line), 503 UNAVAILABLE, 507 disk full. A failed transfer keeps nothing: get a new URL. Errors as ReadPath; FAILED_PRECONDITION also = downloading neither a file nor a directory, uploading onto a non-file, a mount point, /proc or /sys, the hostname not yet certified, or a dump of a project that is no database or is not running. NOT_FOUND also = a Postgres database the server lacks (the message lists its databases). RESOURCE_EXHAUSTED = disk full, or too many transfers. UNAVAILABLE = Postgres runs but does not answer yet: try again shortly.

Input Schema

NameRequiredDescriptionDefault
downloadNoA directory comes as a .tar of what ReadPath shows; symlinks kept. At most one of service, volume. Where the path is. Neither = the project's deployed files.
upload_fileNoAt most one of service, volume.
upload_archiveNoThe project's directory as a zip, tar or tar.gz (told by content), for CreateProject's or DeployProject's upload_id: {} is enough. A single top folder is unwrapped; .git, __MACOSX, .DS_Store, ._* are dropped. Leave out what the build makes again (node_modules, .venv, target).
download_databaseNoA database project's dump: Postgres's in its custom format, Valkey's .rdb.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / description
      Previous value: -"At most one of upload_archive, upload_file, download."New value: +"At most one of upload_archive, upload_file, download, download_database."
    • addedInput schema / properties / download_database
      Added value: +{
+  "additionalProperties": false,
+  "description": "A database project's dump: Postgres's in its custom format, Valkey's .rdb.",
+  "properties": {
+    "database": {
+      "description": "Postgres: the database to dump. Empty = \"app\", the apps'.",
+      "type": "string"
+    },
+    "project_id": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructive=true and non-idempotent, and the description goes well beyond them: it discloses the 2 GiB archive limit, 422 unsafe-archive reasons, replacement semantics ('replacing any file there'), that a failed transfer keeps nothing and needs a fresh URL, disk-full/dump-in-progress constraints, and a full status-code-to-meaning table. That is exactly the extra behavioral context the annotations cannot carry.

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?

Purpose and variant list are front-loaded and the bullet structure makes modes scannable. The trailing error-code paragraph is a run-on chain of terse clauses ('404 used or expired URL, 409 FAILED_PRECONDITION...') that is dense to parse, though each clause carries distinct, non-redundant information.

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 multi-variant, nested-object tool with no output schema, the description covers the return artifact (a one-request URL), expiry, per-mode constraints, and failure semantics thoroughly. It is slightly incomplete in that the command/http modes it mentions are absent from the schema, leaving the agent unsure which modes are actually callable.

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 100%, so the baseline is 3, and the bullets mostly restate variant semantics already in the schema (file_name default, empty=root, at-most-one constraints). Worse, the opening sentence advertises 'run `command` in a shell, or send `http_method` to `url`' parameters that do not appear anywhere in the input schema, creating a mode/schema mismatch rather than added parameter meaning.

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 opening sentence names the operation (create a one-request URL that moves a file or runs a command against the machine) and the four schema variants are spelled out as bullets, so the resource and scope are identifiable. It does not, however, distinguish itself from siblings such as ReadPath or RunServiceCommand, which perform overlapping read/exec work, so the agent must infer the boundary.

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?

Each variant carries a use condition: upload_archive is explicitly 'for CreateProject's or DeployProject's upload_id', download notes 'at most one of service, volume', download_database warns 'one at a time per database', and upload_archive says to exclude build output. This is clear context for choosing a mode, but no explicit when-not-to-use or routing to the command/http siblings.

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

All Pethost toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources