Skip to main content
Glama
PlugLayer MCP Server

PlugLayer MCP Server

Official
by pluglayer

PlugLayer MCP Server

Deploy and manage your infrastructure through natural language with any MCP-compatible AI assistant.

Public plugin setup

Public PlugLayer plugins use the hosted MCP endpoint with OAuth. In the PlugLayer portal, choose Codex, Claude Code, Cursor, or Antigravity, copy the setup prompt, paste it into the agent, and approve PlugLayer in the browser. The agent stores and refreshes its OAuth connection. No Python, uv, terminal, desktop app, or API token is required.

The local commands below are an advanced developer path for explicitly running an MCP server on the same machine.

Related MCP server: hostman-mcp-server

Local installation

PLUGLAYER_API_KEY=your-pluglayer-api-token uvx pluglayer-mcp

This local command mode uses the MCP stdio transport by default, which is the right mode for Cursor, Claude Code, and other editor-launched command servers. The pluglayer-mcp command now always uses stdio so editor clients cannot accidentally switch it into HTTP mode.

Option 2: pip

pip install pluglayer-mcp
PLUGLAYER_API_KEY=your-pluglayer-api-token pluglayer-mcp

Configuration

For editor installations, PlugLayer also reads ~/.pluglayer/credentials.env on every tool call. Saving or rotating PLUGLAYER_API_KEY (and optionally PLUGLAYER_API_URL) there takes effect on the next call without restarting the server. A client's OAuth or generic mcp_auth action does not configure credentials for a local stdio server.

Claude Desktop

Add to ~/.config/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "pluglayer": {
      "command": "uvx",
      "type": "stdio",
      "args": ["pluglayer-mcp"],
      "env": {
        "PLUGLAYER_API_KEY": "your-pluglayer-api-token"
      }
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "pluglayer": {
      "command": "uvx",
      "type": "stdio",
      "args": ["pluglayer-mcp@latest"],
      "env": {
        "PLUGLAYER_API_KEY": "your-pluglayer-api-token"
      }
    }
  }
}

Use either this manual registration or the PlugLayer Cursor plugin's bundled server, not both. If both appear in Cursor's Tools & MCP settings, disable or remove the manual copy so tool calls cannot land on servers with different authentication state.

Remote HTTP (hosted)

The remote MCP server runs at https://mcp.pluglayer.com/mcp and uses OAuth metadata discovery. Add that URL in an agent's remote MCP settings and choose browser authentication; do not paste a PlugLayer API token into chat.

If you intentionally want to run the package itself as an HTTP MCP server, use:

pluglayer-mcp-http

Release Checklist

Before publishing a new pluglayer-mcp build:

  1. Confirm local command mode still uses stdio by default.

  2. Confirm PLUGLAYER_API_URL override works when pointed at a dev API.

  3. Let the publish workflow stamp the package version from the UTC date/time, unique GitHub run ID, and run-attempt number. Do not reuse a published PyPI version or artifact filename.

  4. Publish from the public repo main branch after reviewing the dev -> main PR.

After publishing:

  1. Restart Cursor, Claude Code, or the MCP client you are testing.

  2. If the editor still behaves like an older MCP build, remove and re-add the MCP server entry, then restart the editor.

  3. Re-test with a simple command such as:

    • get_current_user

    • list_projects

    • get_compute_summary

    • list_my_feedback

Cursor Notes

  • For command-based MCP setup, use uvx pluglayer-mcp.

  • Do not force HTTP transport for local editor usage.

  • pluglayer-mcp always uses stdio, which is the correct transport for Cursor-launched command servers.

  • Only use pluglayer-mcp-http when you intentionally want to run the package itself as an HTTP MCP server.

Available Tools

The MCP calls the PlugLayer FastAPI backend instead of re-implementing backend business logic. Auth, roles, ownership, compute guards, and k3s orchestration remain in the backend. MCP and editor plugins should authenticate with a PlugLayer API token created in the PlugLayer Settings page, not the browser/session auth token.

