manage_sdk_project_runtime

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

With no annotations, the description carries the behavioral disclosure burden. It does well by disclosing preview-only status in compact Backbone and sovereign progressive profiles, unavailability of resume/run-next, read-only checkpoint behavior, and the generic resume surface's refusal of recovery attestations and external-operation replay. It does not mention authentication, side effects, or rate limits, but the operation constraints are meaningfully transparent.

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 compact and front-loaded with the core purpose and the operation list. The subsequent sentences add essential operational constraints without padding. Some terminology is dense and jargon-heavy (e.g., 'revisioned JSON checkpoints', 'trustworthy preview binding'), but every sentence contributes information.

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—11 parameters, multiple operations, profile-specific restrictions, and an output schema—the description is incomplete. It thoroughly covers operation semantics and availability conditions, but the absence of parameter-level guidance for nine parameters means an agent cannot reliably construct valid calls for event ingestion, scheduling, or approval flows without external knowledge.

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 0%, so the description must compensate. It explains the possible values of the operation parameter and touches on project_spec via hosted vs local spec handling. But it leaves parameters like event, inputs, run_ref, resume_at, worker_ref, preview_only, workflow_key, approval_refs, and connector_account_refs without any semantic guidance, making correct invocation difficult.

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 starts, pauses/resumes, schedules, dispatches, or inspects a durable SDK workflow, and it enumerates the supported operations. It is specific about the resource and verbs, though it does not explicitly distinguish these capabilities from sibling workflow tools like run_sdk_project_workflow or dynamic_workflow_start.

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 gives clear usage context: hosted specs use a tenant/company/project control plane, local specs use revisioned JSON checkpoints, and certain operations are preview-only or unavailable in specific profiles. It also points one transition to the hosted connector journal authority. However, it never explicitly tells an agent when to prefer this tool over sibling workflow-management tools.

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