Read Parsley menu items, nutrition, allergens, ingredients and events; record event sales and waste.
Scored across 15 tools
Tools are cleanly separated by resource (event, menu, menu item, ingredient) and by operation (list vs get vs create), and the three write tools target distinct payloads. Minor overlap: parsley_list_menu_items includes recipes, sub-recipes and ingredients, which could be conflated with parsley_list_ingredients, but descriptions make the boundary clear.
Every tool uses the same parsley_ prefix plus a consistent snake_case verb_noun pattern (create_event, get_event, list_events, record_event_sales, update_event_covers). No mixed conventions or vague verbs.
15 tools is at the top of the well-scoped range and each one maps to a concrete API endpoint/action. Read tools for the catalog plus focused event write tools, with no filler.
Catalog reads (menu, menu items, ingredients, tags, stations) and event lifecycle (create, get, list, covers, sales, waste) are covered well. Gaps exist: no delete/rename event, no way to modify an event's menu items after creation, and read-only catalog with no update/create for menu items or ingredients.
WRITE: create an event (a workday, shift, service or catering event) in Parsley with its menu items. This changes the account's production plan and is NOT idempotent: calling it twice creates two events. Returns the new event id. Use parsley_list_events first to avoid duplicates. POST /events.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The day of the event, yyyy-mm-dd. | |
| name | Yes | Event name, e.g. 'Brunch'. | |
| type | Yes | Event type: standard, cafe-hot-bar, sale or forecast. | |
| menu_id | No | Parsley menu id the event uses (from parsley_list_menus). | |
| private | No | Mark the event private. | |
| end_time | No | Time of day, HH:mm (24 hour). | |
| line_items | Yes | The menu items and amounts to produce or sell (may be empty). | |
| start_time | No | Time of day, HH:mm (24 hour). | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, but the description adds the operational meaning of those flags: calling twice creates two events and mutates the account's production plan. It also discloses the return value ("Returns the new event id") in the absence of an output schema. Auth requirements and side effects on dependent resources (e.g. inventory deduction) are not covered, keeping it below 5.
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 dense clauses with zero filler: the WRITE prefix, the definition, the risk warning, the alternative, and the endpoint are all front-loaded and each 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 9-parameter write tool with no output schema, the description covers the mutation's effect, its non-idempotent failure mode, the duplicate-prevention path, the returned identifier, and the underlying endpoint. Nothing essential for correct invocation 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 89% and the nested line_items fields are documented in the schema itself, so the schema carries essentially all parameter meaning. The description only obliquely signals that menu items are part of the payload ("with its menu items") without adding semantics beyond the schema, which matches the baseline 3.
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?
Opens with an explicit verb and resource ("WRITE: create an event") and clarifies the resource scope ("a workday, shift, service or catering event") plus the payload content ("with its menu items"). No sibling tool creates events, so the agent can distinguish this immediately from the get_/list_/record_ siblings.
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?
Names the concrete alternative and the condition that selects it: "Use parsley_list_events first to avoid duplicates." Combined with the stated non-idempotency consequence, an agent has everything it needs to decide whether to check before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event with its metadata and all line items (menu item, amount, unit, station, section). GET /events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Parsley event id (from parsley_list_events). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral value by disclosing the exact endpoint and that the response includes all line items, which tells the agent this is a detail-heavy read rather than a lightweight lookup.
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 two compact sentences with zero filler. It front-loads the core behavior (one event plus line items) before appending the endpoint reference.
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?
With no output schema, the description compensates well by listing the returned line-item fields and metadata. It is nearly complete for a simple single-id getter, though it leaves open details like pagination or absent-event behavior that an agent might wonder about.
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?
There is a single required event_id parameter with 100% schema description coverage, and the schema note even says it comes from parsley_list_events. The description itself adds no meaning beyond the schema, so the baseline of 3 is appropriate when structured fields carry the parameter story.
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-resource pair ("One event") and details the returned payload (metadata and all line items with item, amount, unit, station, section), plus the backing endpoint GET /events/{id}. It distinguishes itself implicitly from the list endpoint by emphasizing a single event, though it does not name parsley_list_events as the sibling alternative.
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?
Usage is only implied: retrieving a single event by id. The description gives no explicit guidance on when to choose this tool over parsley_list_events or the other sibling getters, and it does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One ingredient in full: unit conversions, supported units, tags, the supply options (supplier, SKU, pack size, cost) used for costing and the preparations with yield. Parsley limits this call to 1 request every 3 seconds, so fetch ingredients one at a time. GET /ingredients/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient_id | Yes | Parsley ingredient id (from parsley_list_ingredients). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, and openWorld=true, so safety is covered. The description adds a concrete behavioral constraint the annotations do not carry: a rate limit of 1 request every 3 seconds, which directly shapes how an agent should batch calls.
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, front-loaded with what is returned and followed by the throttle constraint and endpoint. The enumeration is dense but every item conveys real payload content, so there is little waste.
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?
With no output schema, the description must describe return contents and it does thoroughly, plus it discloses the rate limit. Only minor gaps remain, such as behavior on an invalid or unknown id.
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% and the single ingredient_id parameter is documented there, including its origin (from parsley_list_ingredients). The description adds no further semantics about the id, so the baseline of 3 applies.
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+resource (get one ingredient) and enumerates exactly what it returns: unit conversions, supported units, tags, supply options with supplier/SKU/pack size/cost, and preparations with yield. That level of detail clearly separates it from parsley_list_ingredients and the menu/event siblings.
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 an operational rule ('fetch ingredients one at a time' due to the 3-second throttle) and the schema note points back to parsley_list_ingredients as the id source, but there is no explicit statement of when to prefer this over alternatives or what preconditions apply beyond the id requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the chef tags (id, name) that recipes are attributed to. Only meaningful for accounts with Chef IDs enabled. GET /tags/chefs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results to return, 1-500 (default 100). | |
| offset | No | Skip this many results (default 0). Pass the previous reply's next_offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral fact (account-level prerequisite), but nothing about pagination limits, empty results, or ordering beyond what the schema and endpoint imply.
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, front-loaded with the resource description and the eligibility caveat. The trailing 'GET /tags/chefs' is largely redundant with the title and siblings, but costs only a few tokens.
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-optional-parameter list tool with no output schema, the description tells the agent what comes back (id, name) and when the tool applies. Pagination mechanics live in the schema, so the remaining gap is minor.
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%, with limit (1-500, default 100) and offset ('pass the previous reply's next_offset') fully documented in the schema. The description adds no parameter meaning at all, so the baseline of 3 applies.
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 and resource ('List the chef tags') and even names the returned fields (id, name) plus the underlying endpoint GET /tags/chefs. It is unambiguous against siblings since no other tool touches tags, but it never explicitly distinguishes itself from those siblings.
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?
'Only meaningful for accounts with Chef IDs enabled' is a real eligibility condition that prevents wasted calls. What is missing is any routing guidance (e.g., pairing with parsley_list_chef_users or how to resolve a tag id to recipes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the chef users of the account: id, email, join date, active flag, permission level and the chef tag they are tied to. Only meaningful for accounts with Chef IDs enabled. GET /users/chefs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results to return, 1-500 (default 100). | |
| offset | No | Skip this many results (default 0). Pass the previous reply's next_offset. | |
| search | No | Only chef users (matched on email or chef name) whose name contains this text (case-insensitive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the description need not restate it. The description adds the underlying endpoint (GET /users/chefs) and the returned field set, but says nothing about pagination behavior, volume, or what an empty result means for a non-Chef-ID account.
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 with the field list front-loaded and the precondition immediately after; nothing is padded. The trailing "GET /users/chefs" is a small implementation detail but costs little.
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?
With no output schema, the enumeration of returned fields (id, email, join date, active flag, permission level, chef tag) fills the biggest gap an agent would otherwise have. Pagination is documented in the schema rather than the description, so the only real omission is what a caller should do when the account lacks Chef IDs.
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% and all three parameters (limit, offset, search) are fully documented in the schema, including the next_offset handoff, so the description rightly does not repeat them. It adds no semantics beyond the schema, which is the baseline case.
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 and resource ("List the chef users of the account") and enumerates the returned fields, so the agent knows exactly what data comes back. It never names a sibling, so the agent must infer that parsley_list_chef_tags covers tags rather than users, but the name and field list make the scope 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?
"Only meaningful for accounts with Chef IDs enabled" is a genuine precondition that tells the agent when this tool is worthless, which is more than most list tools offer. It stops short of naming alternatives (e.g. parsley_list_chef_tags) or saying how to detect whether Chef IDs are enabled, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List events (a workday, shift, service or catering event) that fall in a date window: id, name, type (standard, cafe-hot-bar, sale, forecast), date, start and end time, menu id. A bare date means the whole day in the account timezone. GET /events.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Window end (inclusive): yyyy-mm-dd (to the end of that day) or an ISO 8601 date-time. | |
| type | No | Only this event type. | |
| limit | No | Results to return, 1-500 (default 100). | |
| start | Yes | Window start (inclusive): yyyy-mm-dd or an ISO 8601 date-time. Without a timezone the account timezone applies. | |
| offset | No | Skip this many results (default 0). Pass the previous reply's next_offset. | |
| search | No | Only events whose name contains this text (case-insensitive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context: bare-date semantics in the account timezone, the returned fields, and the underlying GET endpoint.
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 and compact: one dense sentence states the operation, scope, event types, and returned fields, followed by the endpoint. No sentence is wasted.
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?
Despite having no output schema, the description lists the returned fields and explains the key date-window semantics. Combined with the fully documented input schema and safety annotations, it is complete enough 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?
Schema description coverage is 100%, so the schema already explains all six parameters in detail. The description reinforces the date-window behavior and event type values, but adds little parameter meaning beyond what the schema 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?
The description uses a clear verb and resource ("List events") and defines the scope as events falling in a date window. It also names the event kinds covered, though it does not explicitly differentiate itself from the singular get_event sibling.
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 date-window and event-type filter provide implied usage context, but there is no explicit guidance on when to use this tool versus get_event or other event tools. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ingredients that can be used in recipes: id, parent id, name, label name, item number, supported units, and whether a recipe uses it. The API returns the whole list at once; search/limit/offset slice it here. GET /ingredients.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results to return, 1-500 (default 100). | |
| offset | No | Skip this many results (default 0). Pass the previous reply's next_offset. | |
| search | No | Only ingredients whose name contains this text (case-insensitive). | |
| used_by_recipe | No | true: only ingredients used by a recipe; false: only unused ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, so the bar is lower. The description adds non-obvious context: the API returns the entire list in one call and filtering/paging happens on this side, which shapes how an agent should size requests.
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: fields returned, paging behavior, and endpoint. It is front-loaded and there is no 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?
With no output schema, it usefully enumerates the returned fields and explains paging semantics. It stops short of noting the default page size or pointing to the single-item sibling, but nothing essential for a correct call 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 baseline is 3. The description adds a semantic nuance beyond the schema by clarifying that limit/offset/search act as post-hoc slicing over the full list rather than server-side query parameters.
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 and resource ('List the ingredients that can be used in recipes') and enumerates the returned fields, which distinguishes it well from parsley_get_ingredient. It never explicitly contrasts with the singular sibling, so the differentiation is implicit rather than stated.
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 sentence about the API returning the whole list while search/limit/offset slice it 'here' implies when to use this tool for browsing/paging. However, it gives no explicit guidance on choosing it over parsley_get_ingredient for a single lookup, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the serving stations (id, name) that menu items and event line items can be assigned to. GET /tags/serving_stations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results to return, 1-500 (default 100). | |
| offset | No | Skip this many results (default 0). Pass the previous reply's next_offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and return-field context, but does not add meaningful behavioral details beyond that and the schema.
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: one sentence explains the resource and its use, followed by the endpoint. There is no unnecessary text.
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 read-only list tool with fully documented parameters and annotations, the description is largely complete. It also names the returned fields, which helps compensate for the absence of an output schema.
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%, and both limit and offset are fully documented in the schema. The description does not mention parameters, which is acceptable given the schema already carries that information.
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 and resource ('List the serving stations') and clarifies the resource's role for menu items and event line items. It also gives the returned fields (id, name), though it does not explicitly differentiate this from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is relevant by explaining that serving stations are assignable to menu items and event line items, but it does not specify when to use this versus related listing tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: push sold quantities per menu item to a cafe/hot bar event, which feeds Parsley's cost and usage reports. Other event types are refused by Parsley, as is a menu item with no made quantity on the event. Sending the same quantities again overwrites rather than adds. PUT /events/{id}/sales.
| Name | Required | Description | Default |
|---|---|---|---|
| sales | Yes | Sold amount per menu item. | |
| event_id | Yes | Parsley event id of a cafe/hot bar event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=true; the description corroborates these by stating that identical quantities overwrite rather than add. It adds real value beyond the annotations by disclosing server-side rejection rules (wrong event type, item with no made quantity) and the underlying PUT endpoint. It doesn't cover auth needs or error payloads, so it is not a 5.
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 sentences, front-loaded with 'WRITE:' to flag the operation class, then payload purpose, then refusal and overwrite semantics, then the endpoint. No filler and no repetition of schema detail.
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?
With no output schema and only a nested array payload, the description supplies the write semantics, rejection conditions, and idempotency behavior an agent needs to call it correctly. It is slightly thin on what a successful response looks like and on what 'made quantity' means operationally, which keeps it from a 5.
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%, including the uom list, amount bounds, and the item_id-vs-menu_item choice, so the schema carries parameter meaning. The description only summarizes the payload as 'sold quantities per menu item' and adds no syntax or selection guidance beyond that. Baseline 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 opens with an explicit verb-and-resource statement ('push sold quantities per menu item to a cafe/hot bar event') and states the downstream purpose (cost and usage reports). It also distinguishes this write from the other event-related siblings by scoping it to cafe/hot bar events that have made quantities.
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 gives concrete preconditions: only cafe/hot bar events are accepted, and every menu item must have a made quantity or Parsley refuses the call. It also states the overwrite-not-accumulate rule, which tells the agent how to re-send data. It does not explicitly route to a sibling tool as an alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: push waste and/or leftover quantities per menu item to a cafe/hot bar event. If no sold quantity exists, Parsley derives it as made minus waste minus leftover. Parsley refuses amounts above what was made minus sold. Sending the same quantities again overwrites rather than adds. PUT /events/{id}/waste_leftover.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| event_id | Yes | Parsley event id of a cafe/hot bar event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, and the description corroborates and enriches that: same quantities overwrite rather than add, the server derives sold as made minus waste minus leftover, and the server rejects amounts exceeding made-minus-sold. That is real server-side behavior beyond the flags, though permission requirements and the response shape are unmentioned.
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?
Five short sentences, front-loaded with the WRITE marker and the resource, then escalating to derivation rule, validation rule, overwrite semantics, and endpoint. No filler and no repetition of schema 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?
For a nested, destructive write tool with no output schema, the description covers mutation semantics, idempotency behavior, and the key server-side validation error an agent will hit. What's missing is any hint of the success response or whether partial item failures are possible when up to 500 items are sent.
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 roughly 50% (section and station are undocumented, the amount/uom fields carry their own descriptions), so the description only needs to add the 'and/or' semantics — that waste_amount, leftover_amount, and their uoms are independently optional per item. It does that, but gives no guidance on the section/station fields or on how amounts interact with the chosen uom.
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?
Opens with an explicit 'WRITE:' verb marker and names the resource precisely: waste and leftover quantities per menu item on a cafe/hot bar event. It also pins the endpoint (PUT /events/{id}/waste_leftover), so an agent can trivially distinguish it from sibling writers like parsley_record_event_sales or parsley_update_event_covers.
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 cafe/hot-bar-event scope is stated, which implicitly rules out other event types, and 'waste and/or leftover' tells the agent it may supply either or both. But no sibling is named as an alternative and there is no explicit when-not guidance (e.g. use record_event_sales for sold counts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: set the forecast and/or actual number of covers (guests served) on an event. Only the fields you pass change. actual_covers works only on cafe/hot bar events. Setting the same values again has no further effect. PATCH /events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Parsley event id. | |
| actual_covers | No | Real number of covers (cafe/hot bar events only). | |
| forecast_covers | No | Predicted number of covers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare write, destructive, idempotent and open-world hints, so the description only needs to add context – which it does, by spelling out PATCH-style merge behavior and the cafe/hot bar restriction on actual_covers. It does not cover what an overwrite destroys (e.g. prior forecast values being replaced) or any auth requirements, leaving some room above the annotation floor.
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, front-loaded with the WRITE marker and the core action, then the constraint, the idempotency note and the endpoint. Nothing is padded and each sentence adds a distinct fact.
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 three-parameter partial-update call with no output schema, the description covers the essential risks: applicability restriction, merge semantics and idempotency. The remaining gap is the response shape after the PATCH and whether prior values are recoverable.
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 all three parameters are already documented, including the cafe/hot-bar constraint on actual_covers. The description's parameter-related content largely restates that schema text; the one genuine addition is confirming that omitted optional fields are left untouched, which is only a marginal gain.
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 and resource ('set the forecast and/or actual number of covers on an event') with an explicit WRITE marker and the underlying endpoint (PATCH /events/{id}). This clearly distinguishes it from siblings like parsley_record_event_sales or parsley_create_event, which also touch events.
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 clear operating conditions: partial-update semantics ('Only the fields you pass change'), a hard applicability rule ('actual_covers works only on cafe/hot bar events'), and idempotency ('Setting the same values again has no further effect'). It stops short of naming alternatives or when-not-to-use cases, e.g. whether forecast covers should be set here versus at creation time.
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.
parsley_create_eventparsley_get_eventparsley_get_ingredientparsley_get_menuparsley_get_menu_itemparsley_list_chef_tagsparsley_list_chef_usersparsley_list_eventsparsley_list_ingredientsparsley_list_menu_itemsparsley_list_menusparsley_list_serving_stationsparsley_record_event_salesparsley_record_waste_leftoverparsley_update_event_coversThe brain for restaurant costs, pricing, and true profit (read/edit menu, recipes, costs).
Read Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Read Farmbrite livestock, crops, tasks, inventory and orders; log records and tasks.
Query Loyverse POS receipts, shifts, items, inventory and customers, and update stock and customers.
Add one secure layer between your agents and this server.