Managed registries are configured by PlugLayer admins in the platform UI/API. When deploy_image uses mirroring, the backend picks a registry the current user is allowed to use and keeps Kubernetes pull secrets in sync automatically.

Runtime networking and replicas

get_app_access_policy and update_app_access_policy expose outbound policy separately from public ingress. egress_mode=deny_all permits DNS and same-project service traffic but blocks internet destinations. Use egress_mode=allow_cidrs with explicit IP/CIDR entries for a small set of external endpoints; the backend applies this as a per-app Kubernetes NetworkPolicy. allow_all preserves the platform's normal HTTP/HTTPS egress.

replicas creates independent pods. Public routes do not promise cookie or header session affinity, and HPA-style CPU autoscaling is not currently available through MCP. Stateful WebSocket or room-based services should use a single replica or externalize room state and routing until those controls are introduced.

Databases are a first-class Data Layer workflow in MCP. When a user needs a new database, wants to know whether one already exists, asks for a connection string, or needs env vars to wire an app to a database, the preferred MCP path is:

  1. list_user_databases

  2. if needed, list_database_templates

  3. check_slug_availability

  4. optionally check_database_slug_availability

  5. create_database

    • the MCP tool resolves required deploy-time database env vars itself

    • password/secret/token/key fields are generated there when the template expects a random value

    • database-name placeholders are filled from the chosen app name

  6. get_task_status

  7. get_database_connection_details

  8. optionally get_database_logs when troubleshooting

  9. use update_database_access, restart_database, or remove_database for follow-up lifecycle actions

After provisioning a database, the assistant should proactively suggest or apply exact env var updates for dependent apps instead of leaving the user with only a raw connection string.

Marketplace template deployment through MCP now supports both:

  1. deploying into an existing project by project_id

  2. creating a new project inline by passing project_name

Tool

Description

get_current_user

Show the Authentik-backed user and roles

get_user_context

Load the caller's stored user memory/context

update_user_context

Update the caller's stored user memory/context

submit_feedback

Submit authenticated, redacted product feedback with optional affected-tool, expected/actual behavior, error, and page context

list_my_feedback

List the authenticated user's feedback tickets and statuses

get_feedback

Inspect one feedback ticket and its current resolution note

update_my_feedback

Update the title or description of an owned feedback ticket without changing its admin-managed status

list_projects

List authenticated user's projects

get_my_projects

Alias for listing the current user's projects

create_project

Create a new project namespace

rename_project

Rename a project's display name without changing its slug, namespace, or existing app URLs

update_project_metadata

Update a project's display name and/or description without changing routing identity or custom domains

get_project

Get project details, current apps in the project, and attached custom-domain state

remove_project

Remove one of the user's projects by deleting its apps first, requesting namespace cleanup, and then archiving the project record/history

delete_project

Alias for remove_project

get_compute_summary

Show account-level capacity, or pass project_id for attached-node recorded allocation plus live scheduler headroom; estimate first when sizing is unclear

get_my_available_compute

Show the current user's available compute capacity; pair with estimate first for planning

get_my_available_computes

Alias for available compute capacity

estimate_compute

Estimate required compute, monthly price, and a tailored offer link; preferred before purchase/allocation decisions

list_nodes

List accessible compute nodes

list_attachable_project_nodes

List owner-held dedicated nodes and their project attachment state; legacy records that duplicate another physical worker are explicitly blocked

attach_node_to_project

Attach an available dedicated node to one project (owner-only, idempotent)

detach_node_from_project

Detach an unused dedicated node after explicit confirmation; active apps block it

list_registries

List the registries currently available to the user

deploy_image

Mirror a Docker image into PlugLayer's managed Docker Hub namespace, then deploy it after backend compute checks; if a similar app already exists and the namespace is full, use update/replace flow instead of a brand-new app

upload_image_archive_and_deploy

Upload a Docker or OCI tar archive that is already on this MCP host; if the target app already exists, switch to the app upload-first redeploy flow, otherwise create and deploy a new app

