Skip to main content
Glama

Create Plan

create_plan

Write down a sequence of tool calls to be run together, later, as one thing. IT DOES NOTHING UNTIL A PERSON CONFIRMS IT -- creating a plan writes nothing to the CRM and starts nothing, and there is no tool that confirms one. USE THIS WHEN THE WORK SHOULD BE REPEATABLE OR CONDITIONAL. A plan can be fired again without being rewritten, and a step can carry a CONDITION on what an earlier step returned -- which is how 'create the contact if the account exists, and a lead if it does not' is said. For work somebody wants done once and now, create the run and dispatch it directly instead; a plan is the heavier answer. EACH STEP is {tool, arguments, title}, exactly the call you would have made, plus an optional when. A step naming a tool you cannot call is refused when the plan is written rather than when it runs. when IS {step, field, op, value}: step is the INDEX of an EARLIER step, field a key of what that step returned, op one of eq, neq, gt, gte, lt, lte, exists, absent. There is no and/or -- one condition per step. A step whose condition does not hold is SKIPPED and the plan carries on; it is not a failure. THE COMMONEST GUARD reads count_crm_records, which returns matched -- so {step: 0, field: 'matched', op: 'gt', value: 0} means 'if that search found anything'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoWhat a person calls this plan. Required unless request_text is given; a plan fired repeatedly wants one.
stepsYesThe calls, in order.
stagedNoA staged plan: its runs stage their results and write nothing, and the firing writes every record once when the last run finishes, skipping a field the CRM changed since it was staged. Its steps may be the enrichment, verification, job change and assignment runs, and dispatch_run.
request_textNoWhat was asked for, in the person's own words. This is what a reviewer reads to answer why a queued change is in front of them.
connection_idYesThe CRM connection. Call list_crm_connections first.
interpretationNoHow you read the request, in one or two sentences.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only minimal annotations, the description discloses many behavioral traits: no CRM writes or starts until confirmation, refusal timing for unsupported tools, condition-skipping behavior, no and/or support, and the common count_crm_records guard pattern. This is unusually rich behavioral context.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and no-op clarification, then proceeds logically through usage, step shape, and conditions. It is long and uses emphatic all-caps phrasing, but almost every sentence carries useful instruction for this complex tool.

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?

Covers the tool's purpose, usage conditions, and step/condition semantics thoroughly. However, with no output schema, it does not state what create_plan returns, and staged-plan behavior is only documented in the input schema rather than the main description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it defines each step as {tool, arguments, title} plus optional when, explains that step refers to an earlier index, lists all operators, clarifies skip-not-failure semantics, and gives a concrete condition example.

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: writing down a sequence of tool calls as a reusable plan. It explicitly distinguishes plans from runs and from one-off dispatch, and clearly says the plan does nothing until confirmed.

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?

Provides explicit usage context: use for repeatable or conditional work, and create a run and dispatch directly for one-off work. However, the claim that 'there is no tool that confirms one' leaves the execution path unclear and appears to conflict with the sibling tool fire_plan.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.