plan_query

START HERE — the orchestration FRONT DOOR. For any multi-step DC Hub question, call plan_query FIRST, then execute the plan it returns instead of guessing which of the 79 tools to chain. Turns a natural-language intent into an ordered tool plan BEFORE burning calls. Deterministic keyword routing over the tool registry — no LLM, no network, same intent always returns the same plan (free). Also returns a versioned, self-contained replay object (schema_version 1): planner_version, decisions:[{id, step, kind, status, decision, rationale, decision_confidence, depends_on}], rejected:[{id, tool, reason}], execution_graph:{waves, parallel_groups}, and a compatibility contract — an auditable, machine-readable plan you can log, diff across versions, and hand to a human for review. Returns _entity=query_plan: {best_tool, intent_confidence + workflow_confidence (dual 0-1: question-read vs executability), reason, planner_rationale, recommended_sequence:[{step, tool, depends_on, estimated_calls, why, args_hint}], execution_waves (steps grouped into concurrency waves — run a wave's steps in parallel), execution_strategy.parallel_groups (the same waves as explicit TOOL-NAME arrays), execution_estimate {estimated_calls, estimated_latency_ms, parallelizable} (deterministic static-tier preview), parallelizable, estimated_calls (plan total), alternatives (each with when + rejected_because), coverage_notes, matched_classes} — the sequences mirror the shipped recipes (market_selection, grid_and_queue, water_risk, whats_changed, site_analysis, hyperscaler_activity) plus fiber/price/facility-search routes, including the zero-drift candidate_id chaining contract where a plan crosses get_refined_queue → analyze_site/rank_sites. args_hint values in <angle brackets> come from the named earlier step — substitute them, never invent them. Pass structured hints via context (lat/lon, iso, market, capacity_mw, candidate_id, state, since) to sharpen the plan. Try: plan_query intent="rank markets for a 200MW AI campus". Use FIRST for multi-step questions when you are unsure which tools to chain; for a family-level browse use discover_tools; for a one-call server-side ANSWER (not a plan) use get_dchub_recommendation. This tool plans — it never executes; tools/list stays canonical for schemas. It is categorised as a Write tool in the Mcp Server MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

plan_query accepts 2 parameters: intent, context. 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 plan_query: 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.

plan_query is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the plan_query 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 plan_query. 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.

plan_query 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.