upload_image_archive_and_redeploy_app

Upload a newly rebuilt Docker or OCI tar archive from this MCP host for an existing app, using retry-safe chunks for archives over 16 MiB; push it with a new tag, keep the slug unchanged, and queue that app's redeploy

begin_local_image_upload

Start an upload for an archive that exists only on the user's computer. Returns a one-time chunk token the local machine sends as X-Pluglayer-Upload-Token; do not show that token to the user

complete_local_image_upload

Finish a local chunk upload. project_id creates the app; app_id redeploys the existing app and keeps its slug

deploy_compose

Analyze docker-compose.yml, split it into separate deploy units, route known databases through Data Layer templates, deploy remaining services as separate apps, and require uploaded archives for local-build services

analyze_compose_deploy_plan

Preview how PlugLayer will split a docker-compose stack into Data Layer databases, separate compose apps, and local-build image services

get_compose_local_build_commands

Generate exact docker buildx, smoke-test, and OCI export commands for local-build compose services before they are uploaded and deployed

list_deployments

List running apps/deployments

get_apps_by_project

List apps inside a specific project; use this before deploy when you need to clarify update vs replace vs separate new app, especially when a full namespace should block duplicate new-app deploys

check_slug_availability

Check whether a PlugLayer slug is free inside a project before deploy or rename

get_deployment_status

Check app status and URL

get_logs

Get app logs

get_app_logs

Alias for getting app logs

get_app_access_policy

Read saved IP allowlist, HTTP/TCP limits and exposure without env/connection secrets

update_app_access_policy

Replace a complete app ingress policy through backend permission checks; exact app name and all values required

get_app_connection_env_vars

Inspect masked connection/env fields; explicit reveal=true returns plaintext

apply_app_env_vars

Securely import arbitrary runtime env vars from dotenv/KEY=VALUE, JSON, YAML text, or a direct key/value object; merge or replace, then optionally restart/redeploy without returning values

list_marketplace_templates

List deployable marketplace templates before choosing one for a project

get_marketplace_template

Inspect one marketplace template, including its required env vars

deploy_marketplace_template

Deploy a marketplace template into an existing project or create a new project inline during the same MCP flow

exec_app_terminal

Execute a command in the caller's own deployed app container with a fixed 360-second timeout; keep terminal input at or below 10,000 characters and about 350 lines

redeploy

Redeploy an app after confirming the exact app name; the existing slug stays unchanged

restart_app

Restart an app through a verified rollout; completion requires the task's new pod-template revision to be live

rollback

Roll back to previous version

remove_app

Remove one of the user's apps, tear down its runtime workload, revoke active routing, and mark it as removed

delete_app

Alias for remove_app

delete_deployment

Alias for remove_app

list_database_templates

List ready-to-deploy database templates

list_user_databases

List the caller's provisioned databases, optionally by project

check_database_slug_availability

Check whether a Data Layer slug is free in a project before provisioning or renaming a database

create_database

Provision a database from a template after backend compute and project checks, resolving password-like env vars inside the MCP flow first

get_database_connection_details

Inspect masked database fields and docs; prefer server-side env sync

sync_database_env_to_app

Patch one app's env vars from a provisioned database's concrete connection fields, then restart the existing app

get_database_logs

Read logs from a provisioned database app

update_database_access

Update the public TCP IP allowlist for a provisioned database

restart_database

Restart a provisioned database by queueing its restart flow

remove_database

Queue database removal and return its task ID; poll completion before reporting teardown

delete_database

Alias for remove_database

list_project_domains

List custom domains for a project

get_domains_by_project

Alias for project-domain lookup; use this before asking which domain the user wants so existing project domains can be offered as options

detect_custom_domain_provider

Detect the likely DNS provider and authoritative zone so the user can confirm them before DNS instructions are shown

add_custom_domain

Add a single or wildcard custom domain and return provider-friendly DNS records; explains that root and www need separate routing or an explicit redirect, and rejects GoDaddy apex CNAME attempts with a supported www + 301 forwarding path

