Skip to main content
Glama

reassign

by app.reassign

Find event

find_event
Read-only

Search for, look up, or locate SCHEDULED events by name when you don't have an id — fuzzy, case- and accent-insensitive. (For an un-timed Inbox block, search get_schedule's backlogQuery instead — those aren't events.) Searches the past week through the next 30 days by default; pass from/to (ISO "YYYY-MM-DD", e.g. "2026-06-01") to widen or shift the window, and optionally filter by areaId, activityTypeId, or timeOfDay. Returns the best matches as { id, date, start, end, name, area, activityType } rows (one per event), each also carrying its source and, when calendar-linked, its calendar name and readOnly flag (a read-only event lives on a calendar the user doesn't own — don't edit or delete it). When two different events tie, ambiguous is true — ask the user which they meant. Two days of the same recurring event are not ambiguous.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRange end, ISO date, e.g. "2026-07-01". Defaults to +30 days.
fromNoRange start, ISO date, e.g. "2026-06-01". Defaults to 7 days ago.
queryYesText to match against event names, e.g. "standup", "gym".
areaIdNoOnly match events linked to this area id.
timeOfDayNoOnly match events starting in this part of the day.
activityTypeIdNoOnly match events linked to this activity-type id.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substantial behavior: fuzzy/case/accent-insensitive matching, default time window, return row fields, source/calendar/readOnly flags, the instruction not to edit/delete read-only events, and the ambiguous flag for ties. This goes well beyond the annotation and sets clear expectations for results.

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?

The description is dense but every sentence carries unique information: purpose, exclusion, defaults, filters, return format, ambiguity handling, and read-only caution. It is front-loaded with the core purpose, and the length is justified by the tool's complexity. No wasted words.

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?

Despite having 6 parameters and no output schema, the description fully covers the tool's behavior: search scope, time window, filtering options, exact return fields, calendar/readOnly nuance, and ambiguity resolution. It is complete for an AI agent to invoke correctly without needing additional context.

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 100%, so the schema already documents each parameter. The description adds semantic value by explaining the default date range and how from/to shift it, the fuzzy matching nature of query, and that optional filters narrow results. This goes beyond the schema's basic descriptions, though not deeply for every filter.

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 begins with a specific verb phrase: 'Search for, look up, or locate SCHEDULED events by name when you don't have an id' — clearly stating the action, resource, and the key context (no id). It also distinguishes from siblings by explicitly excluding Inbox blocks and pointing to get_schedule's backlogQuery, making the tool's scope unmistakable.

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 usage guidance: use when searching by name without an id; warns against using for un-timed Inbox blocks and directs to get_schedule's backlogQuery instead. It also explains default date range and how to widen/shift it with from/to parameters, giving clear when-to-use and alternatives.

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