Uber Eats MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Most tools are clearly separated by domain (address, cart, checkout, orders, search, preferences), but there are some ambiguous boundaries. uber_eats_get_address vs uber_eats_saved_addresses vs uber_eats_set_address overlap conceptually, and uber_eats_track_orders vs uber_eats_track_active_orders overlap heavily. Checkout tools (checkout_preview, checkout_savings, set_checkout_tip, set_checkout_payment) are distinct but close enough that an agent could misselect.
Naming Consistency4/5
All tools follow the uber_eats_ prefix with consistent snake_case. Most use verb_noun structure (search, track, view, remove, set). Minor inconsistencies: 'whoami' and 'recommend' and 'reorder' lack a noun object, and 'build_taste_profile' uses adjective rather than a direct action on a noun. Overall naming is quite predictable.
Tool Count3/5
34 tools is on the heavier side. The domain genuinely has many facets (search, browsing, cart, checkout, payment, orders, preferences, recommendations, profiles, favorites), so the count is defensible, but it borders on excessive and could clutter an agent's tool selection. Some tools like track_orders vs track_active_orders could be merged.
Completeness4/5
The coverage is thorough: search, browse, menu, items, cart CRUD, checkout flow, payment, promo, tips, orders tracking, reordering, profiles, preferences, favorites, and recommendations. Minor gaps include lack of explicit remove-payment-method or a dedicated order-cancel tool, and reorder doesn't fully perform the action (only surface items for re-add). Overall the lifecycle from search through ordering to tracking is well covered.
Average 3.9/5 across 34 of 34 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether this is read-only, whether results are paginated, how many results are returned, the ordering of results, or what the output schema looks like. The parenthetical '(API)' hints at a data source but adds little insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose efficiently. There is no wasted verbiage. It could add a couple more useful details (e.g., result count, ordering), but the brevity itself is not a flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and zero parameters, the description is thin. For a zero-parameter retrieval tool, it doesn't explain what to expect from the output (beyond 'recent search queries'), how many items, or whether the results are time-ordered. The output schema exists but the description doesn't orient the agent on what data will come back. Adequate minimum but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema fully covers the parameter surface — there's nothing to document. The description need not add parameter semantics when no parameters exist. The baseline 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recent search queries from the user's Uber Eats search history (API)' identifies the resource (search history) and scope (recent queries). It distinguishes from siblings like uber_eats_search and uber_eats_recommend by focusing on historical queries rather than performing searches. However, it lacks a clear verb and could be more explicit about what 'recent' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't contrast with uber_eats_search (which presumably performs a search) or clarify that this is for retrieving history for analysis/recall rather than executing a new search. The context is implied by the name and description but no when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'direct API' and 'fast results' which hints at behavior but doesn't explain error modes, authentication requirements, or what happens with delivered/cancelled orders. For a 0-parameter tool, there's minimal risk surface, which slightly mitigates the gap, but behavior is still underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, compact and front-loaded with the core purpose first. 'Uses direct API for fast results' is slightly vague filler but not harmful. No waste, though the second sentence adds marginal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, output schema present), so the description covers the essentials. However, the existence of the sibling uber_eats_track_active_orders creates genuine ambiguity about scope that the description doesn't resolve. 'Active and past orders' partially addresses this but could explicitly mention the sibling distinction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is nothing to explain beyond the schema. The rubric gives a baseline of 4 for 0-param tools, and the description adds value by describing what output the user gets (status, restaurant, items, totals). The presence of an output schema covering return values also helps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it tracks 'active and past orders' and lists the data shown (status, restaurant, items, totals). The verb 'track' plus a specific resource is clear. However, it doesn't explicitly distinguish from the sibling 'uber_eats_track_active_orders', though the 'active AND past' phrasing implies broader coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'uses direct API for fast results' but provides no guidance on when to use this vs the sibling uber_eats_track_active_orders. No exclusions, prerequisites, or alternative tool references are given. Given the ambiguity with a nearly identically-named sibling, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states 'Save' implies a write/mutation operation, but doesn't disclose whether the action is reversible, whether favorites already exist are duplicated or deduplicated, whether authentication is required, or what response is returned. For a mutation tool with no annotation coverage, more behavioral transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently organized with a clear Args breakdown. The one-line purpose statement followed by parameter explanations is readable and front-loaded with the core purpose. Slightly verbose with the Args formatting that partially duplicates schema information, but generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with 0% schema description coverage and no annotations, so the description needs to do substantial work. It explains which parameters apply to which kind, which is useful. However, it does not explain return values (though output schema exists), prerequisites like being logged in, or behavior in edge cases like duplicate favorites. For a moderate-complexity tool with a kind-based branching logic, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of documentation. The description does add value by explaining which parameters apply to which 'kind' (uuid/url for restaurants, restaurant for items), which is meaningful guidance beyond the bare schema. This is a good example of the description compensating for schema gaps, though it could be slightly more detailed about required vs optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a restaurant or menu item as a favorite, with a specific verb ('Save') and resource ('restaurant or menu item'). It's distinguishable from siblings which focus on cart management, checkout, search, and profile operations. However, it doesn't explicitly differentiate from any near-sibling like a 'remove_favorite' tool (which doesn't exist), so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Save a restaurant or menu item as a favorite') but provides no explicit when-to-use or when-not-to-use guidance or alternative tool references. The Args section provides some direction on parameter selection based on kind, but there's no explicit guidance on choosing this over other tools, though the sibling list makes it fairly obvious this is the right tool for favorites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does state the operation may fail if invalid/expired, which is a useful behavioral trait. However, it doesn't disclose what happens on success (e.g., response shape, whether it mutates cart totals), what permissions are needed, or whether prior login is required. The error-behavior mention earns partial credit but coverage is thin for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — two sentences plus an args doc. Every line earns its place: it states the purpose, the context, the failure behavior, and the parameter. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though its richness isn't detailed), which reduces the need to explain return values. With one simple parameter, the description is mostly complete. However, as a mutation tool with zero annotations, it lacks info about prerequisites (login, checkout flow position), success effects on cart state, and error handling beyond 'invalid or expired'. For such a simple tool this is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only a single parameter (code) and the description explicitly explains it as a 'Promotion code string' with an example source (email or offers). The description does add meaning beyond the bare schema field title. Baseline for low-coverage would demand compensation, but with only one parameter and a clear semantic explanation provided, this is reasonably covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair: apply a promo code. It also mentions the context (from email or offers) and a fallback behavior (may succeed or return an error). It doesn't explicitly distinguish from siblings, but the action is unique enough among the listed tools that differentiation is less critical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given. The description implies this is for applying promo codes at checkout, but doesn't clarify sequencing (e.g., should be applied before place_order), whether it's needed before checkout_preview, or limitations. The 'from email or offers' hints at source but doesn't guide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It notes '(API)' and 'Requires a non-empty cart' but doesn't state what happens if the cart is empty (error?), whether this is a read-only operation, or anything about the response structure despite an output schema existing. For a tool with zero annotation coverage, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the core purpose. The second sentence adds the prerequisite. No wasted words, though slightly more detail could be included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, so return values need not be explained in the description. The tool is a simple no-parameter fetch operation, so the description covers the essentials: what it does and a key precondition. However, given no annotations and the absence of guidance on error/empty-cart behavior, it's somewhat thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, there's nothing for the tool to document, and schema description coverage is 100%. The baseline is 4 for zero parameters. The description adds context that it operates on the 'current draft order' which is useful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches checkout savings/promo carousel data for the current draft order. The verb 'fetch' plus resource 'checkout savings / promo carousel data' is specific. It also distinguishes from siblings like uber_eats_apply_promo (which applies a promo) and uber_eats_checkout_preview (which previews checkout).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement 'Requires a non-empty cart' provides a clear precondition for when to use this tool. However, it doesn't explicitly state when NOT to use it or name alternatives. Given siblings like uber_eats_apply_promo, the distinction is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It describes what data is returned but does not disclose state changes, whether it requires an active session/page context, rate limits, or what happens when the item has no options. Being a read-only inspection tool, some transparency is implied but not explicit about side-effect-free behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with front-loaded purpose statement, an informative data enumeration, a usage note, and brief parameter descriptions. The parameter details are useful and not wasted, though the mention of 'when API provides them' is slightly verbose. Overall tight and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, so return-value documentation is partially delegated. However, the description doesn't clarify the relationship with menu_item_detail, require/verify preconditions (page state, being on a restaurant page), or explain the pick_one/min/max semantics in practical terms. Given a moderately complex tool with zero annotations and 0% schema coverage of parameters, it is adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains item_name (menu item to inspect) and restaurant_url (optional if not already on page), adding context about the URL's optionality tied to page state. However, it doesn't explain what happens if restaurant_url is omitted when not on the page, and doesn't add format or constraint details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Get customization options for a menu item') and enumerates the specific data returned (sizes, extras, required choices, required, min_permitted, max_permitted, pick_one). It distinguishes from sibling tools like uber_eats_menu_item_detail and uber_eats_restaurant_menu by focusing specifically on customization/options, though it doesn't explicitly come across as distinct from the immediately related ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Call this before add_to_cart if the item has options/modifiers.' This gives explicit when-to-use context and ties it to a specific workflow step relative to sibling add_to_cart. However, it doesn't address when NOT to use it (e.g., when item has no modifiers) or explicitly name alternative tools like menu_item_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Remove' clearly signals a mutating destructive action, but the description doesn't disclose specifics like what happens if the item isn't in the cart, whether quantity matters (does it remove all or one?), or if confirmation is needed. The mutation is implied correctly but thin on detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise - one sentence for the purpose and a single-line parameter description. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating cart operation with no annotations and 0% schema coverage, so the description carries full burden. It fails to cover behavioral edge cases: what happens with quantity (removes entirely vs one instance), behavior for non-existent items, and interaction with add_to_cart/update_cart_quantity semantics. For a destructive cart mutation, this is insufficiently specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It states 'Name of the item to remove' which matches the schema's declared 'item_name' param, but adds no additional semantics like case sensitivity, whether exact name matching is required, or how the name should be obtained (e.g., from view_cart results). Table stakes only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove an item from the cart by name' - specific verb+resource with the removal mechanism (by name). This distinguishes it from sibling tools like add_to_cart, update_cart_quantity, and view_cart, though it doesn't explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action is simple and self-explanatory for when to use it (removing from cart), but there's no explicit guidance on when NOT to use it or interactions with related tools like update_cart_quantity. No mention of prerequisites such as needing an active cart or logged-in session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the tool 'analyzes the menu' and recommends categories (mains, sides, drinks), but doesn't disclose whether it reads-only or writes to cart (the name 'suggest_cart' suggests it suggests rather than adds, but this isn't explicitly stated). Whether it mutates the cart vs. just proposes is ambiguous and should be disclosed given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a one-sentence purpose statement followed by a short Args block. No wasted words or redundant elaboration. It's front-loaded with the core purpose before details. Slightly truncated by the absence of behavioral notes, but what's present is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (presumably describing the suggested cart), hosts 2 parameters, and zero annotations. The description covers purpose and both params, but lacks disclosure about whether suggestions are added to cart or just displayed, what happens if the restaurant_url is invalid, and how preference data is sourced. For a suggestion tool these are meaningful gaps, though the output schema may cover return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for both parameters: restaurant_url is explained as 'Restaurant URL or slug' and social_context as 'Who you're eating with (alone, couple, family, friends)' with illustrative examples. However, the values for social_context are only implied in prose, not enumerated, and the description doesn't fully clarify what constitutes a valid restaurant_url. Acceptable but could go further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Suggest what to order from a specific restaurant based on group size and preferences' with a specific verb+resource (suggest cart for a restaurant) and mentions it 'analyzes the menu and recommends mains, sides, and drinks.' It distinguishes reasonably from siblings like uber_eats_recommend (general recommendations) and uber_eats_restaurant_menu (menu viewing) by being cart-focused. However, it doesn't explicitly contrast with the similarly-flavored uber_eats_recommend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need order suggestions from a specific restaurant for a group), and the social_context parameter signals the grouping use case. However, there's no explicit when-not-to-use guidance or alternatives mentioned, leaving the agent to infer distinction from similar tools like uber_eats_recommend and uber_eats_add_to_cart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the switch affects subsequent operations, whether it requires login, whether there are side effects on cart, or what the return response looks like. For an action tool with zero annotation coverage, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a single purpose line, a usage note, and an Args section. It's efficient and front-loaded. Minor redundancy exists since the Args section restates the label parameter, but overall it's tight and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the prerequisite call and the parameter meaning, which is decent for a single-parameter action tool. There's no output schema content described, though an output schema exists. Given a mutation-type tool with no annotations, it could use more guidance on success/failure behavior and side effects, but the core usage is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter 'label'. It does clarify 'label' as the label or name of the saved address, which adds some meaning beyond the schema's bare 'Label' title. However, it doesn't specify valid value examples or constraints beyond the indicated e.g. 'home', 'work'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches to a saved delivery address by label. The verb 'switch' plus resource 'saved delivery address' gives specific purpose. It distinguishes from siblings like uber_eats_saved_addresses (which lists) and uber_eats_set_address (which likely sets a new/arbitrary address).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs calling uber_eats_saved_addresses first to see available addresses, providing valuable usage context and an implicit prerequisite. It doesn't explicitly state when NOT to use it, but the prerequisite guidance effectively orients the agent on correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It conveys this is a read-only fetch ('Load one menu item'), which is implied. However, it doesn't clarify what customization options are included, whether options data differs from uber_eats_get_item_options, or any pagination/response behavior. The '(API)' suffix is unclear as to what it communicates behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear Args listing that adds param semantics efficiently. The '(API)' suffix and opening sentence are slightly redundant, but overall the text is tight and properly structured with front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, so return-value explanation is not required. The 4 required params are all explained via the Args block and origin note, which is helpful. However, no sibling differentiation against uber_eats_get_item_options and no timing guidance leaves some gaps for a tool fetching customization options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the origin/purpose of each UUID parameter in the Args block (store_uuid=restaurant store, section/subsection/item UUIDs from menu entries), adding meaning beyond the plain 'Uuid' titles in the schema. This is useful guidance for sourcing correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Load one menu item with customization options (API)' with a specific verb+resource, which clearly conveys the purpose. It doesn't explicitly distinguish from sibling uber_eats_get_item_options and uber_eats_restaurant_menu, but the phrase 'with customization options' hints at differentiation from a plain menu fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that 'UUIDs come from uber_eats_restaurant_menu item entries' which implies a dependency/ordering for when to call this tool. However, it doesn't explicitly distinguish from the sibling uber_eats_get_item_options, which sounds potentially related, and doesn't clarify when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the tool opens a headed browser and mutates the address (implied by 'change'), but does not state whether the change persists across sessions, whether it validates the address, or what happens to an invalid address. The headed-browser behavior is a useful disclosure, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two short sentences plus the args block. It front-loads the confirmation requirement and the address-picker behavior. Efficient and appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a single parameter, the description is mostly adequate. However, given 0% schema coverage and no annotations, it would benefit from stating the expected address format more explicitly and noting what happens after the address is set (does it affect active checkout?). The description does note the confirmation requirement and browser behavior, which is decent coverage for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the single 'address' parameter. It states 'New delivery address (street address or landmark)', adding format guidance beyond the bare schema. However, it doesn't clarify whether this should be a full formatted address or just a landmark, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the delivery address with a specific verb and resource. It distinguishes from siblings like uber_eats_switch_address and uber_eats_saved_addresses by noting it uses an address picker via a headed browser. However, it doesn't explicitly contrast with uber_eats_switch_address, so differentiation is partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to always confirm with the user before calling, which is important human-oversight context. Notes it opens a headed browser via the address picker. However, it doesn't explicitly state when NOT to use this vs alternatives like uber_eats_switch_address or uber_eats_saved_addresses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a state-changing operation (switch profile) but doesn't disclose consequences: does it affect subsequent operations, cart contents, or session state? Does it require prior authentication? The only disclosed behavior is that profile_uuid must reference an existing listed profile, which is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — two sentences plus a clean Args block. Every word earns its place, and the docstring-style format is well-structured and front-loaded with the core purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation isn't needed. The tool is simple (1 param, no nested objects), and the description covers what's needed to invoke it correctly. The missing piece is behavioral context (side effects of switching), but for a simple state-switching operation this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that profile_uuid is the UUID from list_profiles — a genuinely useful semantic beyond the schema's bare 'Profile Uuid' title. With only 1 param, the description provides enough to disambiguate, though format validation (e.g., valid UUID format) is not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (switch) and resource (active Uber profile by UUID), distinguishing it from profile-listing (uber_eats_list_profiles) and login tools. It's specific and actionable, though it doesn't contrast against the obvious sibling.list_profiles beyond mentioning it as the source of UUIDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the UUID comes from uber_eats_list_profiles, which implies the sequence of listing then switching. However, it doesn't give explicit when-to-use or when-not-to-use guidance, nor does it address the context where this might matter (e.g., before placing orders or checking whoami).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It hints at being read-only via 'List' and 'which is selected,' which is helpful, but it does not describe the output shape, whether profiles require authentication, or any auth-related prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The first states the purpose and scope; the second gives actionable cross-reference to the switch tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool, the description is reasonably complete: it states what it lists, what selection info is returned, and points to the next-step tool. It could be slightly richer on output format given the presence of an output schema, but the output schema mitigates that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter-documentation burden. Any instruction on what the listing entails is sufficient for a no-arg tool; the description adequately conveys the semantic scope (profiles + selection state).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List Uber account profiles... and which is selected'), clearly distinguishing this read-only listing tool from related siblings like uber_eats_switch_profile and uber_eats_saved_addresses. It names the profile types (Personal, Business, Family) to ground the concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (before ordering, to identify the active profile) but does not explicitly state when-not-to-use or provide alternative selection guidance beyond a single mention of the switch tool. The reference to uber_eats_switch_profile gives a direction but lacks explicit criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does clarify the scope (active only) and notes it's 'lighter' (suggesting reduced payload/complexity), but it doesn't disclose return format details, whether it includes historical data, or the exact statuses covered despite having an output schema that could carry some of that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly-written sentences with zero waste. It states the purpose, scope, and the comparison to the sibling tool efficiently. Front-loaded with the essential info in the first clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provided, the description is largely complete. It names the statuses covered, distinguishes itself from the heavier sibling tool, and the output schema covers return structure. Minor gap: doesn't explain what 'lighter' concretely means (e.g., no itemized details per order) but overall adequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (an empty schema is fully documented). With 0 params, the baseline is 4. The description adds useful context about what the tool returns (active order statuses) even though there's nothing to parameterize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks in-progress/active orders only, with a specific verb (track) and resource (active orders). It provides scope (delivery, preparing, etc.). It's distinguishable from sibling uber_eats_track_orders by noting it's 'Lighter than track_orders,' though it doesn't fully enumerate what track_orders includes beyond not being active-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when you need active/in-progress orders specifically—and contrasts it with track_orders by saying it's lighter. However, it doesn't explicitly state when NOT to use this tool or name the alternative for full order tracking. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. The description implies mutation ('Update') and shows the value format expectations (JSON string for lists/objects, plain string for scalars), which is helpful. However, it doesn't disclose whether keys are validated, what happens on unknown/invalid keys, whether setting preferences requires authentication, or what the response looks like beyond having an output schema. The mutation aspect is clear but the failure/validation behavior is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with the core statement up front, followed by examples and Args. The examples section is the bulk of the text but earns its place by clarifying the dotted-path syntax and value formatting. The Args section slightly overlaps with the schema but adds the JSON-vs-scalar distinction not in the schema. Could be trimmed slightly but is well-structured overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a generic preference-setter with no enums and only 2 params, the description covers the key dimensions: path syntax, value encoding, and common use cases. The output schema exists, so return value documentation is not required. The main gaps are behavioral (validation, error handling for invalid keys) but for a low-complexity tool with good examples, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the schema only provides 'Key' and 'Value' titles with no descriptions), so the description must fully compensate. The description provides rich semantic meaning: the dotted-path convention for key, the value formatting rules (JSON string for complex types), and seven concrete examples covering scalars, nested objects, lists, and currency formatting. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a user preference by dotted key path.' This is a specific verb+resource (update preference) with a precise mechanism (dotted key path). It distinguishes from the sibling 'get_preferences' (retrieval) and other setter tools like set_address/set_checkout_tip by targeting generic key/value preferences. It's clear but could be more distinct about how it differs from the checkout-specific set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The extensive examples implicitly teach when to use this tool by demonstrating the range of preference keys (default_address, default_tip_percent, dietary restrictions, budget, language). The dotted-path convention gives clear context for valid usage. However, there's no explicit 'when not to use' or alternative tool guidance (e.g., when to use set_checkout_tip instead of setting default_tip_percent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It conveys it's a read-only list operation (implied, not explicit), mentions that addresses are labeled, and reveals what kind of data is returned. It doesn't state details like auth requirements, whether this returns default addresses, or format specifics, but given the low complexity it's reasonably adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The description front-loads the core purpose in the first sentence and adds the actionable next step in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema present, the description covers the essential use case well. It explains the purpose and points to the related tool for switching. Given the tool's simplicity and the presence of an output schema, this level of description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. With no params, the baseline of 4 applies. The description adds meaningful context about what's returned (labeled addresses) that supplements the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('all saved delivery addresses') and explains what it returns (labeled addresses like home, work). It distinguishes from sibling uber_eats_get_address implicitly, though it doesn't explicitly contrast with it or other sibling tools like uber_eats_search_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context — it lists all saved addresses and explicitly directs the user to use uber_eats_switch_address to switch between them. This names the relevant next-step alternative. However, it doesn't explicitly state when NOT to use this tool or contrast with uber_eats_get_address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this reads from a 'saved session' and that it operates 'no login browser' (i.e., doesn't trigger interactive browser auth), which is a useful behavioral disclosure. However, it doesn't detail the output structure beyond 'profile info and login status' — though an output schema exists. It doesn't address rate limits or side effects, but for a read-only whoami-style tool this is reasonably complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the core function and key constraint ('no login browser'), and the second provides actionable usage guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only whoami tool with an output schema present, the description covers what's needed: what it does, its non-interactive nature, and how to use it in the login-checking workflow. The only minor gap is not describing what 'login status' values look like in the output, but with an output schema present that's partially covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's nothing for the description to elaborate on. The 100% schema coverage baseline applies; the description correctly communicates the session-based data source. With 0 parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: retrieve current user profile info and login status from the saved session. The verb 'Get' plus the resource 'user profile info and login status' is specific. It distinguishes from siblings by noting it operates on a saved session without opening a login browser, differentiating it from uber_eats_login and uber_eats_list_profiles/switch_profile. However, it doesn't explicitly contrast with the profile/session sibling tools beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use with get_preferences/get_address before deciding whether uber_eats_login is needed.' This clearly tells the agent when to call this tool (early, to check session state) and names the relevant sibling (uber_eats_login) for the alternative path. It lacks explicit when-not guidance but the decision context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral traits: the empty-mood pathway returns mood options, and the craving parameter only applies when mood is 'craving.' It also documents the available enumerated values for mood and social context. It could add what the tool returns (recommendation details, whether it's a read-only operation), but the description adds substantial context beyond what annotations would've provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably tight with a clear opening line, a behavioral conditional (empty mood), and enumerated options. The Args section is redundant with the schema but adds example values, which is valuable. Slightly repetitive (mood enumerated twice - in the options list and in the Args examples) but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return-value documentation) and 3 optional parameters, the description is fairly complete. It covers when to use it, valid parameter values, and the conditional behavior around mood='craving'. It could specify what the output structure looks like or whether recommendations include prices/ratings, but with an output schema present, the description does enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides helpful examples for each parameter ('tired', 'celebrating', 'adventurous' for mood; 'alone', 'family', 'friends' for social_context; 'sushi', 'burgers' for craving), enumerates valid values, and explains conditional use of craving (only when mood='craving'). This significantly enriches the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Get personalized food recommendations based on mood and social context.' The verb 'get' + resource 'recommendations' + scoping by mood/social context is specific. It distinguishes reasonably from siblings like uber_eats_search (which searches for restaurants) and nearby_restaurants, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use, including the empty-mood behavior (returns available mood options) and enumerated valid values for mood and social_context. It explains the craving parameter's role when mood is 'craving.' However, it doesn't explicitly state when NOT to use this tool versus nearby_restaurants or search, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies mutation (setting a tip) which is a write operation, and specifies it affects 'the current draft order' - a useful scoping detail. However, it doesn't disclose error conditions (e.g., what happens if called without a prior preview), reversibility, or whether it's idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is tightly constructed with a clear purpose line, usage prerequisite, and parameter breakdown. No wasted words; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only 2 parameters, the description covers the prerequisite call chain and parameter semantics well. Minor gaps include no mention of edge cases (e.g., applying tip to a non-delivery order) or confirmation behavior, but overall adequate for a focused mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies tip_percent as 'e.g. 10 for 10%' and defines draft_order_uuid as 'from checkout preview', which adds meaning beyond bare parameter names. However, it doesn't specify bounds/valid range for tip_percent beyond the button examples, nor whether fractional percentages are allowed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Set the delivery tip on the current draft order') which clearly distinguishes it from siblings like set_checkout_payment or uber_eats_checkout_preview. It also notes the 'API' context which distinguishes this action from UI-based interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call uber_eats_checkout_preview first and pass the draft_order_uuid from its response, establishing the prerequisite sequence. It also gives concrete tip value examples (0, 5, 10, 15, 20) matching Uber's buttons, but doesn't explicitly say when NOT to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description clarifies this is a state-changing/build action (build/update profile) and mentions it depends on past order history ('Analyze past order history'), implying it reads order data and writes profile state. With zero annotations, this is reasonably transparent, though it doesn't describe idempotency, cost/time, or whether it requires login.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main purpose, then detail outputs, then usage timing. No wasted words, no redundancy with the schema, and each sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which documents return values), zero parameters, and no annotations. The description covers purpose, outputs, and when to call. It could marginally benefit from stating prerequisites (e.g., requires order history) and clarifying the distinction from uber_eats_recommend, but given the tool's simplicity and output schema presence, it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100%, so there's nothing to add about parameter meaning. The description's focus on behavior (analysis, building/updating) substitutes adequately for parameter documentation. A baseline score of 4 for zero-parameter tools is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Analyze past order history and build/update the user's taste profile.' It clearly names what it produces (cuisine preferences, favorite restaurants, ordering patterns) and distinctly differs from siblings like uber_eats_recommend (which suggests items) and uber_eats_get_preferences (which reads stored preferences). Slightly lacking because it doesn't name a sibling for explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Call this periodically or when the user wants updated recommendations.' This tells the agent when to invoke it. However, it doesn't explicitly state when NOT to use it or name alternatives like uber_eats_recommend for getting recommendations vs building the profile, so no explicit exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that this is a local-file read with no browser interaction and no login trigger, which is useful safety context for an agent. However, it doesn't describe what happens if the preferences file is missing, whether it silently defaults, or what the returned structure looks like. The 'No browser' note is genuinely valuable but incomplete on error/fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all earning their place: what it does, what it doesn't do, and when to use it. No fluff, no repetition of the tool name, and the most actionable guidance (call first, then get_address) is front-loaded in the second sentence. Exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, a complex web-flow context (Uber Eats with many sibling tools), and an output schema present (so return values are documented externally), the description covers the key operational facts: it's local, it's the session bootstrap call, and it avoids premature login. The main gap is that it doesn't explain how the agent should validate the returned preferences payload (e.g., what a valid response looks like), but the output schema partially handles that. Reasonably complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters (100% coverage trivially), so the baseline is 4 per the rubric since no schema compensation is needed. The description appropriately focuses on behavior rather than parameters because there are no inputs to document. Nothing more is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this reads a local preferences file containing address label and favorites defaults. It's specific about the resource (local preferences file) and distinguishes itself from sibling tools by explicitly noting 'No browser' and 'local preferences file'. However, it doesn't clearly differentiate from 'set_preference' beyond the read/write distinction, and 'preferences' is somewhat ambiguous about exactly what's contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent usage guidance: 'Call first each session' explicitly states when to use it, and it directly instructs the next step ('then get_address'). It also gives a clear when-NOT-to-use rule by advising to avoid opening login until an API tool proves the session is missing or expired. This is exemplary usage direction that references sibling tools (get_address, login) by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read-only browse action returning open/closed status, which is useful context. However, it doesn't describe location source (current address?), pagination behavior, or what the return payload structure looks like despite having an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose statement followed by a one-line usage note and a single argument documented. Efficient and no wasted words, though it could be slightly tighter (the Args section partly duplicates schema info).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter browsing tool, the description covers the core use case, the differentiating guidance, and the key output signal (open/closed status). A deeper explanation of location behavior would improve it, but given the tool's simplicity and existing output schema, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the limit argument (Max restaurants to return, default 15), which aligns with the schema's default of 15. However, schema description coverage is 0%, meaning the schema's property names carry no additional descriptions. The description adds the semantic meaning for limit but there's only one parameter and it's adequately explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list) and resource (nearby/popular restaurants from the Uber Eats home feed). It distinguishes itself from siblings like uber_eats_search by explicitly targeting the home feed browsing use case and noting it returns open/closed status per restaurant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Good for browsing when the user doesn't have a specific craving,' which directly distinguishes this from search-oriented siblings like uber_eats_search. This gives clear when-to-use guidance and implicitly contrasts with search for specific items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key behavioral trait — that cart mutations still happen in the browser, not through this tool — which is genuinely useful caveat. However, it doesn't describe the return format or error behavior (e.g., what happens if order not found), and with an output schema present, some of that is covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in the first sentence, followed by a workflow caveat and a concise Args section. Every sentence earns its place. Minor deduction: the Args section slightly restates the schema's parameter but adds the provenance hint, so it's justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which covers return values, so the description doesn't need to. For a single-parameter, read-only reorder helper with clear provenance for its input, the description covers purpose, workflow role, and the browser-dependency caveat. It's reasonably complete for this tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only 1 parameter and schema coverage is 0%, so the description must compensate. It explains that order_uuid comes from uber_eats_track_orders, giving provenance and type context beyond the bare string schema. That's good value-add for a single-param tool, though schema itself is trivial to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Look up a past order by UUID and return store UUID + previous line items so the user can open the menu and add items again.' This clearly distinguishes it from siblings like track_orders (tracking) and add_to_cart (mutations). It explains both the lookup and the reorder flow purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is a read-only lookup to support reorder, and it explicitly notes that 'Cart mutations still use the browser until add-to-cart API is captured' — explaining the workflow context and constraints. It implicitly differentiates from add_to_cart by positioning this as a prerequisite step. No explicit when-not-to-use but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the merged feed behavior and describes response JSON structure, which is helpful. However, it doesn't disclose the global scope implications (unlike just nearby), potential rate limits, or whether this requires authentication, though these are somewhat implied by context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with a brief intro, clear bullet-style breakdown of response fields, and an arguments section. Slightly verbose in the introspection of backend endpoints ('getSearchFeedV1, merged with getFeedV1') which may be more detail than an agent needs, but the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema that covers return types, and the description adds value by explaining the semantics of each response section (stores vs items vs feed_item_types) and how to use them downstream. It's complete for a search tool—covers what it returns and how to act on the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (query param has title but no descriptions), yet the description provides detailed args documentation: query is 'Search text (cuisine, store, or product, e.g. 'sushi', 'red bull')' with concrete examples. This fully compensates for the schema gap despite being a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Global Uber Eats search' that mirrors the web search bar flow, naming specific endpoints (getSearchFeedV1, getFeedV1) and describing output structure (stores, items, feed_item_types). The purpose is specific and distinct from the many sibling tools like 'nearby_restaurants', 'restaurant_menu', and 'search_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use items[] for quick add via menu_item_detail/add_to_cart, use stores[] for browsing. It states when to use this vs other pathways, though it doesn't explicitly name alternative tools or say when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It names the underlying API mechanism (PATCH payments profilePatch) for set_as_default, which is useful credential/behavioral context. However, it doesn't disclose whether setting payment is destructive/irreversible, what happens to previously selected payment, rate limits, or auth requirements. The mention of 'toggles Uber Cash/credits' and side-effect behavior of set_as_default adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact with effective use of an Args block for parameter clarification. It's front-loaded with the primary purpose, then tapers to parameter details. Slightly verbose with the 'payments profilePatch' internal detail embedded mid-sentence, but every sentence earns its place in explaining behavior and parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return-value burden is reduced. The description covers dependencies (draft from preview, payment profiles from list tool), optional behavior (credits toggle, default persistence), and side effects (PATCHing account default). Given the medium complexity of 4 params with undocumented schema coverage, the description fills the gap adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates for parameter semantics. It explains each parameter's role: use_credits 'If true or false, toggles Uber Cash/credits; empty leaves unchanged', set_as_default 'persist as default payment on the selected Uber profile'. It correctly documents the empty-string default behavior that would otherwise be ambiguous given the schema's default of ''.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Select payment method for checkout (API)' with specific verb+resource. It distinguishes from siblings by referencing the payment methods list tool and the checkout flow (draft_order_uuid from checkout preview, payment profile from list_payment_methods), situating it precisely in the checkout sequence among many similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear sources for parameter values (payment UUIDs from uber_eats_list_payment_methods, draft_order_uuid from checkout preview), which acts as when-to-use guidance within the checkout pipeline. It doesn't explicitly state when NOT to use it or name alternatives, but the integration context with sibling tools is strongly implied and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses the mutation nature (changing quantity), describes matching behavior (UUID preferred, partial name match fallback), and flags a grocery_store caveat for update failures. However, it doesn't mention edge cases like zero/negative quantity behavior, item-not-found errors, or whether price recalculates—though some of this may be covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opening one-liner, a 'Best/Otherwise' pairing for usage, a conditional tip, then a compact Args list. Every sentence earns its place. Slightly verbose but the info density justifies it—no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params with 0% schema coverage and an output schema present (which likely documents return values), the description covers the important gaps: the identification strategy, fallback matching, and the grocery performance caveat. An output schema being present lowers the bar for describing returns. A strong case for mentioning max quantity limits or confirmation of success is minor next to what's covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. Each of the 4 params is explained beyond the schema: quantity ('1 or more'), item_name ('line title to match if UUID not provided'), shopping_cart_item_uuid ('from view_cart items[] preferred'), and grocery_store ('hint for large markets / grocery carts'). This adds real semantic value the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Change the quantity of a line already in the cart'), explicitly states it uses the same API as the site, and differentiates from siblings (add_to_cart, remove_from_cart, view_cart). The distinction from other cart operations is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on best practice (pass shopping_cart_item_uuid from view_cart) and a fallback (match by item_name, partial match ok). Also gives a conditional hint for grocery stores. It doesn't explicitly name 'when not to use,' but the positive usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It does a good job explaining the safe-skip behavior and the destructive aspect of force=true (clears saved session). However, it doesn't disclose details like how the session file is validated, what happens on login timeout/cancel, or whether credentials are stored server-side beyond the cookie file. The force-clears-session behavioral note is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at roughly 60 words with zero filler. Front-loaded with the core action, followed by the default conditional behavior, then parameter explanation. Every sentence carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a login tool, the description covers the essential behaviors: default skip, force override, session persistence location, and when force is warranted. Given there's an output schema (though unknown content) and the tool is interaction-heavy (user drives the login), the description is appropriately complete. Minor gap: no mention of UI instructions for the user during login.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It does: force's purpose (always run full login flow), its effect (clears saved session), and when to use it (switch accounts, bad cookie). The description adds real semantic value beyond the bare boolean schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (open a browser window) and resource (Uber Eats sign-in), with a clear conditional behavior: returns success without opening a window if a saved session works. It also distinguishes itself from the many sibling tools (whoami, switch_address) by being the authentication entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when the tool opens a window (no valid session, or force=true) versus when it short-circuits (valid saved session). It also gives explicit when-to-force guidance ('switch accounts or recover from a bad cookie file'). It doesn't explicitly name alternative tools, but the use case is clear enough given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait: 'no login browser' - meaning this tool works without requiring authentication. This is valuable context. It doesn't describe pagination or return format, but for a zero-parameter getter that returns the current address, this is largely sufficient. However, it doesn't explicitly state whether the call is read-only (though implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place. The first sentence states purpose, the second gives usage guidance with explicit precedence over uber_eats_login. Zero waste, front-loaded with the core purpose. Excellent structure for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter getter with an output schema present. The description is complete for the agent's needs: it explains what it returns, that it works without login, and when to prefer it. The only minor gap is not describing what the output structure looks like, but since an output schema exists, the description needn't explain return values. Given its simplicity, this is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the schema has nothing to document, so baseline is 4. The description provides context on what the returned value represents (current delivery address from saved config), which adds meaning beyond the empty schema. No parameter detail is needed since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: retrieves the current delivery address from saved session/config. It distinguishes it well from siblings like uber_eats_saved_addresses and uber_eats_set_address by emphasizing it reads from saved session/config without login. The phrase 'current delivery address' is specific and clear, though it could be slightly more explicit about being a read-only getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Prefer this (with get_preferences) before uber_eats_login when starting a chat.' This provides a clear precedence instruction and names the companion tool (get_preferences) and the alternative to avoid (uber_eats_login). This is excellent usage guidance that maps to the 'when to use' dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds useful behavioral context: it's a read-only list operation requiring cart state, and it's explicitly tied to the checkout flow. The only minor gap is not stating the output format explicitly, but an output schema exists, partially mitigating this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste. Every sentence provides value: what it does, a precondition, and when to use it. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params) and has an output schema, so the description doesn't need to explain return values. The description conveys purpose, precondition, and usage timing. Given the tool's simplicity and the sibling context, this is reasonably complete, though it could note that it's distinct from set_checkout_payment (which actually selects a method vs. listing them).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, making parameter semantics largely moot. The baseline for 0-param tools is 4. The description does add useful context about why there are no parameters (the methods are determined by the current cart state), which helps the agent understand the tool's statelessness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'List eligible payment methods for the current cart (checkout API).' The verb+resource is specific and unambiguous. It also clarifies scope ('for the current cart'), distinguishing it from potential sibling tools that handle other checkout aspects like set_checkout_payment or set_checkout_tip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition ('Requires items in the cart') and suggests when to use it ('Use after add_to_cart or when checkout fails'). It doesn't explicitly name alternative tools for cases where payment methods are NOT needed, but the context is clear enough for an agent to determine when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains the tool returns cart data for review purposes and previews that UUIDs will be needed for subsequent cart modifications, which is useful operational context. It doesn't mention auth requirements or whether the cart must be non-empty, but the read-only nature is implied by 'view'. Having an output schema also reduces the burden on the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero waste. Every element earns its place: what's returned, when to call it, and how to use the returned UUIDs. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter view tool with an output schema, the description is complete. It covers the return contents, temporal usage guidance (before checkout), and downstream usage pattern (UUIDs for quantity changes). The output schema handles return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there are no parameter semantics to explain. Per the rubric, 0 params receives a baseline of 4. The description effectively focuses on what the tool returns rather than parameters, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it views the current cart and lists exactly what it returns: line titles, quantities, shopping_cart_item_uuid per line, and draft_order_uuid. This distinguishes it clearly from sibling tools like add_to_cart, remove_from_cart, and update_cart_quantity which are mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call before checkout so the user can review' which provides clear temporal context for when to use this tool. It also instructs to 'use UUIDs when changing qty', pointing toward the sibling update_cart_quantity tool. It lacks explicit 'when not to use' guidance but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important behavior: the server auto-resolves section/subsection UUIDs, fixes wrong search data automatically, and uses fuzzy matching on the fallback path. It does not describe auth requirements or what happens on failure, but the behavioral disclosure is substantial for the mutation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear priority sections (Best/Optional/Fallback) and bullet-point args. Slightly long but every sentence adds value—the implementation details (addItemsToDraftOrderV2, getMenuItemV1, getStoreV1) and the 'never the same as store_uuid' warning are genuinely useful, not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers the complex 7-parameter multi-path API thoroughly: priority resolution, auto-fix behavior, customization prerequisite, and parameter relationships. With an output schema present, lack of return-value explanation is acceptable. Could mention error cases or payment requirements, but the core execution flow is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 7 parameters, so the description must fully compensate—and it does. Each parameter gets a meaningful explanation (e.g., 'section_uuid: Catalog section UUID (never the same as store_uuid; optional if resolvable from menu)'), adding relationships, defaults, and usage conditions beyond what the bare schema titles provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Add a line via addItemsToDraftOrderV2 + getMenuItemV1') and covers both restaurant and grocery contexts. It differentiates from siblings like uber_eats_remove_from_cart and uber_eats_update_cart_quantity by focusing on adding a new line item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit priority guidance: best path (store_uuid + menu_item_uuid), optional fields, and fallback (restaurant_url + item_name). Explicitly instructs when to call uber_eats_get_item_options first for required customizations. Includes the critical warning that section_uuid is never the same as store_uuid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It proactively discloses a key behavioral trait: the payload can exceed the client's tool limit for large stores (100k+ chars). This is meaningful context an agent needs before invoking. It doesn't mention authentication requirements or rate limits, but the single most consequential behavior—payload size risk—is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very tight and well-structured. The warning and usage direction are front-loaded, and the args detail is efficient. It covers purpose, exclusions, alternative guidance, and parameter semantics in ~45 words. Minor deduction only because the parameter description could arguably be inline in a separate line, but the current structure is near-optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, this is a powerful and complete tool. The one parameter is fully documented, the performance/limit risk is flagged with a practical mitigation path, and there's an output schema available. The complexity here is moderate (single param), but the description fully covers usage caveats and alternatives, leaving nothing critical undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there's one required param (restaurant_url). The description explains the full semantics: it accepts either the full URL (with example format https://www.ubereats.com/store/...) or a restaurant slug. This adds substantial meaning beyond the schema, which only says 'Restaurant Url'. The description fully compensates for the zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the full menu for one store (specific verb: returns menu; specific resource: one store). It distinguishes itself from siblings by explicitly warning against use for supermarkets and directing to uber_eats_search and item-level tools instead, which differentiates it from uber_eats_menu_item_detail and uber_eats_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent guidance. It explicitly says when NOT to use (supermarkets/groceries with huge payloads) and directs to alternatives (uber_eats_search first, then item-level tools). This explicit when/when-not with named alternative tools is exemplary and exceeds all sibling definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses behavior: the tool is non-mutating (does NOT place order), requires confirmation flow, and defines a step-by-step interaction contract. The 'MUST' list details the exact behavioral requirements an agent must follow, which fully compensates for absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first line. The numbered list is well-structured. While everything earns its place, the list could be slightly tightened; however, given the interaction contract requires clear steps, the verbosity is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, workflow-critical tool (pre-checkout step in a multi-step ordering process). The description fully covers the confirmation flow, what belongs in the summary, and the ordering constraint relative to place_order. The output schema exists, so return values need no additional explanation. Complete for the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there's no param burden to carry. The description's baseline is 4 for a zero-parameter tool, and it adds no misleading param info. It appropriately focuses on process rather than parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'previews the order with full price breakdown' and explicitly notes it 'does NOT place the order,' distinguishing it from uber_eats_place_order among siblings. The contrast with place_order is implicit but clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it ('always call this before place_order'), provides a numbered workflow (show summary, ask payment, ask tip, show total with tip, ask explicit confirmation), and specifies NOT to call place_order until explicit confirmation. This is exemplary when-to-use guidance with clear exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the fallback behavior (API first, then browser click), and critically warns this is an irreversible/committing action requiring explicit user confirmation. It does not detail what happens on success/failure or whether the order is trackable afterward, but the core behavioral traits (irreversible, requires confirmation, dual execution path) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with a bold requirement header, a numbered checklist, and a clear exclusion sentence. Every line earns its place — no fluff, no repetition. The formatting (all-caps pointers, numbered prerequisites) makes it scannable for an agent processing it under decision pressure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-stakes, stateful, side-effect-laden tool with zero annotations and zero parameters. The description compensates comprehensively: it details prerequisites, exclusions, implementation strategy, and the confirmation contract. The presence of an output schema means return values need no explanation. Nothing meaningful is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there's nothing to document. The baseline for 0-param tools is 4, and the description actually exceeds it by clarifying that the order context comes from prior tool calls (checkout_preview, payment method, tip, total) — making the implicit stateful contract explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (place order) and resource (Uber Eats cart/checkout), plus specifics about the implementation approach (tries checkoutOrdersByDraftOrdersV1 first, then browser click). It distinguishes itself from siblings like checkout_preview (which previews) and set_checkout_tip/payment (which configure) by being the final commit action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides exhaustive usage guidelines: a numbered list of ALL preconditions that must be true before calling, and explicit exclusions ('cancel', 'no', 'wait', or uncertain). This is the strongest possible when-to-use guidance and clearly establishes this as a final, guarded action distinct from other checkout tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![uber_eats_mcp MCP server](https://glama.ai/mcp/servers/matiasconcha11/uber_eats_mcp/badges/card.svg)](https://glama.ai/mcp/servers/matiasconcha11/uber_eats_mcp)

Score Badge

Copy to your README.md:

[![uber_eats_mcp MCP server](https://glama.ai/mcp/servers/matiasconcha11/uber_eats_mcp/badges/score.svg)](https://glama.ai/mcp/servers/matiasconcha11/uber_eats_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/matiasconcha11/uber_eats_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server