verify_custom_domain

Verify TXT/CNAME DNS and activate if attached

attach_custom_domain

Attach a verified custom domain to an app

detach_custom_domain

Detach a domain while keeping verification

get_task_status

Poll async operation progress

inspect_local_github_repo

Check whether the local repo has git plus a GitHub origin configured

get_github_deployment

Inspect an app's GitHub connection and first-run verification state

configure_github_deployment

Owner-authorized binding to exact GitHub repository/owner IDs, branch and workflow

disconnect_github_deployment

Revoke an app's automatic deployment connection and outstanding CI credentials

generate_github_actions

Generate a pinned OIDC workflow for a configured connection; no deployment API-key secret

Example Conversations

Deploy your first app:

"I have a FastAPI app at ghcr.io/myorg/api:latest that runs on port 8000. Deploy it into my production project in my cloud."

Convert docker-compose:

"Here's my docker-compose.yml: [paste]. Deploy this to PlugLayer."

CI/CD setup:

"Generate a GitHub Actions workflow for my api app so every push rebuilds it, uploads it to PlugLayer, and redeploys the same app id."

The agent configures the existing app using its PlugLayer OAuth connection and reads repository metadata using the user's GitHub access. If access is missing, it guides one-time browser authentication. Hosted MCP never inspects the user's local filesystem; repository detection belongs to the agent.

The generated workflow builds an image and uses GitHub OIDC to obtain a short-lived, app-scoped deployment credential. Future pushes need no editor login and no PLUGLAYER_API_KEY secret. Optional PLUGLAYER_BUILD_ENV_JSON and PLUGLAYER_ENV_JSON remain application secrets; existing runtime variables are retained. Setup is verified only after GitHub and the PlugLayer rollout succeed. Workflow generation requires a published immutable OIDC Actions release configured in the backend; report that release prerequisite if generation is unavailable.

Add a custom domain:

"Add api.example.com to my production project, detect the provider, show me the DNS records in a table, then verify it and attach it to my API app."

For a root/www website pair, say whether both hostnames must work. PlugLayer routes exact hostnames, so example.com is not automatically covered when only www.example.com is attached. Configure the root separately or redirect it to www, then test a nested path such as /page-1 on both names.

Provision a database and wire the backend to it:

"Create a Postgres database in my marketplace project, check whether the slug postgres is available first, and after it finishes show me the connection env vars so we can update my backend."

Reuse an existing database instead of creating a new one:

"Check whether I already have a Mongo or Postgres database in my project. If I do, show me the connection details and suggest the backend env vars I should update."

Legacy local stdio credentials

Hosted editor plugins use browser OAuth. New GitHub workflows use OIDC. Neither requires users to manually copy a PlugLayer API key.

Self-managed local stdio installations may still use a user-issued PlugLayer API token stored in their local credential file or PLUGLAYER_API_KEY. Existing key-based Actions remain available for compatibility; migrating a workflow must not delete repository secrets still used by other jobs.

Template authoring

Use get_template_authoring_schema(section="create_draft") and preview_template_compose before saving with create_template_draft. The tools also list/read/update/clone/delete private drafts, submit for admin approval, expose launch context/planning/sessions, and update existing apps from templates. deploy_marketplace_template handles test deployments and accepts database_bindings. Public template tools do not publish or approve; those actions remain in the private Admin Center. Schema and context discovery default to summaries; fetch named sections and context pages as needed. Launch planning creates/resumes a session. close_template_launch_session archives it without cancelling tasks or deleting apps.

Run python scripts/test_local_template_mcp.py from this package for a focused read-only local stdio smoke using saved credentials. The new backend routes must be released before the corresponding MCP/plugin release can pass this check.

App security checks and traffic controls

“Check my apps” or “check my app security” starts with app inventory, status, recent runtime logs, and get_app_access_policy. The four public plugins bundle check-app-security and manage-app-access to distinguish abusive traffic from app faults, preserve legitimate clients, and carry authorized mitigations through verification. Check-only requests produce findings and concrete proposals.

