Skip to main content
Glama
Sign In
Edgegap MCP Server

Edgegap MCP Server

Official
by edgegap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Turn an application on or off

edgegap_update_app
Idempotent

Set whether an application accepts new deployments. Turning it off stops new deployments of every version under it; running deployments keep running. Use it to pause an application without deleting anything.

Instructions

Set whether an application accepts new deployments. Turning it off stops new deployments of every version under it; running deployments keep running. Use it to pause an application without deleting anything.

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": {
      "application": "<application>",
      "is_active": "<is_active>"
    },
    "name": "edgegap_update_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNoShow the exact request (method, host, path, body) with secrets masked, and send nothing. Local checks still run. Use it to confirm a billable or destructive call before making it.
is_activeYesfalse blocks new deployments; true allows them again.
applicationYesApplication name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare idempotent, non-destructive, open-world, but they cannot express effect scope. The description supplies exactly that: turning off blocks new deployments of every version under the application while running deployments keep running, and nothing is deleted. That is the key behavioral fact an agent needs before flipping the flag.

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?

Three short sentences, front-loaded with the core action, then the blast radius, then the use case. No filler and no repetition of the title.

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 single-flag toggle with full schema coverage, annotations, and no output schema, this covers what an agent needs. The only omission is the dry_run verification path, which the schema already explains, so the gap is minor.

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 description coverage is 100% and is_active is already documented as 'false blocks new deployments; true allows them again', which the description largely restates. The dry_run parameter is fully documented in the schema but unmentioned here, so the description adds little beyond structured fields. 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 action (set whether an application accepts new deployments) on a specific resource (application), not the version or deployment level. That scoping distinguishes it from edgegap_update_app_version and the deployment siblings without needing to name them.

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?

"Use it to pause an application without deleting anything" gives a clear use case and implicitly rules out deletion as the path to stopping deployments. It stops short of naming an explicit alternative or when-not-to-use case, but the context is unambiguous.

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

Deploy Server

Other Tools