CPG-Radio

Overview Schema Source Related Servers Discussions Admin

plan_session

Initialize a planning session: create a goal node, register the full task graph, resolve dependency indices, generate impact predictions, and confirm constraints as facts before task execution.

Instructions

Initialise a planning session. Creates a GOAL node, registers the full task graph, resolves dependency indices, creates IMPACT predictions, and converts constraints to confirmed FACT nodes. Call once per session before executing tasks.

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": {
      "goal": "<goal>",
      "tasks": "<tasks>"
    },
    "name": "plan_session"
  }
}

Input Schema

Name	Required	Description	Default
`goal`	Yes
`risks`	No
`tasks`	Yes
`budget`	No
`agent_id`	No	Binds the caller's agent identity to this connection, as join_session does.
`confidence`	No		medium
`assumptions`	No
`constraints`	No
`archive_previous`	No	Archive this connection's previous session. Crews pass false.
`decision_context`	No
`success_criteria`	No
`verification_plan`	No

Output Schema

Name	Required	Description	Default
`tips`	No
`task_ids`	Yes
`session_id`	Yes
`binding_token`	No
`dependency_order`	Yes
`impact_predictions`	Yes
`constraint_fact_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 10, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does reveal the main side effects—creating nodes, registering a graph, resolving dependencies, converting constraints to facts—so an agent knows it is making a persistent planning state. However, it fails to mention the destructive default of archiving previous session (via the archive_previous parameter, default true), and does not mention permissions, reversibility, or rate limits, which are important for a tool of this complexity.

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?

Two sentences, 34 words total, are densely packed with meaningful information. It starts with the primary action, then lists the specific effects, and closes the precise usage guidance. There is no filler, no redundant restatement, and every sentence contributes to the agent's understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (12 parameters, many nested object types, low schema coverage), this description is insufficient. It does not explain how to structure or populate the budget, risk, assumption, success_criteria, or verification_plan inputs. Even though an output schema exists, input semantics are not fully covered. The agent cannot infer the intended content of the many nested objects from the description alone.

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

Parameters2/5

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

Schema description coverage is only 17% (only agent_id and archive_previous have descriptions in the schema). The tool description explains a few core parameters—goal, tasks (through 'registers the full task graph'), constraints ('converts constraints to FACT nodes'), and dependencies ('resolves dependency indices')—but it leaves many other parameters unexplained: risks, budget, assumptions, decision_context, success_criteria, verification_plan. The description does not compensate adequately for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb ('Initialise') and resource ('planning session'), then lists concrete actions it performs: creating a GOAL node, registering the task graph, resolving dependencies, creating impact predictions, and converting constraints to FACT nodes. This clearly conveys what the tool does and differentiates it from a generic 'start' tool, though it does not explicitly compare itself to any sibling (e.g., start_workflow).

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?

The description gives an explicit usage instruction: 'Call once per session before executing tasks.' This tells the agent exactly when to invoke the tool and what to do before it, providing clear context. However, it does not mention any alternatives or exclusions (e.g., 'use replan instead of this for replanning'), so it stops short of a full 5.

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

Deploy Server