Skip to main content
Glama

Move Basecamp Todo List

basecamp_move_todolist
Idempotent

Move a todo list to a new position within a Basecamp project. Choose placement as top, bottom, before, or after, with relative ID for before/after.

Instructions

Move a todo list to a different place among the todo lists of its project. Get the todo list IDs from basecamp_get_todoset. To move a group (section), use basecamp_move_todolist_group.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
placementYesWhere to put the item. 'before' and 'after' need relative_to_id.
todolist_idYesBasecamp resource identifier
relative_to_idNoID of the item to put this item before or after. Use it only with placement 'before' or 'after'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare the key traits: idempotentHint=true, destructiveHint=false, openWorldHint=true, readOnlyHint=false, so the mutation/idempotency profile is covered structurally. The description adds the project-scoped placement framing but says nothing about permissions, side effects on ordering of other lists, or the response. With annotations carrying the load, a 3 is appropriate.

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

Conciseness5/5

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

Three short sentences with zero filler; the core action and scope come first, then the ID source, then the sibling routing. Every sentence earns its place.

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 simple 3-param mutation with no output schema and annotations covering safety, the description covers action, scope, ID sourcing and the closest alternative. Only minor gaps remain (ordering effects on sibling lists, error cases), so it is nearly complete.

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 100%, including the placement enum and the relative_to_id conditional ('use only with before/after'), so the schema does the heavy lifting. The description adds nothing about parameter formats beyond that. Baseline 3 applies.

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 ('Move') and resource ('a todo list') with scope ('to a different place among the todo lists of its project'), and explicitly distinguishes itself from the group-moving sibling basecamp_move_todolist_group. An agent can tell it apart from basecamp_move_todo and basecamp_reorder_todos without opening any 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?

Gives a concrete prerequisite for input (get todo list IDs from basecamp_get_todoset) and routes the group case to basecamp_move_todolist_group, which is a real exclusion. It stops short of clarifying reorder vs. move versus basecamp_reorder_todos, so it is clear context without full alternative coverage.

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