Skip to main content
Glama

reassign

by app.reassign

Manage Inbox

manage_backlog
Destructive

Write to the Inbox — the tray of time-blocks captured without a time yet: intentions like "wash the car" or "call the dentist". To READ Inbox blocks, use get_schedule (backlogCount, then includeBacklog: true for the items or backlogQuery to find one by name); THIS tool is the write surface. Pass ops, an array where each item has an op plus its fields — one or many in a single call, atomic by default (if any op fails nothing is written; pass partial: true for best-effort). Ops: capture creates an Inbox block (name, optional notes/durationHours, area/activityType by id or name, and an optional plannedDate or plannedDate+plannedUntil window — the still-untimed day(s) it's meant for; pass enrich: true for RAW captured text, e.g. a web-page selection, to have AI propose a readable name and a duration first — never for a name the user chose); update edits one by id (plannedDate: null moves it back to Someday; a task-app-linked block's date is provider-owned and refused); remove deletes one by id (reversible — the response returns an undoToken); schedule PLACES an Inbox block on the dial at date+start (its duration sizes it; pass recurrence to make it repeat) and removes it from the Inbox; park MOVES a dial event (by eventId) back into the Inbox. park only works on a native or owned-calendar one-off that hasn't been reviewed — a recurring, sleep, reviewed, or not-owned event is refused with a reason (edit it on the dial instead). Moving a calendar-linked event to the Inbox removes its calendar copy but remembers the calendar, so re-scheduling it republishes there. The Inbox is a Pro feature. schedule and park are inverses: to undo a schedule, park it again, and vice-versa.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYes
partialNoBest-effort mode instead of the default all-or-nothing.

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint=true) by detailing atomicity (all-or-nothing by default, partial:true for best-effort), reversibility of remove via undoToken, provider-owned date refusal for task-linked blocks, calendar copy removal and republish behavior for park/schedule, and the inverse relationship between schedule and park. This is rich behavioral context.

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?

The description is a long single paragraph but is front-loaded with the core purpose and each sentence carries unique, necessary information. It could be improved with bullet or subsection structure, but for a tool with five distinct operations, the density is justified and not wasteful.

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

Completeness5/5

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

Given the tool's complexity (five ops, atomicity, edge cases) and lack of an output schema, the description is remarkably complete. It explains the read path (get_schedule), write semantics, undo behavior, calendar interplay, and Pro feature requirement, giving an agent everything needed to invoke the tool safely and 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?

The description adds important parameter meaning beyond the schema, especially for enrich ('never for a name the user chose'), plannedDate:null moving to Someday, schedule removing from the Inbox, and park's eventId constraints. While the schema already covers many per-property details, the description provides operational semantics that are not obvious from the schema alone.

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?

The description opens with 'Write to the Inbox' and explicitly defines the tool as the write surface, distinguishing it from get_schedule for reading. It enumerates all five operations (capture, update, remove, schedule, park) with clear verbs and resources, leaving no ambiguity about what the tool does.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: 'To READ Inbox blocks, use get_schedule' and 'THIS tool is the write surface'. It also covers when to use partial:true, when park is refused vs when to edit on the dial, and notes Pro feature requirement. These exclusions and alternatives are clearly actionable.

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

All reassign toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct operation: reading (get_schedule, find_event, get_energy, get_weather, show_day), scheduling (schedule, confirm_schedule), event editing (write_events, delete_events), backlog management (manage_backlog), category management (manage_categories), reflection (review_day), undo, and feedback. The boundary between schedule and write_events is explicitly clear (exact times vs. conflict-free search), and get_schedule vs. show_day are differentiated by text vs. visual presentation. The only minor ambiguity is that manage_backlog includes a 'schedule' op, but that's internal to the tool.

Naming Consistency4/5

All but two tools follow verb_noun snake_case: confirm_schedule, delete_events, find_event, get_energy, get_schedule, get_weather, manage_backlog, manage_categories, review_day, send_feedback, show_day, write_events. The exceptions are 'schedule' and 'undo', which are bare verbs and thus slightly break the consistent pattern.

Tool Count5/5

14 tools is well-scoped for a comprehensive scheduling assistant: read surfaces, write surfaces, assisted scheduling, backlog/category management, reflection, undo, weather/energy, and feedback. Each tool covers a distinct capability, and none feels redundant. Only the extra weather and energy getters could arguably be merged with get_schedule, but they serve specific use cases.

Completeness5/5

The tool surface covers the full lifecycle: create (schedule, write_events), read (get_schedule, find_event), update (write_events, manage_backlog, manage_categories), delete (delete_events, review_day discard), plus undo and confirmation flows. There are no obvious dead ends or missing CRUD operations for the scheduling domain. Weather and energy are bonuses that support informed scheduling decisions.

Resources