Server4Agent

Import project from a bundle

import_project

Recreate a project on a server from a bundle that export_project produced, here or on another Server4Agent deployment. Pass the bundle base64 encoded in bundle; large bundles are better uploaded from the dashboard, since the request body has a size limit. The new project is always private, gets its own slug and URL, and starts bringing itself up right away (the bundle only reaches the server as part of that run). Env vars the bundle names are bound only where this account already holds a value, and no .env file travels: the result lists what is still missing in missing_env, and the app will not run until you set those with set_secret.

Input Schema

Name	Required	Description
`name`	No	Name the project here. Defaults to the name in the bundle.
`bundle`	Yes	The export file, base64 encoded.
`server_id`	Yes	The server's id, as returned by create_server or list_servers.

Output Schema

Name	Required	Description
`id`	Yes	Project id.
`url`	No	Public URL. null while the project is private.
`name`	No	Project name.
`slug`	No	URL slug. Stays the same when visibility changes.
`access`	No	Who may open the URL once it is public.
`source`	No	What the workspace was seeded from: kind plus git_url, ref, subdir, or archive_path.
`template`	No	Template id it was created from.
`warnings`	No	Anything about the bundle worth knowing.
`bound_env`	No	Env vars bound from secrets this account already holds.
`lifecycle`	No	ephemeral projects are removed with cleanup_project.
`server_id`	Yes	The server the project lives on.
`created_at`	No	ISO 8601 timestamp.
`init_phase`	No	Where bring-up has got to, for a project seeded from a source.
`updated_at`	No	ISO 8601 timestamp.
`url_status`	No	Whether the address and certificate are ready. Not a health check.
`visibility`	No	public = live at url. private = not publicly reachable.
`cert_status`	No	State of the shared certificate. null while private.
`description`	No	One-line description.
`exported_at`	No	When the bundle was made, ISO 8601.
`init_run_id`	No	The bring-up run that unpacks and starts it. Poll it with get_run.
`listen_port`	No	The port inside the box this project's URL is routed to.
`missing_env`	No	Env vars still unset. Set them with set_secret before the app will run.
`imported_from`	No	The deployment the bundle was exported from.
`runtime_status`	No	Whether the project is running or paused.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover safety flags, yet the description discloses the resulting state (always private, new slug and URL, build starts immediately), the env-var binding rule, the absence of a .env file, and the blocking condition that the app won't run until secrets are set. That is substantial behavior beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then size caveat, then post-conditions, then env-var semantics. Every clause carries operational information; nothing is padding despite the length.

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 non-idempotent, open-world write with an output schema present, the description covers the full lifecycle of the call: input constraint, side effects, resulting visibility, and the follow-up action required before the app runs. An agent can invoke it correctly and know what to do next.

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%, so the baseline is 3, but the description adds meaning: bundle must be base64 and is subject to a body size limit with a better path for large bundles, and name falls back to the bundle value. server_id gains no extra context beyond the schema.

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?

Opens with a specific verb+resource ('Recreate a project on a server from a bundle') and immediately ties it to the producing sibling, export_project. That pairing makes it unmistakable versus create_project or init_project without opening any schema.

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?

Explicitly routes large bundles to the dashboard upload path due to request-body size limits, and directs the agent to set_secret afterward for missing env vars. What's missing is an explicit statement of when to prefer create_project over import, though the bundle prerequisite implies it.

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

All Server4Agent tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.