Skip to main content
Glama
ShermanGu
by ShermanGu

continue_action

Resume pending personnel, mail, or time confirmations, or submit weekly report changes using a resume token and selections.

Instructions

恢复人员/邮件/时间确认,或提交 weekly_report 周报修改。

周报 selections 仅支持 changes 和可选 subject;changes 每项使用 weekly_report 返回的短 id/text,例如 {"id":"s3","text":"完成接口联调"}。weekly_report 返回的 subject 已是 Server 自动顺延后的默认草稿主题;通常无需再次提交 subject。

Input Schema

NameRequiredDescriptionDefault
selectionsYes
resume_tokenYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the subject returned by weekly_report is a server auto-advanced default and usually need not be resubmitted, which is real behavioral context. But it says nothing about confirmation types, permissions, or the consequences of submitting the resume path.

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

Conciseness4/5

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

Front-loads the two purposes, then follows with the weekly_report format detail and the subject note. Content is dense but each sentence carries information; minor redundancy in re-explaining the subject.

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

Completeness3/5

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

An output schema exists so return values need not be described. For a 2-param tool with a nested object at 0% schema coverage, the weekly_report selections are well covered but resume_token and the confirmation-type selections are left undefined, so an agent cannot fully call the resume path with confidence.

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

Parameters3/5

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 does document the selections structure in detail (changes with short id/text, optional subject, worked example), but resume_token — the central parameter for a resume tool — is never explained beyond the implied 'resume' sense.

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

Purpose4/5

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

States a specific dual purpose: resume people/mail/time confirmations, or submit weekly_report modifications. The verb+resource is clear and it distinguishes the weekly_report path from the sibling of the same name. It stops short of explaining how the two modes relate.

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

Usage Guidelines3/5

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

Gives concrete guidance for the weekly_report path (selections supports only changes and optional subject, with an id/text example). However it offers no when-to-use guidance for the resume path — it never says how a resume_token arises or what condition should lead an agent here instead of a sibling.

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