execute_plan
Use this when a data center question spans several topics: one-call planner over megawatts and power density, grid headroom and power availability, interconnection queues, substations and transmission, site selection and buildable capacity, colocation and wholesale data-center markets, AI/GPU com...
This record as markdown: /tools/cloud-dchub-mcp-server/execute-plan.md
What execute_plan does on Mcp Server
AI agents invoke execute_plan to trigger actions in Mcp Server. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
iso | string | — | ISO/RTO code to pin geography, e.g. "PJM", "ERCOT". |
lat | number | — | Latitude for a specific site. |
lon | number | — | Longitude for a specific site. |
state | string | — | US state code, e.g. "VA". |
cohort | object | — | Optional experiment tag for adoption/retention measurement, e.g. "cohort.front_door". Has NO effect on routing, planning, geography or results — it is recorded |
intent | string | Yes | The user's infrastructure question, passed through UNCHANGED. Examples: "rank markets for a 200 MW AI campus" · "evaluate 100 MW power headroom for a GPU traini |
market | string | — | Metro slug or name to pin the analysis to, e.g. "ashburn". Beats any market the planner would mint. |
context | object | — | Optional structured hints AND step-arg overrides: {lat, lon, iso, market, capacity_mw, candidate_id, state, since} — user-supplied values beat minted ones. The |
max_steps | object | — | Max plan steps to execute, 1-8 (default 6) |
max_fanout | object | — | Max per-finalist fan-out calls for one step, 1-3 (default 2) |
capacity_mw | number | — | Target capacity in MW, e.g. 100. |
Parameters from the server's own tool schema.
Why execute_plan is rated High
Orchestrates multi-topic analysis and planning decisions across critical infrastructure and business transactions.
From the tool's definition planner over megawatts, power availability, interconnection queues, site selection, M&A and deals
Risk signalsHigh parameter count (11 properties) · Bulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs execute_plan safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Mcp Server, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For execute_plan, this is the rule to start with:
execute_plan stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Mcp Server, apply this rule, and every execute_plan call is checked against it from then on.
Questions about execute_plan
Use this when a data center question spans several topics: one-call planner over megawatts and power density, grid headroom and power availability, interconnection queues, substations and transmission, site selection and buildable capacity, colocation and wholesale data-center markets, AI/GPU compute campuses, fiber routes, diversity and latency, PPAs and energy pricing, tax incentives and permitting, water and climate risk, data-center M&A and deals, power generation, gas and energy infrastructure. Recommended entry for a question that spans more than one of those. Pass the user's question as intent. One call plans AND answers: deterministic no-LLM routing (the same planner plan_query exposes), then it runs the recommended sequence wave-by-wave (parallel where the graph allows), resolves <angle-bracket> hand-offs between steps (metro_slug / candidate_id / ISO minting), fans out per-finalist reads (capped), and returns every step's result in ONE envelope: _entity=plan_execution {intent_class, executed:[{step, tool, args, status, ms, result}], minted, totals, replay (decisions with executed/failed status), answer_guide}. It is categorised as a Execute tool in the Mcp Server MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
execute_plan accepts 11 parameters: iso, lat, lon, state, cohort, intent, market, context, max_steps, max_fanout, capacity_mw. Required: intent. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Server MCP server in PolicyLayer and add a rule for execute_plan: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Server. Nothing to install.
execute_plan is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the execute_plan rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for execute_plan. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
execute_plan is provided by the Mcp Server MCP server (https://dchub.cloud/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Mcp Server, and thousands of servers like it.
Across the catalogue