update_app_access_policy uses PUT /v1/plugin/apps/{app_id}/access and the same backend workflow as the portal. Read the existing policy first and provide all values, including the unchanged ones. An empty allowlist opens source access; CIDRs must represent approved trusted clients, not suspected attackers. HTTP limits count requests per peer IP/route/Traefik instance; TCP limits cap concurrent connections. Neither replaces app authentication, and internal traffic bypasses public ingress controls. Saves need no restart.

Release the matching backend route before the MCP/plugins. Validate local stdio reads with python scripts/test_local_app_security_mcp.py; it uses saved public credentials and never changes live app settings or prints logs. This smoke does not prove policy writes or client enforcement; test those only on an explicitly authorized disposable app before releasing the update feature.

Available Tools

70 tools
add_custom_domainB

Add a custom domain after provider detection. Pass the confirmed provider_name and authoritative dns_zone. GoDaddy apex domains are rejected before API creation because GoDaddy cannot publish CNAME @; use www plus apex forwarding.

Inputs: domain (required), project_id (required), mode, app_id, +2 more. Returns: result

analyze_compose_deploy_planA

Analyze a docker-compose.yml and show how PlugLayer will split it into marketplace databases, separate compose services, and local-build services.

Inputs: project_id (required), compose_yaml (required). Returns: result

apply_app_env_varsA

Import runtime env vars into an existing app from dotenv/KEY=VALUE, JSON, YAML text, or a direct key/value object, then optionally restart it. Pass file content, never a local/server file path. Values are not returned.

Inputs: app_id (required), merge, env_vars, env_content, +3 more. Returns: result

attach_custom_domainA

Attach a verified custom domain to an app. Set make_primary=true if you want it to become the app's main URL.

Inputs: app_id (required), domain_id (required), make_primary. Returns: result

attach_node_to_projectA

Attach one available dedicated node to a project. Owner-only and idempotent. After attaching, call get_compute_summary(project_id) before deploying.

Inputs: node_id (required), project_id (required). Returns: result

check_database_slug_availabilityA

Check whether a database/Data Layer slug is available in a project before provisioning or renaming a database.

Inputs: slug (required), project_id (required), exclude_database_id. Returns: result

check_slug_availabilityA

Check whether a PlugLayer slug is available inside a project before deploying or renaming an app/database.

Inputs: slug (required), project_id (required), exclude_app_id. Returns: result

create_databaseA

Provision a database from a ready marketplace template. The MCP tool resolves required DB names and secret-like template fields here, including random password generation, before sending the deploy request.

Inputs: app_name (required), template_id (required), cpu_limit, project_id, +7 more. Returns: result

create_projectA

Create a PlugLayer project namespace. Project creation only requires authentication. Deployment still requires account-level compute; check get_compute_summary before deploying.

Inputs: name (required), description, domain_type. Returns: result

delete_appD

Alias for remove_app() using app wording.

Inputs: app_id (required). Returns: result

delete_databaseD

Alias for remove_database().

Inputs: database_id (required). Returns: result

delete_deploymentB

Alias for remove_app() for clients still using deployment wording.

Inputs: deployment_id (required). Returns: result

delete_projectD

Alias for remove_project().

Inputs: project_id (required). Returns: result

deploy_composeA

Analyze docker-compose.yml, split it into separate deploy units, provision known databases through Data Layer, and deploy the remaining services as separate apps. If any service uses a local Docker build, provide local_image_archives keyed by service name after building and exporting those images.

Inputs: project_id (required), compose_yaml (required), app_name, route_slug, +3 more. Returns: result

deploy_imageA

Deploy a pullable Docker image after PlugLayer mirrors it into a verified private managed repository. There is no public/direct-image bypass. For a local-only image built on the user's machine, use upload_image_archive_and_deploy() instead.

Inputs: name (required), image (required), project_id (required), tag, +10 more. Returns: result

deploy_marketplace_templateA

