mhlb_get_cart

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Get' aligns and does not need to repeat safety. The description adds useful context that the cart contains lunches not yet paid for, which clarifies scope. It does not disclose return format, pagination, or any operational nuances beyond that, but with annotations covering safety, the description adds moderate value without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tight sentence that leads with the core purpose, immediately defines the resource, and then lists filter options. Every clause earns its place—no filler, no redundancy. It front-loads the most important information (what the cart is) before optional filters.

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 tool with three optional parameters and no output schema, the description gives a clear purpose and filter options. It omits mention that period and orderStatus values should be sourced from mhlb_get_cart_tabs, but the schema already specifies that, so the agent can discover it. It also doesn't describe the response shape, but without an output schema that might be acceptable. The openWorldHint suggests richer data but isn't elaborated; overall, the description is adequate for correct invocation, with minor gaps like inter-tool dependencies.

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% — each parameter (period, studentId, orderStatus) has its own description. The tool description merely paraphrases filtering ('Filter by order status and ordering period, or narrow to one student') without adding new semantic details like value formats or allowed sources beyond what schema already provides (e.g., orderStatus is tied to mhlb_get_cart_tabs in the schema). Since the schema carries the parameter meaning, 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 uses a specific verb 'Get' and a clearly defined resource: 'the shopping cart — lunches added but not yet paid for.' This distinguishes it from related siblings like mhlb_get_cart_tabs (which returns tab values), mhlb_get_order (which likely deals with placed orders), and transactional tools. The definition of what constitutes the cart is precise and 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 explains what the tool returns (lunches not yet paid for) and states it can be filtered by order status and ordering period or narrowed to a student. While it doesn't explicitly name alternatives, the phrase 'not yet paid for' implies contrast with paid/placed orders, giving contextual guidance. It does not, however, explicitly say when to prefer this over mhlb_get_order or mention that filter values come from mhlb_get_cart_tabs (that is only in the schema).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.