Returns the authenticated Paxaver user context: their name, active school, students they are a guardian for, and available roles. ALWAYS call this first before any other tool to establish context. This is a read-only operation.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| roles | No | ||
| lastName | No | ||
| students | No | ||
| firstName | No | ||
| schoolName | No | ||
| schoolSlug | 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the return contents and emphasizing the required first-call behavior, which helps the agent understand the tool's role in the workflow. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver maximum value: the first states the return data, the second provides an explicit ordering directive and confirms the read-only nature. Every sentence earns its place with no redundancy or filler.
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 zero-parameter read-only tool with an output schema, the description is fully complete. It covers the purpose, the data returned, the required call order, and the safety profile, leaving nothing an agent needs to infer before invoking it correctly.
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?
The tool has zero parameters and the input schema is complete, so parameter semantics are trivially satisfied. The description correctly implies no input is needed, and with no parameters to document, baseline 4 is appropriate.
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 uses a specific verb 'Returns' and clearly identifies the resource: the authenticated Paxaver user context. It lists the exact contents (name, active school, guardian students, roles), leaving no ambiguity about what the tool provides, and it is distinct from all sibling tools.
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 explicitly states 'ALWAYS call this first before any other tool to establish context,' giving a clear and authoritative usage rule. Since no sibling tool provides user context, there is no alternative to distinguish against, and the sequencing guidance fully covers when to use it.
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.