Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Os Plan

delimit_os_plan

Create an OS-level execution plan for a target component (deploy, migrate, rotation, rollback) to enable governance gate checks and human approval before any side-effecting execution.

Instructions

Mint an OS-level execution plan against a target component (Pro).

When to use: to draft a structured plan (deploy, migrate, rotation, rollback) that the governance kernel can later inspect via delimit_os_gates and human reviewers can approve before any side-effecting execution. The pattern is plan -> approval check via gates -> separate execution call. When NOT to use: for aggregate OS counts (delimit_os_status), to check gate state on an existing plan (delimit_os_gates), or to actually execute a deploy (delimit_deploy_* / delimit_deploy_build). Also do not use this as an audit-trail surrogate for free-form work; that is delimit_ledger_add territory.

Sibling contrast: delimit_os_gates checks gates on an existing plan; delimit_os_status reports portfolio-wide counts; this is the only OS surface that mints a new plan. Compared to delimit_gov_new_task (governance-classed task), this records an OS-level operation (deploy/migrate/rotation) rather than a policy-scoped task.

Side effects: gated by require_premium — unlicensed callers receive a license payload and no plan is created. On a licensed call, parameters is first coerced (string -> dict via _coerce_dict_arg); a malformed payload short-circuits with an error response. On success, invokes backends.os_bridge.create_plan which writes a new plan record to the OS plan store keyed by a generated plan_id. Result is wrapped via _with_next_steps. No deploy is executed by this call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesTarget component or service. Required.
operationYesOperation to plan (e.g. "deploy", "migrate"). Required.
parametersNoOptional operation parameters as dict or JSON string.
require_approvalNoIf True (default), the plan requires approval before execution.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.7.9
    • changedInput schema / properties / operation / description
      Previous value: -"Operation to plan (e.g. \"deploy\", \"migrate\")."New value: +"Operation to plan (e.g. \"deploy\", \"migrate\"). Required."
    • changedInput schema / properties / parameters / description
      Previous value: -"Operation parameters."New value: +"Optional operation parameters as dict or JSON string."
    • changedInput schema / properties / require_approval / description
      Previous value: -"Whether to require approval before execution."New value: +"If True (default), the plan requires approval before execution."
    • changedInput schema / properties / target / description
      Previous value: -"Target component or service."New value: +"Target component or service. Required."
  2. Changed5 schema fields changedv4.5.5
    • addedInput schema / properties / operation / description
      Added value: +"Operation to plan (e.g. \"deploy\", \"migrate\")."
    • changedInput schema / properties / parameters / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / parameters / description
      Added value: +"Operation parameters."
    • addedInput schema / properties / require_approval / description
      Added value: +"Whether to require approval before execution."
    • addedInput schema / properties / target / description
      Added value: +"Target component or service."
  3. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses substantial behavior beyond annotations: require_premium gating, license-payload responses for unlicensed callers, coercion of parameters from string to dict, malformed-payload error short-circuiting, the underlying backend call backends.os_bridge.create_plan, writing a plan record keyed by generated plan_id, wrapping via _with_next_steps, and the explicit statement that no deploy is executed. This far exceeds the minimal readOnlyHint/destructiveHint annotations.

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?

The description is long but every sentence earns its place: scoping, workflow, exclusions, sibling contrast, side effects, and internal behavior are each in clearly separated sections. The most important identifying sentence is front-loaded, and the structure makes scanning easy despite the volume.

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?

Given an output schema exists, the return-value burden is reduced, yet the description still covers the write path, license gate, error behavior, and the absence of deployment execution. Context signals confirm low structured annotation coverage, so the description fully compensates by giving the agent everything needed to select and safely invoke the tool.

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 schema already documents all four parameters and their defaults. The description adds meaningful extra semantics for `parameters` specifically, explaining string-to-dict coercion and malformed-payload failure behavior. It does not significantly enrich `target`, `operation`, or `require_approval`, but the schema already covers those adequately.

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?

The description opens with a specific verb and resource: 'Mint an OS-level execution plan against a target component (Pro).' It differentiates from siblings by naming delimit_os_gates, delimit_os_status, delimit_deploy_*, delimit_gov_new_task, and delimit_ledger_add, making it unmistakable what this tool does versus alternatives.

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?

There is an explicit 'When to use' paragraph laying out the plan -> gate check -> execute workflow, and an explicit 'When NOT to use' list naming concrete sibling tools. It also provides a sibling-contrast paragraph that clarifies the exact boundaries against related OS and governance tools.

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