Deploy a marketplace template into an existing project or a brand-new project created during the same flow. Secret-like required env vars are auto-resolved here before the deploy request is sent.

Inputs: app_name (required), template_id (required), cpu_limit, project_id, +7 more. Returns: result

detach_custom_domainA

Detach a custom domain from its app while keeping verification.

Inputs: domain_id (required). Returns: result

detach_node_from_projectA

Detach a dedicated node from a project. Active apps block detachment. Set confirm=true only after the user explicitly confirms this change.

Inputs: node_id (required), project_id (required), confirm. Returns: result

detect_custom_domain_providerB

Detect the likely DNS/domain provider for a custom domain from public NS records so the agent can confirm it with the user before showing tailored DNS steps.

Inputs: domain (required). Returns: result

estimate_computeA

Estimate the compute needed for a described workload and return a tailored PlugLayer offer link. This is the preferred first step before telling the user to purchase, reserve, or add more compute, and the agent should present the returned link as the user's next confirmation step.

Inputs: use_case, components, expected_requests_per_minute, expected_monthly_active_users. Returns: result

exec_app_terminalA

Run a shell command inside the user's own deployed app container and return the result. Uses a fixed 360-second backend timeout. Keep input at or below 10,000 characters and about 350 lines. This is limited to the caller's app pod only.

Inputs: app_id (required), command (required). Returns: result

generate_github_actionsB

Generate a GitHub Actions workflow YAML that builds an OCI archive and uploads it to PlugLayer for the same app.

Inputs: app_id (required), project_id (required), repo, repo_path. Returns: result

get_app_connection_env_varsA

Get env vars and connection fields for an app. Use this after provisioning so you can update dependent apps with the right URLs or connection strings.

Inputs: app_id (required). Returns: result

get_app_logsD

Alias for get_logs() using app terminology.

Inputs: app_id (required), lines. Returns: result

get_apps_by_projectA

List apps for a specific project. Use this before a new deploy when the project may already contain the same app and you need to clarify update vs replace vs separate new app. If the project already has a similar app and the namespace is full, prefer update or replace flow instead of a brand-new app.

Inputs: project_id (required). Returns: result

get_compose_local_build_commandsA

Analyze a docker-compose.yml and return exact docker buildx, smoke-test, and OCI-export commands for any local-build services before they are uploaded to PlugLayer.

Inputs: project_id (required), compose_yaml (required), workspace_root, image_tag_prefix. Returns: result

get_compute_summaryA

Show accessible compute. Pass project_id for a project-scoped view that includes the nodes attached to that project and per-node usage. If the user is still planning capacity, prefer estimate_compute() first, then use the returned offer link to purchase or request the right amount.

Inputs: project_id. Returns: result

get_current_userA

Show the authenticated PlugLayer user and roles from Authentik.

Inputs: no named parameters. Returns: result

get_database_connection_detailsA

Get a provisioned database's connection strings, env vars, and docs so you can wire other apps automatically.

Inputs: database_id (required). Returns: result

get_database_logsB

Get recent logs from a provisioned database.

Inputs: database_id (required), lines. Returns: result

get_deployment_statusA

Get current app/deployment status and public URL.

Inputs: deployment_id (required). Returns: result

get_domains_by_projectA

Alias for list_project_domains() using project-first wording. Use this before asking the user which domain they want so existing project domains can be offered as options.

Inputs: project_id (required). Returns: result

get_feedbackA

Get one feedback ticket owned by the authenticated PlugLayer user.

Inputs: feedback_id (required). Returns: result

get_logsC

Get recent logs from an app.

Inputs: deployment_id (required), lines. Returns: result

get_marketplace_templateA

Get one marketplace template, including env var requirements. Use this before template deployment so you can resolve secrets and choose project flow correctly.

Inputs: template_id_or_slug (required). Returns: result

get_my_available_computeA

Show the current user's available compute in an end-user friendly format. When capacity is unclear, call estimate_compute() before recommending any purchase or allocation decision.

Inputs: no named parameters. Returns: result

