Sergio by Serviche

Mark several tasks done

complete_tasks_bulk

Idempotent

Marks up to 200 tasks done at once, as the Tasks page's selection bar does; each closes exactly as its own check box would. Kinds that close only from their own screen (lead follow-ups, flow steps, questions, staff check-ins, rules) are refused per task and reported in results. action "reopen" is the Undo. Pass the same idempotency_key when retrying; a repeat returns the first answer and moves nothing again.

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": {
      "ids": "<ids>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "complete_tasks_bulk"
  }
}

Input Schema

Name	Required	Description	Default
`ids`	Yes
`action`	No		done
`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

A4.5/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the operation is non-atomic, with certain task kinds (lead follow-ups, flow steps, questions, staff check-ins, rules) refused individually and reported in results, and retries with the same key return the first answer without moving anything again. That partial-failure and replay semantics are exactly what an agent needs before committing a bulk mutation.

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 tightly packed sentences, front-loaded with scope, then failure behavior, then idempotency. The parenthetical list of refused kinds is dense but earns its place; nothing is padding, though the sentence structure is somewhat compressed for a first read.

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?

Covers scope, partial-failure, undo, and retry semantics for a mutation tool with no output schema. The main gap is the shape of 'results' — an agent is told refusals are reported but not in what form, which matters since there is no output schema to fall back on.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema description coverage, the description carries weight and does so for all three params: it explains the 200 cap on ids, that action "reopen" is the Undo, and that the same idempotency_key must be reused on retry. It does not explain the id format or key pattern, but those are already constrained in the schema.

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

Purpose5/5

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

States a specific verb and resource with explicit scope: 'Marks up to 200 tasks done at once.' The phrase 'as the Tasks page's selection bar does' plus 'each closes exactly as its own check box would' distinguishes it from the single-task siblings complete_task and reopen_task without ambiguity.

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

Usage Guidelines4/5

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

Gives clear operating context: bulk-done by default, action "reopen" as the Undo, and the kinds that will be refused per task. It does not explicitly say 'use complete_task for a single task' or name the alternative tool, but the scope language makes the routing obvious.

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?