s2docs MCP Server

Overview Schema Source Related Servers Discussions Admin

deploy_push

Destructive

Copies files to a remote host over SSH, verifies MD5 hashes after transfer, and returns a deploy ID for later re-checking.

Instructions

Copy files to a host and verify what landed (Get-FileHash over SSH). Returns a deploy id whose entries carry the server-checked md5 + verified flags. Call deploy_verify later to re-check.

    The push takes the host lease for the copy+verify window: a host held by another owner is a
    conflict (pass that owner if it is you), a free host is claimed as 'deploy:<id>' and released
    when the copy finishes. Inside an orchestration project the project already holds the lease as
    'project:<project_id>', so pass that as `owner` (the `cs2_live_test` deploy step does).

Input Schema

Name	Required	Description
`addon`	No
`files`	Yes	Manifest: {path, local} entries to copy
`owner`	No	Your host-lock owner if you already hold the lease (the push reuses it and leaves it locked). Inside an orchestration project pass 'project:<project_id>' — the project holds the lease for the whole run
`verify`	No	Re-check MD5s on the host after copying
`dry_run`	No
`host_id`	Yes	Host id from list_hosts, e.g. 'build-pc'
`parallel`	No
`dest_root`	Yes	Remote destination root, e.g. 'C:/iso_build/addons'

Output Schema

Name	Required	Description
`id`	Yes
`addon`	No
`notes`	No
`owner`	No	host-lock owner effective for this push: 'deploy:<id>' when the server took the lease itself, else the caller's owner whose lease was reused
`status`	Yes
`entries`	No
`host_id`	Yes
`web_url`	No	Absolute URL of this deployment's page in the web UI (Activity page)
`dest_root`	Yes
`created_at`	Yes
`updated_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations (destructive, non-idempotent, open-world): it discloses the host-lease lifecycle (claimed as 'deploy:<id>', released when the copy finishes), the conflict semantics, and the project-lease convention 'project:<project_id>'. This is exactly the mutating-side-effect context an agent needs before invoking a destructive 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-loads the action and the post-check in the first sentence, then details the lease model. Dense but mostly earning its place; the parenthetical asides ('the `cs2_live_test` deploy step does', 'hashed/sized on push') add a bit of clutter.

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?

An output schema exists, so describing return values is optional — the description covers them lightly (deploy id entries with md5 + verified flags). Lease and conflict semantics are complete; the only shortfall is unexplained secondary parameters (dry_run, parallel, addon).

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?

With 63% schema coverage, the description compensates by explaining `owner` in depth (pass another's owner if it's you, pass 'project:<project_id>' inside a project) and implying verify behavior and the file manifest. However, `dry_run`, `parallel`, and `addon` are not explained anywhere, leaving gaps.

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?

States a specific verb+resource: copy files to a host, verify hashes over SSH, return a deploy id with md5/verified flags. It explicitly distinguishes itself from the sibling deploy_verify ('Call deploy_verify later to re-check'), so an agent can route between them without opening schemas.

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 clear operational context: call deploy_verify afterward for re-checks, and pass `owner` when another party holds the lease or when inside an orchestration project. It explains the conflict case (host held by another owner) but doesn't broadly state when NOT to use this versus deploy_list or build flows — still strong guidance.

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

Deploy Server