get_my_available_computesA

Alias for get_my_available_compute(). When the user has not sized their workload yet, estimate_compute() should usually come first.

Inputs: no named parameters. Returns: result

get_my_projectsA

Alias for list_projects() using end-user wording.

Inputs: no named parameters. Returns: result

get_projectA

Get project details for one of the authenticated user's projects.

Inputs: project_id (required). Returns: result

get_shared_compute_pricingA

Show the admin-defined unit pricing for shared compute reservations plus the currently unreserved shared pool. Read-only: direct the user to the PlugLayer web app (Compute -> Add Compute -> Buy shared compute) to actually purchase a reservation.

Inputs: no named parameters. Returns: result

get_task_statusB

Check async operation status, progress, result URL, or error.

Inputs: task_id (required). Returns: result

get_user_contextA

Load the caller's stored PlugLayer user context memory. Use this at the start of a session when prior project/app/domain preferences may matter.

Inputs: no named parameters. Returns: result

inspect_local_github_repoA

Check whether the local repo exists, has git initialized, and points at a GitHub origin.

Inputs: repo_path. Returns: result

list_attachable_project_nodesA

List the authenticated project owner's dedicated nodes and whether each is available, already attached here, or attached to another project. Use this when project compute is missing before a deploy.

Inputs: project_id (required). Returns: result

list_database_templatesA

List database-ready marketplace templates. Use this first when the user asks to provision a database through PlugLayer.

Inputs: no named parameters. Returns: result

list_deploymentsD

List apps. Optionally filter by project_id.

Inputs: project_id. Returns: result

list_marketplace_templatesA

List deployable marketplace templates. Use this before deploying a ready-made template through PlugLayer.

Inputs: search, category, test_state, featured_only. Returns: result

list_my_feedbackA

List feedback submitted by the authenticated PlugLayer user.

Inputs: limit. Returns: result

list_nodesA

List compute nodes accessible to the authenticated user. Pass project_id to list only the nodes backing that project (a dedicated node serves one project; shared nodes serve many projects at once).

Inputs: project_id. Returns: result

list_pluglayer_compute_optionsA

List PlugLayer marketplace compute options the user can buy. Use this after estimate_compute() when you want real purchasable machine choices instead of abstract resource units.

Inputs: tags, min_gpu_gb, min_ram_gb, tshirt_size, +2 more. Returns: result

list_project_domainsC

List custom domains for a project and show their verification state.

Inputs: project_id (required). Returns: result

list_projectsB

List the authenticated user's projects.

Inputs: no named parameters. Returns: result

list_registriesA

List registry destinations available to the current user.

Inputs: no named parameters. Returns: result

list_user_databasesA

List the authenticated user's databases, optionally filtered to one project.

Inputs: project_id. Returns: result

redeployA

Redeploy an existing app without changing its current slug. Confirm the exact app name with the user first and pass it here. Default to recreate to minimize temporary live compute usage; use rolling only when the user explicitly prefers lower-downtime rollout behavior.

Inputs: deployment_id (required), confirmed_app_name (required), redeploy_strategy. Returns: result

remove_appA

Remove one of the authenticated user's apps. This deletes the runtime workload and revokes its active routing while marking the app as removed in PlugLayer.

Inputs: app_id (required). Returns: result

remove_databaseB

Remove one of the caller's provisioned databases, including its runtime workload and active routing.

Inputs: database_id (required). Returns: result

remove_projectA

Remove one of the authenticated user's projects. PlugLayer removes the project's apps first, then tears down the project and archives the record for recovery/history.

Inputs: project_id (required). Returns: result

rename_projectA

Rename a PlugLayer project's display name.

This does not change the project's slug, Kubernetes namespace, or existing app URLs.

Inputs: new_name (required), project_id (required). Returns: result

restart_appA

Restart an app by queueing a redeploy. Default to recreate to optimize compute usage; use rolling only when lower downtime matters more than temporary headroom.

Inputs: app_id (required), redeploy_strategy. Returns: result

