Skip to main content
Glama

appcrane_push_to_managed_app

Push multiple files to a managed app's repository using server-side authentication. Supports inline content and staged uploads for large files, creating a single commit.

Instructions

Push a batch of files to a managed app's AMC_ repo, authenticated server-side via AppCrane's service-account credential. Use this — NOT github_push_files — for managed apps, because github_* tools authenticate with the caller's personal PAT, which has zero access to the service account's repos. Multiple files become a single commit. files: [{ path, content, encoding? }] where encoding defaults to "utf-8" (use "base64" for binaries like icons). Requires the app to already exist via appcrane_create_managed_app. v2.7.22: response now includes per-file sha256 (hex) and decoded bytes length so you can verify integrity — compute the SHA-256 of the bytes you sent, compare to the server's echo, and fail loudly if they differ. Essential for binary files where inline-string truncation or trailing-byte issues would otherwise produce a silently-broken commit. v2.10.7: for a large CODE file, do NOT inline it — upload the bytes over HTTP and commit by token. (1) curl -F file=@big.js -H "X-API-Key: <your dhk_mcp_ key>" https://<host>/api/files/staged returns { token, sha256, size_bytes }. (2) Pass that file as { path, staged_token } instead of { path, content }. The server reads the staged bytes and commits them verbatim, so 100+ KB sources push reliably without the model having to emit the content (which is where inline truncation comes from). Per file, provide exactly one of content or staged_token. Staged tokens are owner-scoped and expiring.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesManaged app slug. Repo name resolved as AMC_<slug>.
filesYes
branchNoTarget branch. Defaults to the repo's default branch (usually "main").
messageNoCommit message. Defaults to "chore: scaffolding for <slug>".
Behavior5/5

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

With no annotations, the description fully discloses authentication, batch commit behavior, per-file integrity check, staged upload process, and version-specific changes, ensuring the agent understands operational details.

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?

Well-structured with front-loaded purpose, but includes detailed version notes and examples that make it verbose; still earns its length for a complex tool.

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?

Covers authentication, file types, sizes, integrity, and staged upload; lacks formal return schema but describes response fields (sha256, bytes) and error handling ('fail loudly'). Almost complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds significant meaning beyond schema: explains slug resolves to AMC_<slug>, encoding behavior with staged_token, and detailed staged_token workflow. Schema coverage is 75% but description compensates fully.

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?

Explicitly states 'Push a batch of files to a managed app's AMC_<slug> repo' and contrasts with github_push_files, making the tool's purpose and intended use clear.

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?

Provides explicit guidance: 'Use this — NOT github_push_files — for managed apps' with rationale, plus prerequisite 'Requires the app to already exist via appcrane_create_managed_app', and instructions for large files versus inline.

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/gitayg/appcrane-mcp'

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