edit_scheduledReschedule a social media post by updating its scheduled date and timezone, using the job ID to apply the change.
Reschedule a post: change date and/or timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| timezone | No | ||
| scheduledDate | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | No |
Changes observed during successful MCP inspections.
v0.11.1Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions adds modest context beyond the destructiveHint annotation by saying exactly what changes (date and/or timezone). It does not describe side effects, whether existing values are overwritten, or how missing fields are handled, but the annotation already signals mutation.
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?
A single, front-loaded sentence states the action and the scope of the change with no filler. It is appropriately sized for a simple rescheduling tool.
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 tool is simple, has an output schema, and has annotations that signal mutation, which reduces the description's burden. Still, the required jobId is not explained and no date/timezone format guidance is given, so an agent has to infer some important invocation details.
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?
The input schema has 0% description coverage, so the description must carry parameter meaning. It explains timezone and scheduledDate, but does not clarify jobId, which is the only required parameter, nor does it give format or constraint details for the date/timezone strings.
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 states a specific action ('Reschedule') and resource ('a post'), and narrows the scope to changing date and/or timezone. This clearly distinguishes it from siblings like cancel_scheduled and list_scheduled, even without naming them.
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 phrase 'Reschedule a post' implies when to use the tool: when an agent wants to change an existing scheduled post's date or timezone. However, it does not explicitly contrast with alternatives like cancel_scheduled or state any prerequisites, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.