restart_databaseB

Restart a provisioned database by queueing its redeploy/restart flow.

Inputs: database_id (required). Returns: result

rollbackB

Roll back an app to a previous revision.

Inputs: deployment_id (required), revision. Returns: result

submit_feedbackA

Submit safe, actionable product feedback for the authenticated user.

Use after explicit user requests, or automatically once after an actionable PlugLayer operation failure. Ask before submitting inferred, non-blocking improvement ideas. Never include credentials, environment values, private source, or full logs.

Inputs: title (required), description (required), category, page_url, +6 more. Returns: result

sync_database_env_to_appA

Update one deployed app's env vars using a provisioned database's concrete connection details, then restart the existing app.

Inputs: app_id (required), database_id (required), add_missing_connection_fields. Returns: result

update_app_domainA

Update the app's default pluglayer.io route slug. Use this when the user chooses the built-in subdomain now and may switch to a custom domain later.

Inputs: app_id (required), route_slug (required). Returns: result

update_database_accessA

Update a provisioned database's public TCP IP allowlist. Pass an empty list to allow all IPs again.

Inputs: database_id (required), tcp_allowed_cidrs. Returns: result

update_user_contextB

Update the caller's stored PlugLayer user context memory. Use this carefully for durable preferences, project/app mappings, prior decisions, and user-specific deployment habits.

Inputs: context_patch (required), merge. Returns: result

upload_image_archive_and_deployA

Upload a locally built Docker/OCI image archive to PlugLayer. If the target app already exists in the project, upload to that app first and redeploy it; otherwise create a new app from the mirrored image.

Inputs: name (required), project_id (required), image_archive_path (required), tag, +10 more. Returns: result

upload_image_archive_and_redeploy_appB

Rebuild flow for existing apps: upload a newly built image archive, push it with a new tag, keep the current slug, and redeploy the existing app.

Inputs: app_id (required), image_archive_path (required), tag, registry_id, +2 more. Returns: result

verify_custom_domainA

Verify a custom domain after DNS is added. Pass provider_name and dns_zone so an existing GoDaddy apex record gets actionable www + forwarding recovery guidance.

Inputs: domain_id (required), dns_zone, provider_name. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    C2.7/5.0

    Scored across 70 tools

    Disambiguation2/5

    Many tools are near-duplicates or aliases (e.g., list_projects/get_my_projects, remove_database/delete_database, remove_app/delete_deployment/delete_app, get_app_logs/get_logs, get_my_available_compute/get_my_available_computes). This creates ambiguity about which variant is canonical or whether behavior differs. The project/node/compute/deploy/domain surface has overlapping concepts that require careful reading.

    Naming Consistency3/5

    Most names use verb_noun (list_projects, deploy_image, get_compute_summary), but there are inconsistent patterns: aliases (delete_ vs remove_ vs get_ vs list_), mixed styles (get_apps_by_project vs list_project_domains, get_my_available_compute vs get_my_available_computes), and some verbs like 'check_' 'detect_' 'submit_' are fine but the overall pattern is not uniform.

    Tool Count1/5

    70 tools is excessive for a single MCP server. While the domain (deployments, databases, compute, domains, feedback) is broad, this count overwhelms an agent. Many tools are aliases or minor variants that could be consolidated into parameterized calls. This is far beyond a typical well-scoped server.

    Completeness4/5

    The surface covers core lifecycle operations for projects, apps, databases, compute, domains, and feedback, including status checks and env var management. Minor gaps exist (e.g., no explicit database update besides access restart/remove, no explicit project member management), but the main workflows are covered. Aliases actually help ensure no obvious dead ends for common terms.

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables infrastructure operations including provisioning, configuration, monitoring, compliance auditing, and auto-remediation through natural language, using Terraform and Ansible tools exposed over MCP.
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Cloud infrastructure provisioning via natural language. Enables deploying production-ready infrastructure on AWS, GCP, Azure, or Oracle with a single prompt.
      12
      13 npm
      MIT