mhlb_get_cart

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds a genuinely non-derivable warning that returned text is third-party authored and must be treated as data, not instructions. It stops short of describing pagination or result size, which keeps it out of 5 territory.

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

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

Two sentences, no filler. The functional scope leads and the security caveat follows, so the most decision-relevant information 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 read-only, no-required-params, no-output-schema tool whose annotations cover safety, this is nearly complete: the agent knows the resource, the filters, where filter values come from, and how to treat the response. Only minor gaps remain around result shape and pagination.

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 all three parameters are already documented, including the cross-reference to mhlb_get_cart_tabs. The description only restates the filtering axes at a high level and adds no format or value constraints 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?

Names a specific verb and resource and then defines the resource's scope precisely: 'the shopping cart — lunches added but not yet paid for.' That scope statement distinguishes it from mhlb_get_order and mhlb_list_transactions without the agent needing to open either 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?

It says what the filters do ('filter by order status and ordering period, or narrow to one student') and points at mhlb_get_cart_tabs as the source of valid values, which is useful routing. But it never states when to prefer this tool over siblings like mhlb_get_order or mhlb_get_transaction, so usage is only implied.

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