Skip to main content
Glama

reassign

by app.reassign

Send feedback

send_feedback

Report a bug, limitation, friction, or idea about reassign itself — its tools, their results, or this MCP integration — to the product team, who read every message. Covers errors, confusing or wrong results, retries or workarounds, loops, and rough edges that could be smoother, plus feedback the user asks to send. This is meta-feedback ABOUT the product, not a way to change the schedule (use write_events for events). kind is "bug" | "idea" | "other". In message, describe what you tried, what happened, what you expected, and any event ids or steps to reproduce; send one concise report per issue rather than repeating it. Describe the problem in your own words — don't paste the user's personal details or private schedule contents; their account is attached automatically for follow-up.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesType of feedback: "bug" for something broken or wrong, "idea" for a suggestion or feature request, "other" for anything else.
messageYesThe feedback itself. For a bug, say what happened, what you expected, and any event ids or steps that reproduce it.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint:false, destructiveHint:false, which don't clarify much for a feedback tool. The description compensates by disclosing key behaviors: the user's account is attached automatically for follow-up, every message is read by the team, and privacy guidance about not pasting personal details or private schedule contents. This is valuable behavioral context beyond the annotations.

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 solid paragraph that front-loads the purpose and packs in usage guidelines, privacy, and content requirements efficiently. It's somewhat long but every sentence adds meaning—purpose, exclusions, content guidance, and privacy. No wasted words, though it could be tightened slightly.

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?

For a simple 2-param tool with no output schema and full schema coverage, the description is thorough: it covers purpose, usage boundaries, content quality, privacy, and expected outcomes (account attached, read by team). It fully equips an agent to decide when and how to invoke this tool correctly.

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 coverage is 100%, so the schema already documents both parameters fully (kind enum values and message requirements). The description adds marginal value by reinforcing the content guidance for message (what to include, one issue per report), but the schema already carries most of the parameter semantics. Baseline 3 is appropriate.

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 clearly states the tool sends meta-feedback about the reassign product itself (bugs, ideas, limitations, friction) to the product team. It explicitly distinguishes from schedule-changing tools with 'not a way to change the schedule (use write_events for events)', providing excellent sibling differentiation.

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?

The description gives explicit when-to-use guidance (reporting bugs, limitations, friction, ideas about the product) and explicit when-not-to-use (not for scheduling changes, pointing to write_events). It also gives clear content guidance: describe what tried, what happened, what expected, event ids, steps to reproduce, and send one report per issue.

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