Sergio by Serviche

Move a task's due time

snooze_task

Idempotent

Moves a task's due time (ISO 8601 with offset). A flow-step task shifts its later steps by the same gap, as in the app. Pass the same idempotency_key when retrying; a repeat returns the task, reports what the original call applied, and changes nothing if the task changed since.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "due_date": "<due_date>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "snooze_task"
  }
}

Input Schema

Name	Required	Description
`task_id`	Yes
`due_date`	Yes
`idempotency_key`	Yes	Your id for this operation (8-128 of A-Z a-z 0-9 . _ : -). Reuse it on every retry of the same operation; use a new one for a new operation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description discloses two non-obvious behaviors: a flow-step task cascades the same gap to its later steps, and a repeated idempotency_key returns the task, reports what the original call applied, and makes no change if the task changed since. The cascade side effect and the stale-change no-op are exactly the traits an agent could not derive from structured fields.

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?

Three tight sentences, front-loaded with the core action before the cascade caveat and the retry contract. The phrase 'as in the app' is the only soft wording, conveying parity with UI behavior in few words.

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

Completeness4/5

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

No output schema exists, yet the description covers what a normal call returns implicitly (the task) and what a repeated call returns explicitly. Gaps remain around permissions, past-date handling, and errors, but for a three-parameter reschedule tool the essentials are present.

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 coverage is only 33%, with just idempotency_key documented in the schema, so the description must compensate. It adds real meaning to due_date (ISO 8601 with offset) and reinforces retry semantics for idempotency_key, but says nothing about task_id beyond the obvious, so the compensation is partial.

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?

The description states a specific verb and resource: it moves a task's due time, rather than editing arbitrary task fields. That scopes it against siblings such as update_task, skip_task, complete_task and reopen_task, though it never names them explicitly and leaves the agent to infer the boundary.

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?

Usage is implied by the narrow scope (use this to reschedule, not to edit other task fields), and the retry condition is spelled out clearly. There is no explicit when-not guidance, and no sibling is named as the alternative for editing other task attributes.

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

All Sergio by Serviche tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?