Loading ToolBench
Paxaver MCP server — AI-facing adapter over the Paxaver school community operating system. Streamable HTTP, OAuth 2.1, capability-first authorization.
Paxaver MCP shows a mixed profile. Strengths: HTTP transport with proper OAuth 2.1 setup, 27 tools with clear action-verb naming (get_, list_, create_, update_, cancel_, order_, register_, sign_up_for_, pay_, discard_), and documented permission gating (pac_cordinator, event_cordinator roles). Weaknesses: ~40% of tools (22-27) lack visible input schemas in the provided source, only tools 1-10 and 12-21 show explicit schemas; tools 22-27 are documented as having no visible schema definition (empty {} or missing entirely). Descriptions are present and mostly adequate (60-150 chars typical), but many are functional rather than LLM-optimized. Error handling is minimal, no recovery guidance, no retryable/fatal classification. Output schemas not documented. Draft-order tooling shows sophisticated field mapping (camelCase conversion in mapDraftItems) but this complexity is buried in implementation, not surfaced to the LLM. Security model is sound (OAuth 2.1, capability-first authorization, PII filtering in get_my_context) but audit trails and rate limits not mentioned.
Archive a restaurant menu item. Requires pac_cordinator or lunch_cordinator role.
Cancel an event registration.
Cancel an existing lunch order.
Cancel a volunteer shift signup.
Cancel a school event. Requires pac_cordinator or event_cordinator role.
Create a draft lunch order with multiple items.
Six restaurant/menu tools (22-27) lack visible input schemas. Listed as {} or with no parameter definitions in the source. This makes it impossible for LLMs to understand what inputs these tools require or what constraints apply.
update_school_event tool has minimal description (< 20 chars visible) and no parameter schema. LLMs cannot determine which fields it modifies or what inputs are required.
No output schemas documented for any tool. LLMs cannot know what fields to expect from responses, preventing reliable downstream tool chaining and field extraction.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2025-06-18+ | v2 |
Create a new menu item for a restaurant. Requires pac_cordinator or lunch_cordinator role.
Create a new school event. Requires pac_cordinator or event_cordinator role.
Create a new restaurant at a school. Requires pac_cordinator role.
Discard a draft lunch order.
Get the lunch menu for a school.
Get the authenticated user's account context including name, school, students, and roles.
Get the authenticated user's wallet balance.
List the authenticated user's event registrations.
List the authenticated user's lunch orders.
List the authenticated user's volunteer shift signups.
List menu items for a restaurant. Requires pac_cordinator or lunch_cordinator role.
List school events with optional date range filtering.
List restaurants at a school. Requires pac_cordinator, pac_member, or lunch_cordinator role.
Legacy tool: order lunch for a student. Not in the canonical catalog but callable via tools/call for existing integrations.
Finalize and pay for a draft lunch order using wallet funds.
Register for a school event and charge the wallet for paid events.
Schedule a menu item for a specific date. Requires pac_cordinator or lunch_cordinator role.
Sign up for a volunteer shift at an event.
Update items or date in a draft lunch order.
Update a restaurant menu item. Requires pac_cordinator or lunch_cordinator role.
Update an existing school event. Requires pac_cordinator or event_cordinator role.
Error handling is absent. Tools return raw API errors with no recovery guidance, classification (retryable vs. fatal), or actionable next steps. Example: 'User not found' provides no hint to try search_users().
No idempotency or confirmation support for destructive operations. Tools like cancel_my_lunch_order, cancel_school_event, and pay_lunch_order_draft modify state irreversibly with no dry-run, confirmation request, or idempotency key support visible in the descriptions.
Descriptions for restaurant tools are generic ('Create a new restaurant at a school', 'Create a new menu item') with no guidance on required vs. optional parameters, expected format, or when to call each tool. Under 20 chars of actionable detail per tool.
Response filtering logic in get_my_context is sophisticated (PII stripping) but buried in handler code. Not documented in the tool description, so LLMs do not know the fields returned are already filtered or why certain fields (email, phone, address, totp_secret) are omitted.
Default behavior for student_id in order_lunch and create_lunch_order_draft is implicit: 'defaults to the user's only student'. If the user has multiple students, the tool fails silently or requires explicit lookup. Should be documented or made required.
Parameter descriptions in draft-order tools mention field mapping (menuItemId vs. menu_item_id) but LLMs should not need to understand internal camelCase conversion. The tool should accept snake_case (following the naming convention) and handle mapping internally without surfacing the complexity.
No batching support for bulk operations. If an agent needs to register for 10 events or create 5 menu items, it must call the tool 5-10 times sequentially, wasting tokens and latency. Consider batch variants.