Returns recent lunch orders for the authenticated user's students. Read-only. Optionally filter by student_id.
| Name | Required | Description | Default |
|---|---|---|---|
| student_id | No | Filter to a specific student (must be your own) |
| Name | Required | Description | Default |
|---|---|---|---|
| orders | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and destuctiveHint, and the description adds the own-students scope and recent time window as useful context. It restates 'Read-only' already captured by annotations and does not disclose ordering, pagination, or other response behavior; still, there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loads the core purpose and scope, and includes the optional parameter without extra fluff. Every clause is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-param, read-only tool with an output schema and safety annotations, the description is nearly complete. The main gaps are lack of explicit sibling routing and the unspecified time boundary of 'recent', but neither blocks a competent call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% parameter schema coverage, the schema already defines student_id and that it must be the user's own. The description only says 'Optionally filter by student_id', which adds no meaning beyond the schema field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb and resource (returns recent lunch orders) and narrows scope to the authenticated user's students. The words 'recent' and 'students' help distinguish it from sibling tools like get_upcoming_orders or get_school_lunches, so an agent can see what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It communicates the general context (recent orders for the user's own students) and an optional filter, but it does not explicitly say when to prefer this tool over sibling order/list tools. An agent would have to infer the temporal and ownership boundary from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct resources, but get_wallet_balance and get_wallet_status overlap heavily, and create_draft_order/order_lunch offer two order-creation paths that could be confused. get_orders/get_daily_orders/get_monthly_orders also share retrieval territory, though role/date filters help.
Snake_case verb_object naming is used throughout and most names are predictable (create_*, update_*, get_*, list_*). Minor inconsistencies exist: list_ vs get_ for menu reads, order_lunch vs create_draft_order, and sign_up_to_volunteer breaks the simple verb_object pattern.
25 tools is on the heavy end, and several could be merged, such as get_wallet_balance/get_wallet_status and some order-retrieval variants. The broad school-lunch/event/wallet domain justifies much of the surface, but it still feels slightly over-scoped.
The lunch order lifecycle (draft, finalize, cancel, view) and admin menu/event workflows are well covered. Minor gaps: no direct event-detail or shift-list tool is provided for sign_up_to_volunteer, and restaurants lack update/delete operations.