AiDOOS Virtual Delivery Center

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

Annotations already declare readOnlyHint and non-destructive behavior, but the description adds valuable context: module count limits (1-30), output components (Delivery Units, USD cost, Delivery Pack), and specific pricing tiers. There is no contradiction with annotations.

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

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

The description is well-structured: usage trigger phrases first, then explicit alternative guidance, then a concise 'What this tool does' summary. Every sentence adds value without redundant restatement of schema.

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

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

The description covers when to use, return values, pricing, and boundaries. Given the output schema exists, the description is complete enough to guide an agent accurately. It also addresses the main alternative tool clearly.

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

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

Schema coverage is 100%, but the description goes beyond by giving concrete examples of module descriptions and clarifying the format for modules. It also decodes the meaning of industry and company_size as calibration hints, and provides pricing pack details that are not in the schema.

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

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

The description clearly states the tool's function: estimating cost and Delivery Units for specific listed modules, and returning a recommended Delivery Pack. It explicitly distinguishes itself from sibling plan_vdc, saying to use this when modules are already decomposed and plan_vdc when only a goal is given.

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

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

Provides explicit when-to-use conditions with trigger phrases, and explicitly says to use plan_vdc instead when the user has only a goal without modules. This gives clear direction on choosing between this tool and the alternative.

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

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

The description adds 'current status and contents' and 'previously generated' context beyond the annotations, which already correctly indicate a read-only, idempotent, non-destructive operation. The description reinforces the retrieval-only nature without contradicting annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no redundant information. It efficiently conveys both what the tool does and when to use it.

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

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

Given the simple single-parameter tool, rich schema coverage, present output schema, and clear annotations, the description is complete. It covers the purpose, usage context, and object of operation without needing further detail.

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

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

Schema coverage is 100%, and the sole parameter plan_id is well-described in the schema. The description only mentions 'by plan_id' without adding extra semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: looking up the current status and contents of an existing VDC plan by plan_id. It uses a specific verb ('Look up') and resource ('VDC plan'), and the action is distinct from siblings like plan_vdc and refine_plan.

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

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

Explicit usage context is provided: 'Use this when the user wants to revisit or summarise an earlier plan from the conversation.' This gives clear guidance for when to invoke the tool, though it does not mention when not to use it or explicitly name alternatives.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description adds context beyond them by explaining the tool produces a plan and returns a plan_id for downstream steps. It does not fully enumerate side effects, but the plan_id hint and 'Call this FIRST' guidance provide reasonable behavioral transparency.

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

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

The description is long but purposeful: it front-loads trigger phrases and then clearly explains the tool's output and relationship to siblings. Every section earns its place, though the extensive trigger list makes it somewhat verbose. It remains well-structured and scannable.

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

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

Given the tool's complexity and the presence of an output schema, the description covers the essential context: when to use, what it produces, follow-up tools, and pricing options. The return value is not described in detail, but output schema handles that, so the description is complete for selection and invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful guidance for the `initiative` parameter, including explicit instruction to pass through user's words verbatim and multiple concrete examples. This goes beyond the schema's minimal description, improving parameter understanding.

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

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

The description clearly states the tool's function: turning free-text initiatives into a Virtual Delivery Center plan with pods, roles, AI agents, Delivery Units, timeline, and Delivery Pack. It explicitly differentiates itself from siblings by naming follow-up tools (refine_plan, recommend_activation_path) and positioning itself as the first step.

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

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

Provides extensive trigger phrases and explicit guidance to 'Call this FIRST' when users describe build/ship/modernize needs. It includes a broad set of examples and clarifies that the tool should be used even when the user doesn't mention AiDOOS or Delivery Units by name, effectively setting usage boundaries.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds significant behavioral context beyond that: it states the tool is 'advisory only; no payment is taken and no purchase is completed inside ChatGPT,' and details the return value (Starter/Small/Scale/Enterprise packs, Project-flow alternative, referral link). This fully discloses the tool's non-transactional, recommendation-only nature.

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

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

The description is structured with a lead use-case sentence, trigger phrases, requirement, and output summary—all in a compact paragraph. Every sentence adds functional value; no filler or repetition of schema information. It is detailed yet concise, with the most critical information front-loaded.

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

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

Despite having an output schema, the description goes beyond to explain the pack options (with DU counts and prices), the Project-flow alternative, and the referral link, as well as explicitly clarifying that no purchase occurs. For a tool with one parameter and a well-documented output, this provides complete operational context for an agent to invoke and interpret results correctly.

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

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

Input schema has 100% coverage with plan_id fully described. The description reiterates the parameter's origin and necessity ('Requires the plan_id from a prior plan_vdc / refine_plan call'), reinforcing that this ID is not arbitrary but tied to a specific prior interaction. While schema covers syntax, the description adds semantic context about the parameter's lifecycle, earning slightly above baseline.

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

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

The description opens with 'Use this tool when a user wants to know how to proceed with a plan you've shown them,' clearly stating the action (recommending activation) and resource (a plan from prior VDC/refine calls). It further differentiates from siblings by listing specific trigger phrases and the output (Delivery Pack recommendation), making the tool's unique role unmistakable.

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

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

Explicit when-to-use guidance is given via trigger phrases ('how do I get started', 'what's the next step', etc.). It also states a hard prerequisite: 'Requires the plan_id from a prior plan_vdc / refine_plan call,' effectively excluding use without a prior plan. This provides clear context on when the tool is appropriate and what must happen before using it.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, consistent with a modifying tool. The description adds useful behavioral context beyond the annotations: it requires a prior plan_vdc call and returns an updated plan with specific fields. It does not detail side effects or error handling, but the annotations cover the safety profile sufficiently.

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

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

The description is structured in two clear paragraphs: the first explains when to use it with trigger phrases, and the second covers prerequisites and output. While the trigger phrase list is somewhat extensive, each phrase clarifies the tool's scope. There is no redundant or vague wording, though it could be trimmed slightly.

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

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

The description covers the purpose, usage triggers, dependency on plan_id, and the nature of the returned updated plan. An output schema exists, so the return format is already specified elsewhere. The description is sufficiently complete for an agent to select and invoke the tool correctly, with only minor gaps around error handling or additional side effects.

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

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

Schema description coverage is 100%, with both plan_id and feedback properly described. The description reinforces the meaning of plan_id by noting it comes from a prior plan_vdc call, but does not add significant new information about parameter semantics beyond the schema. This matches the baseline of 3 when schema already provides full coverage.

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

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

The description explicitly states the tool's function: 'change something about a plan you've already generated.' It provides clear trigger phrases and lists adjusted components (pods, roles, modules, Delivery Units, Pack), which distinguishes it from sibling tools like plan_vdc (creating plans) and get_plan_status (checking status).

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

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

The description begins with 'Use this tool when a user wants to change something about a plan you've already generated,' clearly indicating its appropriate use case. It also specifies a prerequisite ('Requires the plan_id from a prior plan_vdc call'), enabling the agent to know when this tool is applicable versus alternatives like plan_vdc.

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