workspace_resumeResumes all paused items in a workspace for the owner. Returns what was resumed and what was skipped, with why.
Use this when the workspace owner wants to start again everything they paused in a workspace. Owner only. Returns what was resumed and what was skipped, with why.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | Workspace ID (see workspace_list) |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the mutation profile (readOnly=false, idempotent=true, destructive=false), and the description adds value beyond them: the owner-only authorization requirement and the partial-success behavior ("what was resumed and what was skipped, with why"). That skipped-with-reason disclosure is genuinely useful for an agent interpreting results, though it doesn't say whether resuming triggers billing or restarts services.
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?
Two tight sentences, front-loaded with the usage trigger and constraint, followed by return behavior. Every clause earns its place with no filler.
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?
With no output schema, the description usefully summarizes the return shape (resumed vs skipped, with reasons), and annotations already cover idempotency and safety. The main residual gap is whether resume has side effects like billing resumption or downstream service restarts, which the description doesn't address.
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?
Only one parameter, and schema coverage is 100% with the schema pointing to workspace_list for how to obtain the ID. The description adds no additional meaning about workspaceId, so the baseline 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?
States a specific verb and resource (resume a workspace) and clarifies scope with "everything they paused in a workspace", which separates it from narrower siblings like project_resume and service_resume. It stops short of naming those siblings explicitly, so the differentiation is implied rather than stated.
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?
"Use this when the workspace owner wants to start again everything they paused" gives a clear triggering condition, and "Owner only" acts as a prerequisite/exclusion. No alternative tool (project_resume, service_resume) is named for the narrower cases, so routing is partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.