Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Edit a to-do

connections_todo_update
DestructiveIdempotent

Use this when the member asks to rename, reword, move or clear the due date of, add details to, relabel, or change whether a to-do is done. Pass the id from connections_todo_list and any of title, body, due_at, labels, done. Only what you pass is changed; due_at: null clears the deadline; labels replaces the whole label set and body replaces the details. Nothing is deleted (connections_todo_delete does that).

Input Schema

NameRequiredDescriptionDefault
idYesThe to-do id from connections_todo_list.
bodyNoThe to-do's details (what, where, who, links); replaces the current details.
doneNotrue = mark complete; false = reopen. Leave out to keep it as is.
titleNoThe new one-line title.
due_atNoNew deadline: a day (2026-11-06), or a date-time with the member's UTC offset (2026-11-06T17:00:00-06:00); null clears it. Leave out to keep it.
labelsNoReplaces the whole label set (an empty array removes all labels). Leave out to keep them.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
projectNoWorkspace to run this call in (id or name).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / due_at / description
      Previous value: -"Deadline, unix seconds; null clears the deadline. Leave out to keep it."New value: +"New deadline: a day (2026-11-06), or a date-time with the member's UTC offset (2026-11-06T17:00:00-06:00); null clears it. Leave out to keep it."
    • addedInput schema / properties / due_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}(T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?)?$"
    • changedInput schema / properties / due_at / type
      Previous value: -"integer"New value: +"string"
  2. Changed2 schema fields changed
    • addedInput schema / properties / due_at / nullable
      Added value: +true
    • changedInput schema / properties / due_at / type
      Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
  3. Changed3 schema fields changed
    • addedInput schema / properties / body
      Added value: +{
+  "description": "The to-do's details (what, where, who, links); replaces the current details.",
+  "type": "string"
+}
    • addedInput schema / properties / due_at
      Added value: +{
+  "description": "Deadline, unix seconds; null clears the deadline. Leave out to keep it.",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedInput schema / properties / labels
      Added value: +{
+  "description": "Replaces the whole label set (an empty array removes all labels). Leave out to keep them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / person
      Added value: +{
+  "description": "Linked person to run this call as (first name). Omit to run as the connection's holder.",
+  "type": "string"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  6. Added

TDQS

A4.3/5.0
Behavior4/5

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

Without relying on annotations, it discloses the patch semantics (partial update), the replace-not-merge behavior for labels and body, and the explicit reassurance that nothing is deleted. This aligns with destructiveHint=true (field overwrite) and idempotentHint=true rather than contradicting them, though it does not mention permissions, auth context, or whether a replaced body is recoverable.

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-loaded with the trigger condition, then parameter notes, then the deletion boundary — a sensible order with no filler. The first sentence is a long comma-chained list that is slightly harder to parse than it needs to be, but every clause carries information.

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?

For a mutation tool with full schema coverage, no output schema, and annotations covering safety hints, the description supplies the missing semantic layer (partial update, replacement, clearing). It stops short of explaining the person/project run-as scoping or what a successful response looks like, but neither is essential to calling it correctly.

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?

Schema coverage is already 100%, so baseline is 3; the description adds genuine meaning beyond it by stating that only passed fields change, that due_at: null clears the deadline, and that labels and body are full replacements rather than merges. It does not touch the person/project scoping parameters, but those are clearly documented 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 set (rename, reword, move/clear due date, add details, relabel, toggle done) against a named resource (a to-do), and explicitly routes deletion to connections_todo_delete. An agent can distinguish this from connections_todo_delete and connections_todo_add without opening a schema.

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?

The opening 'Use this when the member asks to...' enumerates concrete trigger phrasings, which is strong when-to-use guidance, and deletion is explicitly excluded. However it never mentions the sibling connections_todo_done, even though marking done is listed here as a supported use case, leaving ambiguity about which of the two tools to pick for that action.

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

All Connections toolsInspect
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