ADMIN: Creates a restaurant for the active school. Requires pac_cordinator role. WRITE operation - confirm with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| school_slug | No | ||
| tax_percent | No |
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| name | No | ||
| isActive | 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?
Although readOnlyHint=false already indicates a write operation, the description adds valuable behavioral context: it requires the pac_cordinator role, is an admin operation, and the agent should confirm with the user before invoking. This goes beyond the annotations and meaningfully guides invocation.
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 three short, front-loaded sentences with no filler. The critical access requirement and user-confirmation instruction are included without bloating the text.
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?
The description provides purpose, role information, and confirmation guidance, and an output schema exists to cover return values. However, the complete absence of parameter guidance leaves an agent without enough information to confidently construct a valid call, especially for tax_percent and school_slug.
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?
Schema description coverage is 0%, and the description compensates with nothing about the parameters. The required 'name' is never mentioned, and there is no guidance on the meaning or format of 'school_slug', 'description', or 'tax_percent', nor how 'active school' relates to 'school_slug'.
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 clearly identifies the operation ('Creates a restaurant'), the scope ('for the active school'), and the admin-only nature. This distinguishes it well from siblings like create_menu_item, create_event, and create_draft_order, which target different resource types.
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?
The description states the intended context—creating a restaurant for the active school—and the required role ('pac_cordinator role'). It does not explicitly name an alternative tool or mention when not to use it, but the resource-specific purpose makes the usage context reasonably clear.
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.