AI Worlds CLI Knowledge

Plan Model-Aware CLI Work

worlds_plan_cli_work

Read-onlyIdempotent

Create a read-only, dependency-aware work plan across Claude Code, Codex, and Grok Build. It selects a concrete dated-catalog model and supported native effort for each workstream, while keeping CLI fit, orchestration, permissions, handoff context, and verification separate. Routing is continuity-first and does not claim benchmark superiority, launch another CLI, or enable permission bypass. Clients that support MCP prompts can enter the same workflow through the worlds_plan_model_aware_work prompt (or worlds_consult_hard_problem for one hard problem).

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": {
      "task": "<task>",
      "current_cli": "<current_cli>"
    },
    "name": "worlds_plan_cli_work"
  }
}

Input Schema

Name	Required	Description	Default
`task`	Yes
`strategy`	No		continuity-first
`current_cli`	Yes	CLI holding the active conversation; continuity is preferred unless switching has a concrete benefit.
`workstreams`	No
`available_clis`	No
`risk_tolerance`	No		low
`orchestration_mode`	No		none
`max_parallel_tracks`	No
`execution_environment`	No		local-workspace
`require_independent_review`	No

Output Schema

Name	Required	Description	Default
`task`	Yes
`safety`	Yes
`handoff`	Yes
`evidence`	Yes
`strategy`	Yes
`assignments`	Yes
`current_cli`	Yes
`routing_basis`	Yes
`uncertainties`	Yes
`available_clis`	Yes
`planner_version`	Yes
`routing_principles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 2, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description nonetheless adds real behavior: routing is continuity-first, it will not claim benchmark superiority, will not launch another CLI, and will not enable permission bypass — exactly the constraints an agent needs before relying on the plan.

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?

Three front-loaded sentences: artifact first, then the decomposition it performs, then the routing guarantees and prompt alternative. Dense but purposeful; minor jargon ('dated-catalog model', 'native effort') costs a little clarity without padding.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the behavioral guarantees are well covered. However, for a 10-parameter planning tool with 10% schema description coverage, the description leaves the agent guessing about the knobs that shape the plan, so it is only adequate overall.

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 10% across 10 parameters, so the description carries the burden — yet it explains none of them beyond a nod to 'continuity-first' routing and 'concrete dated-catalog model and supported native effort'. Strategy, risk_tolerance, workstreams, max_parallel_tracks, orchestration_mode, execution_environment and require_independent_review get no meaning added, leaving half the inputs opaque.

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?

States a specific verb and artifact ('Create a read-only, dependency-aware work plan') plus the scope ('across Claude Code, Codex, and Grok Build') and what the plan separates (CLI fit, orchestration, permissions, handoff, verification). That is enough to distinguish it from the get/list/search/compare siblings, though no sibling is named as a contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers entry-point routing (MCP-prompt clients can use `worlds_plan_model_aware_work`, or `worlds_consult_hard_problem` for a single hard problem), which implies when to use it. But it never contrasts with the actual sibling tools such as worlds_compare_cli_workflows or worlds_advise_hard_problem, and the prompt name it cites does not match any listed sibling, so an agent must infer the boundary.

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

All AI Worlds CLI Knowledge tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.