Connect AI assistants to Paxaver, the School Community Operating System, for authorized access to school lunch menus, student lunch orders, wallet balances, school events, restaurants, and school-community operations.
Scored across 16 tools
Each tool targets a distinct resource+action, and descriptions explicitly cross-reference alternatives (e.g. cancel_my_lunch_order vs discard_lunch_order_draft, register_for_event vs sign_up_for_volunteer_shift). The lunch draft lifecycle (create/update/discard/pay) is cleanly separated with clear boundaries.
All names are snake_case, verb-first (get_, list_, create_, update_, discard_, pay_, cancel_, register_, sign_up_). The 'my' qualifier is used consistently for user-scoped reads/writes, so the pattern is predictable.
16 tools is slightly above the ideal range but justified by three real feature domains (lunch, events, volunteering) plus account/wallet lookups. No obvious filler; each tool maps to a concrete operation.
Covers the full lifecycle for lunch orders (menu→draft→update/pay/discard/cancel), events (list→register→cancel), and volunteer shifts (list→sign up→cancel), plus account context and wallet. Minor gaps like a wallet top-up tool are explicitly out of scope (deferred to the panel), so the surface is coherent.
Cancels one of the authenticated user's own event tickets (ticket_id from list_my_event_registrations). Releases the reserved seats; for paid tickets the full amount is refunded to the user's wallet at that school. Only the ticket owner or a coordinator can cancel. DESTRUCTIVE - confirm with the user before cancelling.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | Ticket ID from list_my_event_registrations - must belong to the caller and still be cancellable |
| Name | Required | Description |
|---|---|---|
| id | No | Cancelled ticket ID |
| status | No | Ticket status (cancelled) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description discloses concrete effects: reserved seats are released, full refund is credited to the user's wallet at that school, access is restricted to owner/coordinator, and the user must confirm before cancellation. This adds real behavioral context that the annotations do not provide.
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?
Three concise sentences with no filler. The core operation is front-loaded, followed by consequences, permission constraint, and a clear safety warning. Every sentence contributes useful information.
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-parameter tool with an output schema and strong annotations, the description covers the identity of the affected ticket, the post-cancellation effects (seats and refund), the authorization constraint, and the required user confirmation. No significant calling context is missing.
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 single parameter is already fully documented by the schema (100% coverage), including the constraint that the ticket must belong to the caller and be cancellable. The description repeats the source of ticket_id but does not add new parameter-level semantics beyond the schema.
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?
Description uses a specific verb ('Cancels'), specifies the resource ('one of the authenticated user's own event tickets'), names the required input source ('ticket_id from list_my_event_registrations'), and distinguishes itself from sibling cancel tools by targeting ticket registrations rather than lunch orders, volunteer signups, or the event itself.
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 clearly frames when to use the tool: for a user's own event ticket cancellation, and it sets the condition that only the ticket owner or a coordinator may cancel. It also includes a confirmation requirement. However, it does not explicitly contrast with sibling tools like cancel_school_event or cancel_my_volunteer_signup, so some routing is left to context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels a finalized order and refunds the charge to the wallet. Only works before order labels have been sent; after that the request is rejected and the order stands. DESTRUCTIVE - confirm with the user before cancelling.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ID of a finalized order - from list_my_lunch_orders; the order must still be finalized and not yet have labels sent |
| Name | Required | Description |
|---|---|---|
| id | No | Order ID |
| status | No | Order status (cancelled) |
| refundCents | No | Amount refunded to the wallet, in cents |
| balanceCents | No | Wallet balance after the refund, in cents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavior beyond that: the wallet refund, the rejection condition after labels are sent, and the user-confirmation requirement. There is no contradiction with the annotations, including idempotentHint=true.
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?
Three short sentences with no filler: the core action, the timing limitation, and the destructive-action warning. It is front-loaded and every sentence earns its place.
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 single-parameter mutating tool with an output schema and complete annotations, this covers the preconditions, the failure mode, the postcondition (refund), and the required user confirmation. Nothing essential for selecting or invoking the tool is missing.
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 schema fully documents order_id, including the source (list_my_lunch_orders) and the preconditions (finalized, labels not sent). With 100% schema description coverage, the description does not need to add parameter-level detail and does not meaningfully exceed what the schema already provides.
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?
States a specific verb ('Cancels'), a resource ('finalized order'), and the resulting effect ('refunds the charge to the wallet'). The phrase 'finalized order' clearly distinguishes this from draft-focused siblings like discard_lunch_order_draft and create_lunch_order_draft.
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?
Explicitly gives the acceptable timing ('before order labels have been sent') and the when-not case ('after that the request is rejected and the order stands'). It also instructs the agent to confirm with the user before cancelling. It does not name a sibling alternative for drafts, but the finalized-order phrasing covers the primary routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels one of the authenticated user's own volunteer signups (signup_id from list_my_volunteer_signups) and frees the shift slot for others. No payment is involved. Only the volunteer themselves or an admin can cancel. DESTRUCTIVE - confirm with the user before cancelling.
| Name | Required | Description | Default |
|---|---|---|---|
| signup_id | Yes | Signup ID from list_my_volunteer_signups - must belong to the caller and still be active |
| Name | Required | Description |
|---|---|---|
| id | No | Cancelled signup ID |
| status | No | Signup status (cancelled) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it destructive and non-read-only, but the description adds meaningful behavioral detail: it frees the shift slot for others, clarifies that no payment is involved, specifies authorization (volunteer/admin only), and explicitly instructs the agent to confirm with the user before proceeding. This goes far beyond the annotations and provides the agent with critical safety context. No contradiction with 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?
The description is compact and front-loaded, with each sentence serving a distinct purpose: the first states the action and effect, the second removes financial ambiguity, the third specifies authorization, and the fourth delivers the safety warning. There is no filler or redundancy, and the most critical destructive note is placed at the end for emphasis while still being quickly scannable.
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 simple one-parameter tool with annotations covering read-only/destructive/idempotent hints, the description provides ample context: effect on the shift, payment clarity, authorization, and confirmation requirement. It does not explicitly describe the return value, but an output schema exists, so that is not required. It also does not mention idempotency (e.g., behavior on double-cancel), but that is already covered by idempotentHint. Overall, it is almost complete.
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 100%: the signup_id parameter already has a clear description stating it must come from list_my_volunteer_signups and belong to the caller. The tool description repeats this source but does not add new meaning or details (e.g., format, validation). Per the baseline rule for high schema coverage, a score of 3 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 states a specific verb ('cancels'), resource ('volunteer signups'), and scope ('own'), and even references the source of the ID (list_my_volunteer_signups). It clearly distinguishes from sibling tools like cancel_my_event_registration or cancel_my_lunch_order by naming the unique resource. The purpose is unambiguous.
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 gives clear context: it cancels only the authenticated user's own signups, from a specific list, and notes that only the volunteer or an admin can cancel. However, it does not explicitly contrast with related tools (e.g., cancel_my_event_registration) or state when not to use it beyond the ownership scope. There is implied usage guidance, but no explicit exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an unpaid draft lunch order with one or more items - nothing is charged until pay_lunch_order_draft commits it. Use for multi-item orders or when the user should review the total first; each items entry pairs a menu_item_id with a quantity. The draft total is the sum of item prices times quantities plus nothing else until pay_lunch_order_draft. To change or abandon the draft, use update_lunch_order_draft or discard_lunch_order_draft. FINANCIAL - confirm student, items, and date before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items to order; get IDs and prices from get_lunch_menu | |
| menu_date | Yes | Date the lunch is served, YYYY-MM-DD | |
| student_id | No | Student ID (must be your own student; from get_my_context); required when the user has more than one student, defaults to their only student | |
| school_slug | No | School slug (from get_my_context); defaults to the active school |
| Name | Required | Description |
|---|---|---|
| id | No | Draft order ID - pass to pay_lunch_order_draft |
| items | No | Draft line items |
| status | No | Order status (draft) |
| menuDate | No | Date the lunch is served, YYYY-MM-DD |
| studentId | No | Student the order is for |
| schoolSlug | No | School the order was placed at |
| itemTotalCents | No | Item total in cents - charged on finalize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly=false, idempotent=true, destructive=false, so the bar is lower. The description adds genuine context beyond those: 'nothing is charged until pay_lunch_order_draft commits it' discloses deferred financial impact, and 'plus nothing else' rules out hidden fees. No contradiction with the annotations exists — the description never claims read-only or destructive behavior.
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?
Purpose is front-loaded and each sentence earns its place: purpose, usage criterion, pricing/behavioral detail, lifecycle alternatives, and a FINANCIAL confirmation warning. Minor redundancy exists between sentence one ('nothing is charged until pay commits it') and sentence three ('plus nothing else until pay_lunch_order_draft'), which could be merged without loss.
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?
Given the output schema exists (covering return values), the schema documents parameter provenance via get_lunch_menu and get_my_context defaults, and the description covers financial impact, lifecycle routing, and a confirmation warning, this is nearly complete for a financial write tool. The one small gap is that the description doesn't state what happens on repeat calls with identical arguments — though idempotentHint=true partially covers this.
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 coverage is 100%, so the schema documents all four parameters, justifying a baseline of 3. The description adds meaning on top: it explains the items structure as pairing a menu_item_id with a quantity and spells out the pricing computation ('sum of item prices times quantities plus nothing else'), which clarifies that price_cents is the unit price multiplied by quantity.
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 states a specific verb and resource — 'Creates an unpaid draft lunch order with one or more items' — and immediately distinguishes it from its lifecycle siblings: pay_lunch_order_draft commits it, update/discard change or abandon it. An agent can tell this tool apart from pay, update, and discard without opening any schema.
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?
Gives explicit when-to-use criteria ('Use for multi-item orders or when the user should review the total first') and names the alternative tools for the next action (pay_lunch_order_draft) and for alterations (update_lunch_order_draft, discard_lunch_order_draft). It lacks an explicit when-not-to-use statement for the direct single-item/pay-now case, but the guidance is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently discards an unpaid draft order - the caller must own it and it must still be in draft status (order_id from create_lunch_order_draft). Nothing was ever charged, so there is no refund; the draft is simply deleted. For a finalized order use cancel_my_lunch_order instead. DESTRUCTIVE - confirm with the user before discarding.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | Draft order ID from create_lunch_order_draft - must still be in draft status |
| Name | Required | Description |
|---|---|---|
| status | No | Order status (discarded) |
| orderId | No | Discarded draft order ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides substantial behavioral context beyond the annotations: the operation is permanent, no refund exists because nothing was charged, the draft is simply deleted, and it explicitly warns to confirm with the user. It also emphasizes destructive behavior, matching the destructiveHint annotation without contradicting it.
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 compact and front-loaded, with every sentence contributing necessary operational or safety information. The critical DESTRUCTIVE warning is included without redundancy or fluff.
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 single-parameter destructive tool, the description fully covers purpose, preconditions, side effects, alternatives, and user confirmation. Since an output schema exists, return-value details are not required here, and nothing essential is missing.
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 input schema already fully describes order_id as the draft order ID from create_lunch_order_draft and requires draft status. The description reinforces this but adds no new parameter meaning beyond what the schema already covers, so the baseline of 3 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 identifies a specific verb and resource: 'Permanently discards an unpaid draft order.' It also differentiates from the sibling tool by specifying that it applies only to drafts and directing finalized orders to cancel_my_lunch_order.
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 when to use the tool: the caller must own the draft, it must still be in draft status, and it must be unpaid. It also names the alternative for finalized orders and includes a clear confirmation requirement, leaving no ambiguity about usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only lookup with no side effects - safe to call repeatedly. Requires authentication: returns only the caller's own context (never another user's data): first name, active school, the students they are a guardian for, and their role codes at that school. This is the context-discovery call - most other tools need a student_id or school_slug from here, and admin-role checks come from roles. Returns live account state, so call again if the user may have switched schools or had roles changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| roles | No | Role codes the user holds at the active school |
| students | No | Students the user is guardian for (id, firstName, schoolSlug) |
| firstName | No | User first name |
| schoolName | No | Active school display name |
| schoolSlug | No | Active school slug |
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 meaningful behavioral context: it is safe to call repeatedly, requires authentication, returns only the caller's own data, and returns live account state. It does not contradict annotations. A small gap is that it doesn't describe the output schema shape, but the output schema exists and the description covers the key behavioral traits.
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 compact, front-loaded with the most important fact (read-only, safe to call repeatedly), and every sentence adds value: what it returns, why it matters, and when to call again. No wasted words.
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 and annotations covering safety, the description is complete. It explains the return contents, the authentication requirement, the privacy boundary, and the live-state caveat. An agent has everything needed to call it correctly and interpret its role in the broader toolset.
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, so the schema is trivially complete. The description adds value by explaining what the returned data contains and how it should be used, which is more relevant than parameter semantics for a no-parameter tool. Baseline 4 for zero params 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 states a specific verb ('lookup'), a clear resource (the caller's own context), and enumerates exactly what is returned (first name, active school, guardian students, role codes). It also distinguishes itself from siblings by framing it as the context-discovery call that other tools depend on.
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 says when to use it: as the context-discovery call, before other tools that need student_id or school_slug, and for admin-role checks. It also tells the agent to call again if the user may have switched schools or roles changed. This is strong usage guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only lookup - never moves funds or has side effects. Requires authentication: returns only the caller's spendable wallet balance at their active school (wallets are scoped per school, so a balance at one school does not apply elsewhere), in cents and formatted. Live value reflecting orders and refunds up to the current moment - recheck before assuming funds are still available. Call before pay_lunch_order_draft or register_for_event to confirm the user can cover the charge; not needed for read-only lookups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| currency | No | ISO currency code (CAD, USD, or MXN) |
| balanceCents | No | Spendable balance in cents |
| balanceFormatted | No | Balance formatted with the currency symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: requires authentication, school-scoped data, live values reflecting orders/refunds, and the caution to recheck before assuming funds. It also emphasizes no side effects, which reinforces the read-only annotation without contradicting it.
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 front-loaded with the most important fact ('Read-only lookup - never moves funds or has side effects') and every subsequent sentence earns its place: auth, scope, units, freshness, and usage guidance. It is detailed but not bloated, each clause adds distinct value.
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 tool with an output schema, the description covers everything needed to call it correctly: authentication requirement, per-school scoping, return format (cents and formatted), live-value semantics, and when to invoke it. An agent has all necessary context.
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 input schema has zero parameters, so the baseline is 4. The description doesn't need to explain parameters because there are none; it instead explains what data the tool operates on (caller's balance, active school), which is the relevant semantic content.
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 specific verb and resource: it 'returns only the caller's spendable wallet balance.' It also scopes the operation precisely to the caller's active school, in cents and formatted, which separates it from any other balance-related query. This clearly distinguishes it from the mutation-heavy sibling list.
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 gives explicit when-to-use instructions: 'Call before pay_lunch_order_draft or register_for_event to confirm the user can cover the charge.' It also provides a when-not exclusion ('not needed for read-only lookups') and contextual scoping guidance about per-school balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only, no side effects. Returns the authenticated user's own event tickets at their active school - ticket id, event name/date/location, quantity, total paid, and status (paid or checked_in). Cancelled tickets are excluded. The id values returned are required by cancel_my_event_registration. Pair with list_school_events for events the user has not registered for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tickets | No | Caller's event tickets at the active school |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only, no side effects.' It adds valuable behavioral context beyond annotations: results are scoped to the active school, cancelled tickets are excluded, and the return payload includes ticket status values like paid and checked_in.
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?
Four sentences with no fluff; the key behavioral claim is front-loaded and every sentence adds useful information. The only minor issue is that 'Read-only, no side effects' partly duplicates the annotations, but it is brief and harmless.
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 tool with an output schema and strong annotations, this description is complete: it defines scope, exclusions, returned fields, and links to the two most relevant sibling tools. An agent has everything needed to select and invoke 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 input schema has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description correctly focuses on output and scope rather than parameter syntax, and no parameter-level explanation is needed.
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?
States a specific verb ('Returns') and a precise resource: the authenticated user's own event tickets at their active school, including the exact fields returned. It clearly differentiates itself from sibling list tools like list_school_events, list_my_lunch_orders, and list_my_volunteer_signups by scope and resource.
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?
Explicitly names the sibling tool list_school_events for events the user has not registered for, giving a clear when-to-use/when-not-to-use distinction. It also states that the returned ids are required by cancel_my_event_registration, which helps an agent decide to call this tool before attempting a cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns lunch orders already placed - items, menu date, status, and total - for the authenticated user's students, newest first (up to ~100 most recent). Filters combine with AND: student_id narrows to one student; menu_date and month narrow the date range, and if both are given menu_date wins. With no filters returns recent orders across all of the user's students. Admins (pac_cordinator, lunch_cordinator) see school-wide orders; parents only their own students. For what can be ordered (menu and prices), use get_lunch_menu.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Calendar month to query, YYYY-MM; omit when using menu_date | |
| menu_date | No | Single day to query, YYYY-MM-DD; omit when using month | |
| student_id | No | Filter to a specific student (must be your own student, from get_my_context; admins may filter any student in the school) |
| Name | Required | Description |
|---|---|---|
| orders | No | Orders matching the filters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds non-obvious behavior beyond that: newest-first ordering, a ~100 record cap, filter precedence, and role-based visibility. Nothing contradicts 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?
The description is information-dense with no filler. Each clause earns its place: return fields, ordering, limit, filter semantics, fallback behavior, role scoping, and the pointer to a sibling tool.
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 read-only listing tool with an output schema, the description covers all needed invocation context: what is returned, ordering, limits, filter combination and precedence, default behavior, role-based access, and which sibling to use for menus.
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?
Although schema coverage is 100%, the description adds meaning beyond the schema: filters combine with AND, menu_date wins if both menu_date and month are provided, and student_id has ownership/role constraints. These behaviors are not inferable from the schema alone.
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 opens with a specific verb and resource: 'Returns lunch orders already placed - items, menu date, status, and total - for the authenticated user's students.' It clearly distinguishes this read tool from sibling create/cancel/update/order tools and from get_lunch_menu.
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?
Explicitly explains filter combination behavior (AND), menu_date vs month precedence, the no-filter default, and admin vs parent scoping. It also points to get_lunch_menu when the goal is ordering-eligible items, giving a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only, no side effects. Returns the authenticated user's active volunteer signups at their school - signup id, shift title/date/times, and the parent event. Cancelled signups are excluded. The id values returned are required by cancel_my_volunteer_signup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| signups | No | Caller's active volunteer signups |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying that cancelled signups are excluded, the data scope (active signups at the user's school), and the dependency on cancellation. No contradiction with 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?
Four short sentences, each carrying distinct information: safety, return content, exclusion filter, and downstream usage. No filler, and the most critical information (read-only, what it returns) is front-loaded.
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 no-parameter tool with an output schema present, the description covers all necessary operational details: return fields, scope, exclusions, and the relationship to cancellation. Nothing critical is missing for an agent to call 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, so the input schema is empty and coverage is effectively 100%. The description appropriately doesn't dwell on parameters; the baseline for 0-param tools is 4, and no additional parameter explanation is needed.
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 states a specific verb ('Returns') and resource ('volunteer signups'), with explicit fields returned. It distinguishes from siblings like list_my_event_registrations (different resource) and cancel_my_volunteer_signup (different action). The scope is clear: authenticated user's active signups at their school.
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 mentions that returned IDs are required by cancel_my_volunteer_signup, which gives a concrete use case and implies this tool is the precursor for cancellation. However, it doesn't explicitly contrast with other list tools (e.g., list_my_event_registrations) or state when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns upcoming events for the user's active school: date, times, location, volunteer shifts, and whether registration is closed. The event IDs returned feed register_for_event; shift IDs feed sign_up_for_volunteer_shift. To review or undo your own registrations and signups, use list_my_event_registrations / cancel_my_event_registration and list_my_volunteer_signups / cancel_my_volunteer_signup. Optionally filter by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day of the range, YYYY-MM-DD (inclusive); omit for all upcoming events | |
| start_date | No | First day of the range, YYYY-MM-DD (inclusive); omit for all upcoming events |
| Name | Required | Description |
|---|---|---|
| events | No | Upcoming events matching the date range |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so the bar is lower. The description adds useful behavioral context beyond annotations: it returns upcoming events only, includes volunteer shifts and registration closure status, and is scoped to the active school. It does not contradict annotations and provides enough behavioral framing for a list operation.
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 sentences long and each sentence earns its place: the first states what is returned, the second explains how the returned IDs connect to downstream tools, and the third provides alternative-tool routing and the optional filter. It is front-loaded and free of 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 read-only listing tool with an existing output schema, two optional parameters fully documented, and clear annotations, the description covers everything an agent needs: return contents, relationship to dependent tools, alternatives for own registrations, and optional filtering. Nothing important is missing.
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 100%, so the schema documents both optional parameters (start_date and end_date) adequately. The description only says 'Optionally filter by date range,' which adds no new semantic detail beyond the schema's own descriptions. Baseline 3 is appropriate given full schema coverage.
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 states the tool lists upcoming events for the user's active school and enumerates the included data (date, times, location, volunteer shifts, registration status). It distinguishes itself from related registration/signup tools by explicitly noting that event IDs feed register_for_event and shift IDs feed sign_up_for_volunteer_shift.
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 gives explicit routing guidance: it says to use list_my_event_registrations / cancel_my_event_registration and list_my_volunteer_signups / cancel_my_volunteer_signup to review or undo the user's own registrations and signups. This tells the agent exactly when this tool is appropriate and when alternatives should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Commits a draft order from create_lunch_order_draft and charges the wallet for the item total plus optional tip_cents (donated to the school's PAC). Wallet-only: if the balance cannot cover the full total, the call fails with an error directing the user to open the Paxaver panel and top up the wallet balance, then retry - no card payment is offered through this tool. Not for new orders - use create_lunch_order_draft first. FINANCIAL - confirm the total before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | Draft order ID from create_lunch_order_draft - must still be in draft status; already-finalized orders are rejected | |
| tip_cents | No | Tip in cents (donated to school PAC) |
| Name | Required | Description |
|---|---|---|
| status | No | 'finalized' when the wallet covered the full total |
| orderId | No | Order ID |
| tipCents | No | PAC donation added, in cents |
| itemTotalCents | No | Item total in cents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false, destructive=false, and idempotent=true, and the description adds valuable behavior: charging the wallet, optional tip donation, the rejection of already-finalized orders (supporting idempotency), and the no-card-payment limitation. The FINANCIAL warning further clarifies the risk profile.
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 compact and front-loaded: the core action is stated first, followed by payment constraints, failure behavior, and the key exclusion. Every sentence carries operational weight, with no redundant or filler content.
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?
Given a 2-parameter schema, an output schema, and rich annotations, the description covers the essential workflow: commit a draft, charge wallet, handle insufficient funds, and avoid misuse for new orders. No critical operational detail is missing.
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 coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that tip_cents is added on top of the item total and that the combined amount is charged to the wallet, reinforcing the schema's note that tips go to the PAC.
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 states a specific verb and resource ('commits a draft order') and clearly distinguishes this tool from siblings like create_lunch_order_draft, discard_lunch_order_draft, and cancel_my_lunch_order. It also names the source of the draft order and the financial action performed.
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 explicitly says this is not for new orders and directs the agent to use create_lunch_order_draft first. It also defines the payment constraint (wallet-only, no card) and gives a concrete failure-handling path: if balance is insufficient, tell the user to top up and retry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registers the authenticated user for a school event and issues tickets to the caller (quantity is the number of tickets bought for the caller, minimum 1 - there is no per-student split). For paid events quantity times the ticket price is charged to the user's wallet - the call fails on insufficient balance or when the event is sold out or registration is closed. To volunteer at an event rather than attend, use sign_up_for_volunteer_shift. FINANCIAL for paid events - confirm before registering.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Event ID from list_school_events - registration must still be open (check the closed flag) | |
| quantity | No | Number of tickets |
| Name | Required | Description |
|---|---|---|
| id | No | Registration ID |
| status | No | Registration status |
| eventId | No | Event the user registered for |
| quantity | No | Tickets issued |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that all tickets go to the caller with no per-student split, that paid events debit the wallet, and that the call fails on insufficient balance, sold out, or closed registration. This significantly clarifies side effects; no statement contradicts the annotations, though the idempotentHint tradeoff is left to the annotation.
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 definition is compact and front-loaded: purpose first, then financial consequence, failure conditions, and sibling routing. The second sentence is dense but each clause earns its place.
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 two-parameter registration tool, the description covers purpose, ticket allocation, costs, failure modes, and alternative tool, while an output schema exists for return values. Nothing essential is missing.
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 schema covers 100% of parameters and already defines event_id and quantity; the description adds real semantic value by stating that quantity is tickets for the caller, enforces minimum 1, and explicitly rules out per-student splitting.
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 opens with a specific verb and resource: 'Registers the authenticated user for a school event and issues tickets to the caller.' It also differentiates itself from the volunteer sibling by explicitly directing volunteer use to sign_up_for_volunteer_shift.
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 names the key alternative ('To volunteer at an event rather than attend, use sign_up_for_volunteer_shift') and gives conditional guidance for paid events with 'confirm before registering.' Failure conditions (sold out, registration closed, insufficient balance) further clarify when a call would not be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signs the authenticated user up for a specific volunteer shift - no payment involved. shift_id identifies one shift within an event, not the event itself: get it from the event's volunteer shifts in list_school_events. The call fails when the shift is full or cancelled. To attend an event as a guest instead, use register_for_event. WRITE - confirm with the user before signing up.
| Name | Required | Description | Default |
|---|---|---|---|
| shift_id | Yes | Volunteer shift ID - from the event's volunteer shifts (list_school_events) |
| Name | Required | Description |
|---|---|---|
| id | No | Signup ID |
| status | No | Signup status |
| shiftId | No | Volunteer shift signed up for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: no payment is involved, the call fails when the shift is full or cancelled, and it explicitly labels itself as a WRITE operation requiring user confirmation before executing. These details complement the idempotentHint and destructiveHint annotations without contradicting them.
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?
Each sentence earns its place: the core action, the no-payment clarification, the shift_id disambiguation with sourcing instructions, the failure triggers, the guest alternative, and the confirmation guardrail. The description is compact but information-dense, with the main purpose front-loaded.
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 single-parameter tool with an output schema and complete annotations, the description covers everything an agent needs to invoke it correctly: parameter semantics, source of the ID, failure conditions, alternative usage, and user confirmation. There are no notable gaps.
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 coverage is 100%, so baseline is 3. The description goes further by clarifying that shift_id refers to a shift within an event, not the event itself, and directs the agent to list_school_events for retrieval—value that the schema description alone does not fully convey.
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 ('Signs up'), names the resource ('volunteer shift'), and adds critical distinctions: it is for the authenticated user, involves no payment, and shift_id is a shift within an event, not the event itself. This clearly separates it from sibling tools like register_for_event and the event-level operations.
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?
Explicitly states when the tool is appropriate (signing up for a volunteer shift) and directly names the alternative for guests: 'To attend an event as a guest instead, use register_for_event.' It also instructs where to obtain shift_id via list_school_events, leaving no ambiguity about the prerequisite data source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces the items and/or menu_date of an unpaid draft order before it is finalized - the caller must own the draft and it must still be in draft status (order_id from create_lunch_order_draft). Pass the complete items list: it replaces the draft's items wholesale and the total is recomputed from price times quantity. Only draft orders can be updated; once finalized, use cancel_my_lunch_order. WRITE - confirm the new contents with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Replacement line items (menu_item_id from get_lunch_menu + quantity); replaces all existing items when provided | |
| order_id | Yes | Draft order ID from create_lunch_order_draft - must still be in draft status | |
| menu_date | No | New date the lunch is served, YYYY-MM-DD |
| Name | Required | Description |
|---|---|---|
| status | No | Order status (draft) |
| orderId | No | Updated draft order ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: items are replaced wholesale, the total is recomputed from price times quantity, and only unpaid draft orders can be updated. It correctly complements readOnlyHint=false and destructiveHint=false by framing the operation as a controlled, reversible-enough edit with ownership requirements.
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 information-dense and front-loaded with the core behavior, but it contains minor redundancy about draft status ('must still be in draft status' and 'Only draft orders can be updated'). Still, it earns its length by covering ownership, replacement semantics, and post-finalization routing in a compact form.
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 tool with 3 parameters, an output schema, and no nested objects, the description covers all essential context: what changes, what is required, what the preconditions are, how totals behave, and how to handle finalized orders. An agent has enough information to invoke the tool correctly and to avoid destructive mistakes.
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 coverage is 100%, but the description adds crucial semantics beyond the schema: items must be the complete replacement list, the update replaces existing items entirely, and the total is recomputed from price times quantity. It also clarifies that order_id comes from create_lunch_order_draft, reinforcing the schema's provenance note.
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 states a specific action ('Replaces the items and/or menu_date') on a specific resource ('unpaid draft order'), and clearly scopes it to drafts not yet finalized. It also implicitly distinguishes this tool from siblings like discard_lunch_order_draft, pay_lunch_order_draft, and cancel_my_lunch_order by emphasizing draft-state editing.
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 says when to use the tool: the order must be owned by the caller and still in draft status. It also provides the alternative for finalized orders ('use cancel_my_lunch_order'), and instructs the caller to pass the complete items list and confirm with the user, giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_my_event_registrationcancel_my_lunch_ordercancel_my_volunteer_signupcancel_ordercreate_draft_ordercreate_lunch_order_draftdiscard_lunch_order_draftfinalize_orderget_lunch_menuget_menuget_my_contextget_my_wallet_balanceget_ordersget_upcoming_eventsget_user_infoget_wallet_balancelist_my_event_registrationslist_my_lunch_orderslist_my_volunteer_signupslist_school_eventsorder_lunchpay_lunch_order_draftregister_eventregister_for_eventsign_up_for_volunteer_shiftsign_up_to_volunteerupdate_lunch_order_draftcancel_my_event_registrationcancel_my_lunch_ordercancel_my_volunteer_signupcancel_ordercreate_draft_ordercreate_lunch_order_draftdiscard_lunch_order_draftfinalize_orderget_lunch_menuget_menuget_my_contextget_my_wallet_balanceget_ordersget_upcoming_eventsget_user_infoget_wallet_balancelist_my_event_registrationslist_my_lunch_orderslist_my_volunteer_signupslist_school_eventsorder_lunchpay_lunch_order_draftregister_eventregister_for_eventsign_up_for_volunteer_shiftsign_up_to_volunteerupdate_lunch_order_draftpay_lunch_order_draft5 fields changedOutput schema / properties / balanceCentsRemoved value: -{
- "description": "Wallet balance after the charge, in cents",
- "type": [
- "number",
- "null"
- ]
-}Output schema / properties / idRemoved value: -{
- "description": "Order ID",
- "type": "string"
-}Output schema / properties / orderIdAdded value: +{
+ "description": "Order ID",
+ "type": "string"
+}Output schema / properties / status / descriptionPrevious value: -"Order status (finalized)"New value: +"'finalized' when the wallet covered the full total"Output schema / properties / totalCentsRemoved value: -{
- "description": "Total charged to the wallet, in cents",
- "type": "integer"
-}cancel_event_registrationcancel_my_event_registrationcancel_my_lunch_ordercancel_my_volunteer_signupcancel_ordercancel_volunteer_signupcreate_draft_ordercreate_lunch_order_draftdiscard_draft_orderdiscard_lunch_order_draftfinalize_orderget_lunch_menuget_menuget_my_contextget_my_event_registrationsget_my_volunteer_signupsget_my_wallet_balanceget_ordersget_upcoming_eventsget_user_infoget_wallet_balancelist_my_event_registrationslist_my_lunch_orderslist_my_volunteer_signupslist_school_eventsorder_lunchpay_lunch_order_draftregister_eventregister_for_eventsign_up_for_volunteer_shiftsign_up_to_volunteerupdate_draft_orderupdate_lunch_order_draftdiscard_draft_orderupdate_draft_ordercancel_event_registrationcancel_volunteer_signupget_my_event_registrationsget_my_volunteer_signupscancel_order1 field changedInput schema / properties / order_id / descriptionPrevious value: -"Order ID to cancel"New value: +"ID of a finalized order - from get_orders; the order must still be finalized and not yet have labels sent"create_draft_order2 fields changedInput schema / properties / school_slug / descriptionPrevious value: -"School slug (from get_user_info)"New value: +"School slug (from get_user_info); defaults to the active school"Input schema / properties / student_id / descriptionPrevious value: -"Student ID (must be your own student; from get_user_info)"New value: +"Student ID (must be your own student; from get_user_info); required when the user has more than one student, defaults to their only student"finalize_order1 field changedInput schema / properties / order_id / descriptionPrevious value: -"Order ID from create_draft_order"New value: +"Draft order ID from create_draft_order - must still be in draft status; already-finalized orders are rejected"get_menu2 fields changedInput schema / properties / date / descriptionPrevious value: -"Single day to show, YYYY-MM-DD"New value: +"Single day to show, YYYY-MM-DD; omit when using month"Input schema / properties / month / descriptionPrevious value: -"Calendar month to show, YYYY-MM"New value: +"Calendar month to show, YYYY-MM; omit when using date. Today is used when neither is given"get_orders3 fields changedInput schema / properties / menu_date / descriptionPrevious value: -"Single day to query, YYYY-MM-DD"New value: +"Single day to query, YYYY-MM-DD; omit when using month"Input schema / properties / month / descriptionPrevious value: -"Calendar month to query, YYYY-MM"New value: +"Calendar month to query, YYYY-MM; omit when using menu_date"Input schema / properties / student_id / descriptionPrevious value: -"Filter to a specific student (must be your own; from get_user_info)"New value: +"Filter to a specific student (must be your own student, from get_user_info; admins may filter any student in the school)"get_upcoming_events2 fields changedInput schema / properties / end_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Last day of the range, YYYY-MM-DD (inclusive); omit for all upcoming events"Input schema / properties / start_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"First day of the range, YYYY-MM-DD (inclusive); omit for all upcoming events"order_lunch1 field changedInput schema / properties / student_id / descriptionPrevious value: -"Student ID (must be your own student; from get_user_info)"New value: +"Student ID (must be your own student; from get_user_info); required when the user has more than one student, defaults to their only student"register_event1 field changedInput schema / properties / event_id / descriptionPrevious value: -"Event ID"New value: +"Event ID from get_upcoming_events - registration must still be open (check the closed flag)"sign_up_to_volunteer1 field changedInput schema / properties / shift_id / descriptionPrevious value: -"Volunteer shift ID"New value: +"Volunteer shift ID - from the event's volunteer shifts (get_upcoming_events)"cancel_eventcreate_eventcreate_menu_itemcreate_restaurantdelete_menu_itemlist_menu_itemslist_school_restaurantsset_daily_menuupdate_eventupdate_menu_itemcancel_event3 fields changedInput schema / properties / event_id / descriptionPrevious value: -"Event ID — from get_upcoming_events"New value: +"Event ID - from get_upcoming_events"Output schema / properties / id / descriptionAdded value: +"Event ID"Output schema / properties / status / descriptionAdded value: +"Event status (cancelled)"cancel_order4 fields changedOutput schema / properties / balanceCents / descriptionAdded value: +"Wallet balance after the refund, in cents"Output schema / properties / id / descriptionAdded value: +"Order ID"Output schema / properties / refundCents / descriptionAdded value: +"Amount refunded to the wallet, in cents"Output schema / properties / status / descriptionAdded value: +"Order status (cancelled)"create_draft_order15 fields changedInput schema / properties / items / descriptionAdded value: +"Line items to order; get IDs and prices from get_menu"Input schema / properties / items / items / properties / menu_item_id / descriptionAdded value: +"Menu item ID from get_menu"Input schema / properties / items / items / properties / menu_item_name / descriptionAdded value: +"Item display name from get_menu"Input schema / properties / items / items / properties / price_cents / descriptionAdded value: +"Unit price in cents from get_menu"Input schema / properties / items / items / properties / quantity / descriptionAdded value: +"Number of servings"Input schema / properties / menu_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Date the lunch is served, YYYY-MM-DD"Input schema / properties / school_slug / descriptionPrevious value: -"School slug"New value: +"School slug (from get_user_info)"Input schema / properties / student_id / descriptionPrevious value: -"Student ID"New value: +"Student ID (must be your own student; from get_user_info)"Output schema / properties / id / descriptionAdded value: +"Draft order ID - pass to finalize_order"Output schema / properties / itemTotalCents / descriptionAdded value: +"Item total in cents - charged on finalize"Output schema / properties / items / descriptionAdded value: +"Draft line items"Output schema / properties / menuDate / descriptionAdded value: +"Date the lunch is served, YYYY-MM-DD"Output schema / properties / schoolSlug / descriptionAdded value: +"School the order was placed at"Output schema / properties / status / descriptionAdded value: +"Order status (draft)"Output schema / properties / studentId / descriptionAdded value: +"Student the order is for"create_event4 fields changedOutput schema / properties / eventDate / descriptionAdded value: +"Event date, YYYY-MM-DD"Output schema / properties / id / descriptionAdded value: +"Event ID"Output schema / properties / name / descriptionAdded value: +"Event name"Output schema / properties / status / descriptionAdded value: +"Event status (e.g. active)"create_menu_item5 fields changedInput schema / properties / restaurant_id / descriptionPrevious value: -"Restaurant ID — from list_school_restaurants"New value: +"Restaurant ID - from list_school_restaurants"Output schema / properties / id / descriptionAdded value: +"Menu item ID"Output schema / properties / isActive / descriptionAdded value: +"Whether the item is on the restaurant menu"Output schema / properties / name / descriptionAdded value: +"Item name"Output schema / properties / priceCents / descriptionAdded value: +"Sale price in cents"create_restaurant4 fields changedInput schema / properties / school_slug / descriptionPrevious value: -"School slug — defaults to the active school"New value: +"School slug - defaults to the active school"Output schema / properties / id / descriptionAdded value: +"Restaurant ID"Output schema / properties / isActive / descriptionAdded value: +"Whether the restaurant is active"Output schema / properties / name / descriptionAdded value: +"Restaurant name"delete_menu_item4 fields changedInput schema / properties / menu_item_id / descriptionPrevious value: -"Menu item ID — from list_menu_items"New value: +"Menu item ID - from list_menu_items"Input schema / properties / restaurant_id / descriptionPrevious value: -"Restaurant ID — from list_school_restaurants"New value: +"Restaurant ID - from list_school_restaurants"Output schema / properties / deleted / descriptionAdded value: +"Whether the item was soft-deleted"Output schema / properties / id / descriptionAdded value: +"Menu item ID"finalize_order6 fields changedOutput schema / properties / balanceCents / descriptionAdded value: +"Wallet balance after the charge, in cents"Output schema / properties / id / descriptionAdded value: +"Order ID"Output schema / properties / itemTotalCents / descriptionAdded value: +"Item total in cents"Output schema / properties / status / descriptionAdded value: +"Order status (finalized)"Output schema / properties / tipCents / descriptionAdded value: +"PAC donation added, in cents"Output schema / properties / totalCents / descriptionAdded value: +"Total charged to the wallet, in cents"get_menu9 fields changedOutput schema / properties / date / descriptionAdded value: +"Date this menu applies to, YYYY-MM-DD"Output schema / properties / menuItems / descriptionAdded value: +"Items orderable on that date"Output schema / properties / menuItems / items / properties / availableQty / descriptionAdded value: +"Remaining portions; null means unlimited"Output schema / properties / menuItems / items / properties / dailyMenuId / descriptionAdded value: +"Daily-menu entry ID"Output schema / properties / menuItems / items / properties / dietaryTags / descriptionAdded value: +"Dietary labels (e.g. vegetarian, halal)"Output schema / properties / menuItems / items / properties / menuItemId / descriptionAdded value: +"Menu item ID for ordering tools"Output schema / properties / menuItems / items / properties / menuItemName / descriptionAdded value: +"Item display name"Output schema / properties / menuItems / items / properties / priceCents / descriptionAdded value: +"Sale price in cents"Output schema / properties / menuItems / items / properties / restaurantName / descriptionAdded value: +"Restaurant offering the item"get_orders8 fields changedOutput schema / properties / orders / descriptionAdded value: +"Orders matching the filters"Output schema / properties / orders / items / properties / createdAt / descriptionAdded value: +"ISO timestamp the order was placed"Output schema / properties / orders / items / properties / id / descriptionAdded value: +"Order ID"Output schema / properties / orders / items / properties / itemTotalCents / descriptionAdded value: +"Item total in cents"Output schema / properties / orders / items / properties / items / descriptionAdded value: +"Ordered line items"Output schema / properties / orders / items / properties / menuDate / descriptionAdded value: +"Date the lunch is served, YYYY-MM-DD"Output schema / properties / orders / items / properties / status / descriptionAdded value: +"Order status"Output schema / properties / orders / items / properties / studentId / descriptionAdded value: +"Student the order is for"get_upcoming_events8 fields changedOutput schema / properties / events / descriptionAdded value: +"Upcoming events matching the date range"Output schema / properties / events / items / properties / endsAt / descriptionAdded value: +"End time"Output schema / properties / events / items / properties / eventDate / descriptionAdded value: +"Event date, YYYY-MM-DD"Output schema / properties / events / items / properties / id / descriptionAdded value: +"Event ID - input to register_event, update_event, cancel_event"Output schema / properties / events / items / properties / isClosed / descriptionAdded value: +"Whether registration is closed"Output schema / properties / events / items / properties / location / descriptionAdded value: +"Event location"Output schema / properties / events / items / properties / name / descriptionAdded value: +"Event name"Output schema / properties / events / items / properties / startsAt / descriptionAdded value: +"Start time"get_user_info5 fields changedOutput schema / properties / firstName / descriptionAdded value: +"User first name"Output schema / properties / roles / descriptionAdded value: +"Role codes the user holds at the active school"Output schema / properties / schoolName / descriptionAdded value: +"Active school display name"Output schema / properties / schoolSlug / descriptionAdded value: +"Active school slug"Output schema / properties / students / descriptionAdded value: +"Students the user is guardian for (id, firstName, schoolSlug)"get_wallet_balance3 fields changedOutput schema / properties / balanceCents / descriptionAdded value: +"Spendable balance in cents"Output schema / properties / balanceFormatted / descriptionAdded value: +"Balance formatted with the currency symbol"Output schema / properties / currency / descriptionAdded value: +"ISO currency code (CAD, USD, or MXN)"list_menu_items11 fields changedInput schema / properties / restaurant_id / descriptionPrevious value: -"Restaurant ID — from list_school_restaurants"New value: +"Restaurant ID - from list_school_restaurants"Output schema / properties / items / descriptionAdded value: +"Full catalog items, including inactive and unavailable"Output schema / properties / items / items / properties / calories / descriptionAdded value: +"Calorie count"Output schema / properties / items / items / properties / costCents / descriptionAdded value: +"Kitchen cost in cents"Output schema / properties / items / items / properties / description / descriptionAdded value: +"Item description"Output schema / properties / items / items / properties / id / descriptionAdded value: +"Menu item ID"Output schema / properties / items / items / properties / ingredients / descriptionAdded value: +"Ingredient list text"Output schema / properties / items / items / properties / isActive / descriptionAdded value: +"Whether the item is on the restaurant menu"Output schema / properties / items / items / properties / isAvailable / descriptionAdded value: +"Whether the item can currently be ordered"Output schema / properties / items / items / properties / name / descriptionAdded value: +"Item name"Output schema / properties / items / items / properties / priceCents / descriptionAdded value: +"Sale price in cents"list_school_restaurants6 fields changedOutput schema / properties / restaurants / descriptionAdded value: +"Restaurants attached to the school, including inactive ones"Output schema / properties / restaurants / items / properties / description / descriptionAdded value: +"Restaurant description"Output schema / properties / restaurants / items / properties / id / descriptionAdded value: +"Restaurant ID - input to menu-item and daily-menu tools"Output schema / properties / restaurants / items / properties / isActive / descriptionAdded value: +"Whether the restaurant is active"Output schema / properties / restaurants / items / properties / logoUrl / descriptionAdded value: +"Restaurant logo URL"Output schema / properties / restaurants / items / properties / name / descriptionAdded value: +"Restaurant name"order_lunch7 fields changedOutput schema / properties / id / descriptionAdded value: +"Order ID"Output schema / properties / itemTotalCents / descriptionAdded value: +"Item total in cents"Output schema / properties / items / descriptionAdded value: +"Ordered line items"Output schema / properties / menuDate / descriptionAdded value: +"Date the lunch is served, YYYY-MM-DD"Output schema / properties / schoolSlug / descriptionAdded value: +"School the order was placed at"Output schema / properties / status / descriptionAdded value: +"Order status (e.g. finalized)"Output schema / properties / studentId / descriptionAdded value: +"Student the order is for"register_event4 fields changedOutput schema / properties / eventId / descriptionAdded value: +"Event the user registered for"Output schema / properties / id / descriptionAdded value: +"Registration ID"Output schema / properties / quantity / descriptionAdded value: +"Tickets issued"Output schema / properties / status / descriptionAdded value: +"Registration status"set_daily_menu6 fields changedInput schema / properties / menu_item_id / descriptionPrevious value: -"Menu item ID — from list_menu_items"New value: +"Menu item ID - from list_menu_items"Input schema / properties / restaurant_id / descriptionPrevious value: -"Restaurant ID — from list_school_restaurants"New value: +"Restaurant ID - from list_school_restaurants"Output schema / properties / availableQty / descriptionAdded value: +"Portion cap for the day; null means unlimited"Output schema / properties / id / descriptionAdded value: +"Daily-menu entry ID"Output schema / properties / menuDate / descriptionAdded value: +"Date the item is orderable, YYYY-MM-DD"Output schema / properties / menuItemId / descriptionAdded value: +"Menu item scheduled"sign_up_to_volunteer3 fields changedOutput schema / properties / id / descriptionAdded value: +"Signup ID"Output schema / properties / shiftId / descriptionAdded value: +"Volunteer shift signed up for"Output schema / properties / status / descriptionAdded value: +"Signup status"update_event6 fields changedInput schema / properties / event_id / descriptionPrevious value: -"Event ID — from get_upcoming_events"New value: +"Event ID - from get_upcoming_events"Input schema / properties / status / descriptionPrevious value: -"Event status — cancelled stops sales, completed closes the event"New value: +"Event status - cancelled stops sales, completed closes the event"Output schema / properties / eventDate / descriptionAdded value: +"Event date, YYYY-MM-DD"Output schema / properties / id / descriptionAdded value: +"Event ID"Output schema / properties / name / descriptionAdded value: +"Event name"Output schema / properties / status / descriptionAdded value: +"Event status after the update"update_menu_item9 fields changedInput schema / properties / is_active / descriptionPrevious value: -"Whether the item stays on the restaurant menu — set false to retire it"New value: +"Whether the item stays on the restaurant menu - set false to retire it"Input schema / properties / is_available / descriptionPrevious value: -"Whether the item can be ordered — set false while out of stock"New value: +"Whether the item can be ordered - set false while out of stock"Input schema / properties / menu_item_id / descriptionPrevious value: -"Menu item ID — from list_menu_items"New value: +"Menu item ID - from list_menu_items"Input schema / properties / restaurant_id / descriptionPrevious value: -"Restaurant ID — from list_school_restaurants"New value: +"Restaurant ID - from list_school_restaurants"Output schema / properties / id / descriptionAdded value: +"Menu item ID"Output schema / properties / isActive / descriptionAdded value: +"Whether the item is on the restaurant menu"Output schema / properties / isAvailable / descriptionAdded value: +"Whether the item can currently be ordered"Output schema / properties / name / descriptionAdded value: +"Item name"Output schema / properties / priceCents / descriptionAdded value: +"Sale price in cents"cancel_event1 field changedInput schema / properties / event_id / descriptionAdded value: +"Event ID — from get_upcoming_events"delete_menu_item2 fields changedInput schema / properties / menu_item_id / descriptionAdded value: +"Menu item ID — from list_menu_items"Input schema / properties / restaurant_id / descriptionAdded value: +"Restaurant ID — from list_school_restaurants"get_daily_menuget_daily_ordersget_menuget_monthly_ordersget_orders3 fields changedInput schema / properties / menu_dateAdded value: +{
+ "description": "Single day to query, YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / monthAdded value: +{
+ "description": "Calendar month to query, YYYY-MM",
+ "type": "string"
+}Input schema / properties / student_id / descriptionPrevious value: -"Filter to a specific student (must be your own)"New value: +"Filter to a specific student (must be your own; from get_user_info)"get_wallet_statusorder_lunch2 fields changedInput schema / properties / menu_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Date the lunch is served, YYYY-MM-DD"Input schema / properties / menu_item_id / descriptionPrevious value: -"Menu item ID from get_daily_menu"New value: +"Menu item ID from get_menu"set_menu_item_pricecreate_event7 fields changedInput schema / properties / description / descriptionAdded value: +"Optional event description"Input schema / properties / ends_at / descriptionAdded value: +"End time (e.g. 20:00)"Input schema / properties / event_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Event date, YYYY-MM-DD"Input schema / properties / location / descriptionAdded value: +"Event location (e.g. Gymnasium)"Input schema / properties / max_capacity / descriptionAdded value: +"Maximum attendees/tickets; omit for unlimited"Input schema / properties / name / descriptionAdded value: +"Event name shown to parents"Input schema / properties / starts_at / descriptionAdded value: +"Start time (e.g. 18:30)"create_menu_item7 fields changedInput schema / properties / calories / descriptionAdded value: +"Calorie count"Input schema / properties / cost_cents / descriptionAdded value: +"Kitchen cost in cents (internal margin tracking)"Input schema / properties / description / descriptionAdded value: +"Optional item description"Input schema / properties / ingredients / descriptionAdded value: +"Ingredient list text"Input schema / properties / name / descriptionAdded value: +"Item display name shown to parents"Input schema / properties / price_cents / descriptionAdded value: +"Sale price in cents (e.g. 550 = $5.50)"Input schema / properties / restaurant_id / descriptionAdded value: +"Restaurant ID — from list_school_restaurants"create_restaurant4 fields changedInput schema / properties / description / descriptionAdded value: +"Optional restaurant description"Input schema / properties / name / descriptionAdded value: +"Restaurant display name"Input schema / properties / school_slug / descriptionAdded value: +"School slug — defaults to the active school"Input schema / properties / tax_percent / descriptionAdded value: +"Sales tax percentage applied to orders (e.g. 5 for 5%)"list_menu_items1 field changedInput schema / properties / restaurant_id / descriptionAdded value: +"Restaurant ID — from list_school_restaurants"set_daily_menu4 fields changedInput schema / properties / available_qty / descriptionAdded value: +"Maximum portions for the day; omit for unlimited"Input schema / properties / menu_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Date the item is orderable, YYYY-MM-DD"Input schema / properties / menu_item_id / descriptionAdded value: +"Menu item ID — from list_menu_items"Input schema / properties / restaurant_id / descriptionAdded value: +"Restaurant ID — from list_school_restaurants"update_event10 fields changedInput schema / properties / description / descriptionAdded value: +"New event description shown to parents"Input schema / properties / ends_at / descriptionAdded value: +"End time (e.g. 20:00)"Input schema / properties / event_date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"Event date, YYYY-MM-DD"Input schema / properties / event_id / descriptionAdded value: +"Event ID — from get_upcoming_events"Input schema / properties / location / descriptionAdded value: +"Event location (e.g. Gymnasium)"Input schema / properties / max_capacity / descriptionAdded value: +"Maximum number of attendees/tickets"Input schema / properties / name / descriptionAdded value: +"New event name"Input schema / properties / starts_at / descriptionAdded value: +"Start time (e.g. 18:30)"Input schema / properties / status / descriptionAdded value: +"Event status — cancelled stops sales, completed closes the event"Input schema / properties / ticket_price_cents / descriptionAdded value: +"Ticket price in cents; 0 for free events"update_menu_item10 fields changedInput schema / properties / calories / descriptionAdded value: +"Calorie count"Input schema / properties / cost_cents / descriptionAdded value: +"Kitchen cost in cents (internal margin tracking)"Input schema / properties / description / descriptionAdded value: +"New item description shown to parents"Input schema / properties / ingredients / descriptionAdded value: +"Ingredient list text"Input schema / properties / is_active / descriptionAdded value: +"Whether the item stays on the restaurant menu — set false to retire it"Input schema / properties / is_available / descriptionAdded value: +"Whether the item can be ordered — set false while out of stock"Input schema / properties / menu_item_id / descriptionAdded value: +"Menu item ID — from list_menu_items"Input schema / properties / name / descriptionAdded value: +"New display name for the item"Input schema / properties / price_cents / descriptionAdded value: +"Sale price in cents (e.g. 550 = $5.50)"Input schema / properties / restaurant_id / descriptionAdded value: +"Restaurant ID — from list_school_restaurants"cancel_eventcreate_eventcreate_menu_itemcreate_restaurantdelete_menu_itemget_daily_orderslist_menu_itemslist_school_restaurantsset_daily_menuset_menu_item_priceupdate_eventupdate_menu_itemget_user_info1 field changedOutput schema / properties / lastNameRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}cancel_ordercreate_draft_orderfinalize_orderget_daily_menuget_monthly_ordersget_ordersget_upcoming_eventsget_user_infoget_wallet_balanceget_wallet_statusorder_lunchregister_eventsign_up_to_volunteer
Add one secure layer between your agents and this server.