Nife MCP Server

Deploy site

deploy_site

Deploy a NEW static site. Performs every backend step (validate the target, fetch or archive the code, resolve build settings, start the deployment) in a single call. Supports public and private Git repositories, archive URLs, prebuilt or built-from-source sites. Returns once the deployment is submitted; poll get_site_status for progress.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_name": "<site_name>",
      "organization_id": "<organization_id>",
      "source_type": "<source_type>"
    },
    "name": "deploy_site"
  }
}

Input Schema

Name	Required	Description	Default
`env`	No	Environment variables for the build, as {NAME: value}
`branch`	No	Branch or tag name (source_type='git')	main
`ref_type`	No	Public GitHub only: 'heads' for a branch, 'tags' for a tag	heads
`repo_url`	No	Repository URL, e.g. https://github.com/owner/repo (source_type='git')
`framework`	No	Framework preset for import_type='source' (see list_site_frameworks or inspect_repository)
`site_name`	Yes	Lowercase letters, digits, '-' or '_' (max 30). The site is served at <site_name>.on.nifetency.com.
`archive_url`	No	Public https URL of the archive (source_type='archive_url')
`import_type`	No	'build' = the code is already built static files; 'source' = build it first (needs a plan that allows source builds)	build
`source_type`	Yes	'git' for a GitHub/GitLab/Bitbucket repo (public or private), 'archive_url' for a public https link to a .zip/.tar/.tar.gz
`node_version`	No	Node major version for the build (default 20)
`build_command`	No	Override the preset build command
`install_command`	No	Override the preset install command
`organization_id`	Yes	Organization id from list_organizations
`pat_secret_name`	No	NAME of a stored secret holding a Git token, REQUIRED for PRIVATE repos (see list_git_secrets). Never pass the token itself.
`cloud_account_id`	No	Host the site in this AWS cloud account of the organization (from list_cloud_accounts) instead of Nife's account
`output_directory`	No	Override the preset build output directory

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations cover mutation/open-world/non-idempotent profile, and the description adds genuinely new behavior: the multi-step backend pipeline (validate, fetch/archive, resolve build settings, start deployment) and the asynchronous return-at-submission semantics. It does not mention permissions or quota/plan gating beyond source builds, which the schema covers.

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?

Four short sentences, front-loaded with the verb and the NEW qualifier, then scope, then return/next-step. No filler and nothing repeated from the schema.

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 16-parameter async creation tool with an output schema and full annotation coverage, the description supplies the missing pieces an agent needs: orchestration scope, source-type support matrix, and the polling contract. Only minor gaps remain (plan prerequisites for source builds, private-repo token requirement) and those are already handled by schema parameter descriptions.

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 coverage is 100%, so per-parameter semantics are already fully documented in the schema. The description echoes the source-type space (public/private git, archive URLs, prebuilt vs from-source) without adding syntax or defaults beyond what the schema states. Baseline 3 applies.

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 and resource ('Deploy a NEW static site') and contrasts with the sibling redeploy_site via the capitalized NEW. Also enumerates what the call encapsulates, so an agent knows it is an end-to-end orchestration rather than a partial step.

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?

Sets the create-vs-redeploy boundary and tells the agent what to do after the call ('poll get_site_status for progress'). No explicit when-not-to-use guidance (e.g., name collisions, use check_site_name first), but the routing intent is clear.

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

All Nife MCP Server 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.

Resources

Need Help?