Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@striderlabs/mcp-chipotle Find Chipotle locations in San Francisco"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Chipotle — let AI agents find locations, browse menus, build custom orders, and checkout for pickup or delivery.
🌯 Full order building — bowl, burrito, tacos, salad, quesadilla
🥑 Complete customization — protein, rice, beans, salsas, toppings
📍 Location search — find nearby Chipotle restaurants
🏆 Rewards — check Chipotle Rewards points and available offers
🛍️ Bag management — view and manage your current order
🚗 Pickup & delivery — checkout for either fulfillment method
📦 Order tracking — track status of placed orders
🔐 Session persistence — cookies saved at ~/.striderlabs/chipotle/cookies.json
Related MCP server: OrderFood MCP
npm install -g @striderlabs/mcp-chipotle
npx playwright install chromiumAdd to your claude_desktop_config.json:
{
"mcpServers": {
"chipotle": {
"command": "striderlabs-mcp-chipotle"
}
}
}Tool | Description |
| Check connection and login status |
| Authenticate with Chipotle credentials |
| Clear session cookies |
| Find nearby Chipotle restaurants |
| Get details for a specific location |
| Get full menu with prices and calories |
| Get saved favorite orders |
| Begin building a new order |
| Add protein, rice, beans, toppings |
| Add customized item to bag |
| View current bag contents |
| Place order for pickup or delivery |
| Track order status |
| Check Chipotle Rewards balance |
1. chipotle_status → check if logged in
2. chipotle_login → authenticate (if needed)
3. chipotle_search_locations address="94105"
4. chipotle_get_menu → see all options
5. chipotle_start_order entreeType="bowl"
6. chipotle_customize_item protein="chicken" rice="white" beans="black" toppings=["guac","salsa-mild","cheese"]
7. chipotle_add_to_bag quantity=1
8. chipotle_view_bag → review order
9. chipotle_checkout fulfillment="pickup" confirm=false → preview
10. chipotle_checkout fulfillment="pickup" confirm=true → place order
11. chipotle_track_order → track statusBrowser automation: Playwright (Chromium) with stealth patches
Session persistence: Cookies stored at ~/.striderlabs/chipotle/cookies.json
Transport: MCP stdio
MIT — Strider Labs
Add the currently configured item to your bag. Call after chipotle_start_order and chipotle_customize_item.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Number of this item to add (default: 1) |
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 only states the action without detailing side effects (e.g., whether it appends or replaces items, requires an existing bag), error conditions, or confirmation of success. For a mutation tool, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence directly states the purpose, and the second provides essential sequential guidance. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers the basic action and sequence but lacks details on default behaviors (e.g., quantity defaults to 1), return values, or error states. It is minimally complete but not fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the quantity parameter. The tool description does not add any extra meaning beyond the schema; therefore, it meets the baseline score of 3. No additional parameter context is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('the currently configured item to your bag'), and the sibling tools confirm distinct purposes like viewing bag or checkout. The mention of calling after chipotle_start_order and chipotle_customize_item adds clarity on the workflow context, though it could be more explicit about the scope of 'currently configured item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the sequential dependency: 'Call after chipotle_start_order and chipotle_customize_item.' This provides clear context for when to use the tool. However, it does not mention when not to use it or list alternative tools like chipotle_view_bag for checking bag contents, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checkout and place your Chipotle order. Set confirm=false to preview the order first, confirm=true to actually place it.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to place the order, false to preview only (default: false) | |
| pickupTime | No | Desired pickup time (e.g., 'ASAP', '6:30 PM') | |
| fulfillment | Yes | Order fulfillment method | |
| deliveryAddress | No | Delivery address (required if fulfillment is 'delivery') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description reveals dual mode (preview vs place) via confirm flag, but lacks details on side effects like payment, cancellation, or irreversible actions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by critical confirm parameter guidance. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavior and confirm flag, but missing details on return values (since no output schema) and conditional requirements like delivery address. Adequate for a checkout tool but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. The tool description adds context about confirm's behavior (preview vs place), but adds little to other parameters beyond what schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's action (checkout/place order) and resource (Chipotle order), distinguishing preview vs actual placement. Differentiates from siblings like chipotle_view_bag or chipotle_start_order by naming the final step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on using confirm=false for preview and confirm=true to place. Does not explicitly mention prerequisites or alternative tools, but the context implies it's the final step after building an order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customize the current order item by adding protein, rice, beans, salsas, and toppings. Call after chipotle_start_order.
| Name | Required | Description | Default |
|---|---|---|---|
| rice | No | Rice choice | |
| beans | No | Beans choice | |
| extras | No | Any extra notes or additions (e.g. ['extra protein', 'light rice']) | |
| protein | No | Protein choice | |
| toppings | No | List of toppings/salsas to add (e.g. ['guac', 'salsa-mild', 'cheese', 'sour-cream', 'lettuce', 'salsa-hot', 'salsa-green', 'salsa-medium', 'fajita-veggies']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'customize,' implying mutation, but does not describe whether multiple calls override or append, validation rules, or error conditions. This lack of detail makes it insufficient for an agent to understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a clear ordering instruction, with zero wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description covers the high-level purpose but omits important details like the return value, whether customization resets after adding to bag, or any constraints on combinations (e.g., can't have both rice and beans). It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions (enums, examples). The description adds no additional meaning beyond listing categories (protein, rice, etc.), so it meets the baseline but does not improve understanding of parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool customizes an order item by adding specific components (protein, rice, etc.) and explicitly mentions it should be called after chipotle_start_order, distinguishing it from sibling tools like chipotle_start_order and chipotle_add_to_bag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by stating 'Call after chipotle_start_order,' which tells the agent when to invoke the tool. However, it doesn't mention when not to use it or any alternatives, but the instruction is clear enough for a single customization step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get saved favorite orders from your Chipotle account. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only notes the login requirement, omitting details about read-only behavior, rate limits, response structure, or any side effects. For a GET operation, more transparency about data freshness or pagination would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the core purpose and a key prerequisite. It is front-loaded with the action and resource, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters, the tool is simple but lacks detail about what constitutes a 'favorite order' and the expected output format. With no output schema, the description should at least hint at the return structure (e.g., list of order IDs or items). This is minimal for an agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the schema inherently explains all inputs. The description adds no parameter-specific meaning, but this is acceptable given no parameters exist. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves saved favorite orders, specifying the verb 'Get' and the resource 'saved favorite orders from your Chipotle account'. This distinguishes it from related sibling tools like chipotle_get_order_history, which returns past orders, and chipotle_reorder, which reorders past items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires being logged in') but provides no guidance on when to use this tool versus alternatives like chipotle_get_order_history or chipotle_start_order. There is no mention of exclusions or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Chipotle location by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | The location ID from chipotle_search_locations results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states 'get detailed information', implying read-only, but does not disclose authentication requirements, rate limits, or any side effects. For a read operation, minimal behavioral disclosure is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Concisely conveys the tool's purpose and input requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description covers the essential purpose and input. However, it lacks details about what 'detailed information' includes (e.g., address, hours, etc.), which would aid the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The parameter description adds value by specifying that the locationId comes from chipotle_search_locations results, providing context beyond the type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get', resource 'detailed information about a specific Chipotle location', and input method 'by its ID'. Distinguishes from sibling 'chipotle_search_locations' which searches rather than retrieves by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives like chipotle_search_locations or chipotle_select_location. However, the description implies it is for retrieving details after obtaining an ID, which is reasonable for a simple lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your past Chipotle orders with items, dates, locations, and totals. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of past orders to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a key behavioral trait (requires login) but does not mention the read-only nature, pagination behavior, or data freshness. Given the minimal description, it is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a requirement, front-loaded and concise with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequately complete. It covers purpose and main constraint. It does not explain the return format, but given the tool's simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the 'limit' parameter. The description adds no further param-specific meaning beyond the login requirement, which is not parameter-related. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'past orders', and specifies the content (items, dates, locations, totals). It distinguishes from siblings like 'chipotle_reorder' and 'chipotle_track_order' by focusing on historical order data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the prerequisite 'Requires being logged in'. It does not explicitly exclude alternatives or specify when not to use, but the context implies this is for viewing history, not for actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Chipotle Rewards points balance and available rewards. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation but does not confirm read-only nature or disclose any other behavioral traits like data freshness, rate limits, or side effects. Minimal behavioral context provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and then state the prerequisite. No wasted words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately explains what the tool returns. It could detail the reward format, but it is sufficiently complete for a simple read operation among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline is 4. The description adds context about what is retrieved (points balance and rewards), which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and the resource 'Chipotle Rewards points balance and available rewards'. It is specific and distinguishes from sibling tools like chipotle_get_favorites or chipotle_get_order_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a prerequisite: 'Requires being logged in.' This guides usage context. However, it does not explicitly mention when to use this tool versus alternatives or 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.
Authenticate with your Chipotle account using email and password. Required to access rewards and saved payment methods.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Chipotle account email address | ||
| password | Yes | Chipotle account password |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the authentication behavior but does not disclose side effects (e.g., session creation, token handling) or failure behavior. For a standard login tool, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and contains no superfluous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (login), no output schema, and full schema coverage, the description adequately covers what the tool does and its role in the workflow. It is complete for the expected use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('email' and 'password'). The tool description only restates these parameters without adding extra meaning (e.g., format requirements, constraints). Baseline score 3 is appropriate as schema already provides sufficient information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Authenticate with your Chipotle account using email and password.' It also explains the importance ('Required to access rewards and saved payment methods'), distinguishing it from sibling tools like chipotle_get_rewards or chipotle_checkout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is required for accessing rewards and payment methods, implying when to use it. However, it lacks explicit guidance on when not to use it or alternatives (e.g., if already logged in, use chipotle_logout first), but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log out of Chipotle by clearing stored session cookies. Use this to reset authentication state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes clearing cookies and resetting auth, which fully discloses the behavior. No annotations, but description is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded and contain no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logout tool with no parameters, the description is complete and covers purpose and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds no param details but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: logging out by clearing session cookies and resetting authentication state. Distinct from sibling tools like chipotle_login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it to reset authentication state, providing clear context. No exclusions or alternatives, but simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickly reorder a previous Chipotle order by its order ID. Items from the past order will be added to your bag. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Order ID from chipotle_get_order_history results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions logging in requirement and that items are added to bag. However, it doesn't disclose potential side effects like overwriting current bag contents or location constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. The purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists. The description explains the effect (adds to bag) but doesn't mention return values, error handling, or constraints like valid order legality. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already tells where the orderId comes from. The tool description adds minimal extra value by restating 'by its order ID'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (reorder a previous order), the resource (order ID), and the effect (adds to bag). The description distinguishes from siblings like chipotle_get_order_history (which retrieves IDs) and chipotle_add_to_bag (which adds items individually).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (logged in) and the required input (order ID from chipotle_get_order_history). It doesn't mention when NOT to use or alternative tools, but the context of siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Chipotle restaurants near a given address or zip code. Returns a list of nearby locations with address and hours.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | Search radius in miles (default: 10) | |
| address | Yes | Address, city, or zip code to search near (e.g., '94105', '123 Main St, San Francisco CA') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full responsibility. It states the tool finds locations and returns a list with address and hours, but does not disclose read-only nature, error behavior, or any constraints beyond the schema, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 17 words, front-loaded with the action and resource, and includes the return value. No unnecessary words; each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description briefly mentions return value (list with address and hours) but lacks details on ordering, distance, or limit. For a simple search tool, it is marginally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add additional context beyond what is in the schema, yielding baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Find' and resource 'Chipotle restaurants' with clear context 'near a given address or zip code'. Distinguishes from sibling tools like chipotle_get_location which likely gets a single location, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives such as chipotle_get_location or chipotle_select_location. The description implies usage for finding locations but does not provide when-not-to-use or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a specific Chipotle restaurant for your order. Call after chipotle_search_locations to confirm which restaurant to use.
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location ID from chipotle_search_locations results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates the tool selects a location but does not disclose any side effects, state changes, or return behavior. For a simple selection tool, this is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the action and provides sequencing guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple action, the description covers the basics. However, it does not explain what happens after selection (e.g., confirmation, state update), which could be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required parameter. The description adds value by specifying that locationId comes from chipotle_search_locations results, which provides useful context beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects a specific Chipotle restaurant and specifies it should be called after chipotle_search_locations, distinguishing it from sibling tools like chipotle_search_locations and chipotle_get_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call after chipotle_search_locations to confirm which restaurant to use,' providing clear when-to-use guidance. It does not explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the order fulfillment type before building your order: pickup (you collect in-store), delivery (brought to you), or group (others can add items).
| Name | Required | Description | Default |
|---|---|---|---|
| orderType | Yes | How the order will be fulfilled |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the behavioral meaning of each enum value (pickup, delivery, group). This adds context beyond the schema's simple 'How the order will be fulfilled'. No side effects or rate limits are mentioned, but given the tool's simplicity, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes definitions for all options. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient context: what the tool does, when to use it, and what each value means. It could mention that this affects subsequent add-to-bag actions, but 'before building your order' implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for orderType, but the tool description adds value by defining each enum option (pickup, delivery, group). This goes beyond the schema's basic explanation, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the order fulfillment type (pickup, delivery, group) and distinguishes these options. It specifies the timing ('before building your order'), making it distinct from sibling tools like chipotle_start_order or chipotle_checkout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('before building your order'), providing clear context. However, it does not explicitly state when not to use it or mention prerequisites (e.g., location selection), though these are likely handled by other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start building a new Chipotle order by selecting the entree type (bowl, burrito, tacos, salad, or quesadilla). Must call chipotle_customize_item next to add ingredients.
| Name | Required | Description | Default |
|---|---|---|---|
| entreeType | Yes | Type of entree to build | |
| locationId | No | Optional location ID if you've already chosen a restaurant |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions the action and next step, but does not disclose behavioral traits like side effects, idempotency, or required permissions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core action and immediate next step. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description covers the essential flow. It could mention return value or error handling, but the core functionality is sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). Description adds little extra meaning beyond listing entree types and noting locationId is optional. Baseline 3 is appropriate as schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: start a new Chipotle order by selecting entree type. It lists specific options and mentions the next step, which distinguishes it from sibling tools like chipotle_customize_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the required next step (chipotle_customize_item), providing clear usage context. However, it does not include exclusions or when not to use this tool, but given the sibling list, the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check connection status and whether you are logged in to Chipotle. Call this first to verify authentication before ordering.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: checking connection and login status. It is a read-only check and does not modify anything, which is implied by 'check' and 'verify.' However, it could explicitly state it makes no changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words. It front-loads the purpose and adds usage guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple purpose, the description is complete. It tells what the tool does and when to use it, sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so baseline is 4. The description does not need to add parameter information beyond what the schema provides, and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks connection and login status for Chipotle. It distinguishes itself from sibling tools like chipotle_login by specifying it is for verification, not performing login. The verb 'check' and resource 'connection status and login' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'call this first to verify authentication before ordering,' providing clear when-to-use guidance. It does not, however, mention when not to use it or provide alternatives, but the directive is strong and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track the status of a Chipotle order. Shows order status and estimated pickup time.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | No | Order ID to track. If omitted, shows the most recent order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'shows order status and estimated pickup time.' It does not disclose whether the operation is read-only, requires authentication, or has side effects. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description is too vague about return format. With 17 siblings, more context about ordering statuses or output structure would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully (100% coverage), so baseline is 3. The tool description adds no additional parameter information, but the schema already explains the 'if omitted' default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states tracking an order and what it shows (status, pickup time). However, it does not differentiate from the sibling tool 'chipotle_status', leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like chipotle_status, or when to provide an orderId versus omit it. The optional parameter is not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all items currently in your bag with customizations and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral detail beyond the purpose. It does not disclose side effects, state changes, permission requirements, or that it is a read-only operation. With no annotations, the description carries full responsibility for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the purpose with no wasted words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description is minimally adequate. However, it omits contextual details like session scope or potential empty bag state, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema coverage is 100%. The description adds no parameter details, but baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: viewing items in the bag with customizations and pricing. It effectively distinguishes from sibling tools like chipotle_add_to_bag or chipotle_checkout by focusing on read-only access to the bag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given multiple sibling tools (e.g., chipotle_customize_item, chipotle_checkout), explicit usage context would help an agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0chipotle_add_to_bagchipotle_checkoutchipotle_customize_itemchipotle_get_favoriteschipotle_get_locationchipotle_get_menuchipotle_get_order_historychipotle_get_rewardschipotle_loginchipotle_logoutchipotle_reorderchipotle_search_locationschipotle_select_locationchipotle_set_order_typechipotle_start_orderchipotle_statuschipotle_track_orderchipotle_view_bagEach tool targets a distinct action: authentication, location selection, order building steps, bag management, checkout, reordering, history, and rewards. No two tools have overlapping purposes.
All tools follow the consistent 'chipotle_verb_noun' pattern (e.g., chipotle_search_locations, chipotle_add_to_bag). No mixing of naming conventions.
18 tools cover the full ordering workflow comprehensively. While slightly above the typical 3-15 range, the count is justified by the domain complexity including authentication, location, customization, and order management.
The tool set covers the complete ordering lifecycle from login to checkout, plus reordering, history, rewards, and tracking. Minor gaps like removing items from bag are absent but unlikely to cause agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Hosted MCP server to manage a restaurant menu from AI agents - 39 tools over the DuckHub API.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-chipotle'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
