mcp-wendys

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct stage of the Wendy's ordering flow: menu discovery, nutrition details, location lookup, cart management, offers, checkout, and order tracking. No two tools overlap in purpose, making selection unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (search_, get_, find_, add_, apply_, place_, check_). The naming convention is uniform and predictable, aiding agent comprehension.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose—covering the essential steps of finding, ordering, and tracking Wendy's food. Each tool earns its place without redundancy or bloat.
Completeness4/5
The tool surface covers the full order lifecycle from search to status check. A minor gap is the lack of an explicit remove-from-order tool, but agents can likely work around this by building a new order or using external logic.
Average 3.5/5 across 7 of 7 tools scored.
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
This repository is licensed under MIT License.
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 disclosing behavior. It doesn't mention side effects such as charging the payment method, order irreversibility, or requirements like location operating hours. The description simply states what happens without contextualizing the action's consequences.
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 a single, front-loaded sentence with no redundancy. It effectively communicates the core purpose in minimal words, achieving maximum conciseness without sacrificing clarity.
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?
Given the tool's responsibility (placing an order) and the absence of annotations or output schema, the description is incomplete. It fails to mention that the order must already contain items, that payment will be processed, or any post-placement expectations. The single sentence leaves significant operational context unaddressed.
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 100%, with each parameter having a clear description (e.g., order_type enum, location_id from find_nearby_locations). The tool description adds no additional parameter-level semantics, but the schema sufficiently documents the required and optional parameters, warranting the baseline score.
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's action ('Place the current order') and specifies the resource ('at a selected Wendy's location'). This distinguishes it from siblings like 'add_to_order' (which adds items) and 'find_nearby_locations' (which finds locations).
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 provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing items in the order (from add_to_order) or that this is the final checkout step. Sibling tools exist but are not referenced.
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?
With no annotations, the description carries the full burden of disclosing side effects. 'Add an item to the current mobile order cart' implies a mutation but does not state whether it requires an existing cart, what happens if the item is unavailable, or if the action is irreversible. It adds minimal context beyond the basic action.
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 a single sentence of ten words, entirely front-loaded with the essential purpose. Every word is necessary, and there is 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?
For a simple tool with three parameters and full schema descriptions, the description is minimally adequate but lacks contextual details. It does not explain that a 'current order' must exist, or how this step fits into the larger order workflow (search → add → apply offers → place order). The absence of annotations and output schema increases the need for more context, which is not provided.
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 100% for all three parameters (item_name, quantity, customizations), so the baseline is 3. The tool description does not add any meaning beyond the schema; for instance, it does not clarify how item_name maps to menu items or how customizations are formatted.
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 a specific action 'Add an item' to a specific resource 'current mobile order cart'. It distinguishes this tool from siblings like 'place_order' (finalizing) and 'search_menu_items' (discovery), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives. It does not mention that this should be used after searching for items, before placing an order, or that it requires an active cart. No exclusions or alternative recommendations are 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 for behavioral disclosure. It only states the core function and gives no details about error handling (e.g., what happens if the item name is not found), whether it returns a single item or an array, or any authentication/rate-limit requirements. For a simple read tool this is a notable gap, but not severe enough for a 1.
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 a single, clear sentence that front-loads the action and object. It is concise with no filler or repetition of the schema.
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?
Given the tool's simplicity (one parameter, no output schema), the description is minimally sufficient but not complete. It states the purpose but does not specify the return structure or units (e.g., calories per serving), nor does it explain error behavior. With no output schema and no annotations, the description should provide more detail about what the agent can expect in the response.
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 schema fully documents the single parameter 'item_name' with description and examples, so the baseline is 3. The description adds only the phrase 'specific Wendy's menu item', which reinforces the need for an exact item name but adds no extra detail about format, case sensitivity, or valid values beyond what the schema already provides.
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's function: getting nutrition information and calorie count for a specific Wendy's menu item. It uses a specific verb ('Get') and resource ('nutrition information and calorie count'), and the phrase 'for a specific Wendy's menu item' distinguishes it from sibling tools like search_menu_items, which likely search or list items.
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 guidance is given on when to use this tool versus alternatives. The description implies the user should already know the exact item name, but it does not mention using search_menu_items first or any exclusions. There is no 'when not to use' or alternative tool reference.
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?
With no annotations, the description must carry all behavioral context, but it only states the action without disclosing side effects, prerequisites, or error behavior, such as whether it modifies the order total or requires an active order.
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 a single precise sentence that conveys the action without any redundant words.
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 with one parameter and no output schema, but the description omits important contextual details like the need for a current order or the effect of an invalid code, making it minimally adequate.
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 parameter is fully described in the schema with examples, and the description adds no additional parameter semantics; per rubric, high schema coverage gives a baseline of 3.
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 uses the specific verb 'apply' with the resource 'promotional offer or deal code' and clearly states it applies to the current order, distinguishing it from sibling tools like add_to_order or place_order.
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?
No explicit when-to-use guidance or alternatives are given, but the action is self-evident; it is implied that this is used when a customer has an offer code to apply to their order.
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 disclosing behavior. 'Check' implies a read-only operation, but it does not describe what statuses might be returned, whether the tool errors on unknown order IDs, or any side effects. This lack of detail is a significant gap for a tool with no annotation support.
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 a single concise sentence that clearly states the purpose. Every word earns its place with no redundancy or filler.
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 with one parameter and no output schema, but the description does not explain what 'status' entails or the format of the return value. While minimal, it is adequate for a basic status check; more detail would improve completeness, especially since the output schema is absent.
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 schema covers 100% of the single parameter (order_id) with a clear description. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
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 uses a specific verb ('Check') and resource ('current status of a placed order'), clearly distinguishing this from sibling tools like place_order or add_to_order. It leaves no ambiguity about what the tool does.
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 phrase 'placed order' implies the tool is used after an order has been created, but there is no explicit guidance on when to use this versus alternatives. No mention of prerequisites or exclusions, but the context of sibling tools makes the intended usage reasonably clear.
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 states it returns matching items with name, description, price, and category, which gives useful output context. However, it does not disclose potential behaviors like read-only safety, pagination, or result limiting, leaving some ambiguity.
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 two concise sentences with the action and resource front-loaded. Every word adds value: it states the search capability and the return fields, with no redundant or vague phrasing.
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 search tool with two parameters and no output schema, the description is nearly complete. It explains the purpose and return structure, and the schema covers parameter details. A minor gap is not explicitly noting the optional nature of the category filter, but this is already clear in the schema.
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 schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides, but the schema itself fully documents the 'query' and 'category' parameters, so no compensation is needed.
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's function: 'Search Wendy's menu items by name, category, or keyword.' It uses a specific verb ('Search') and resource ('menu items'), and the scope is defined. It is distinct from siblings like get_item_nutrition and find_nearby_locations.
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 the tool—whenever a menu item search is needed—but it does not explicitly mention when not to use it or provide alternatives. It lacks references to sibling tools for differentiated use cases, so guidance is purely implied.
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, the description carries the transparency burden. It states that it finds nearby locations based on address or zip, but does not disclose output format (e.g., distance, hours, details), sorting behavior, or any default limits beyond the schema. This is adequate for a simple read-only query, but not rich.
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 a single, well-structured sentence that immediately states the tool's action and target. No wasted words, and the key information is 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?
Given the simplicity of the tool and the absence of an output schema, the description covers the essential purpose. It could mention that locations include details like address/hours, but this is not critical for selecting the correct tool. The schema fully documents parameters, and all sibling tools are distinct.
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 100%, so the baseline is 3. The description adds no extra meaning to the parameters; 'address' and 'limit' are already self-descriptive in the schema. The description merely reiterates the address usage, which is already in the property description.
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's purpose with a specific verb ('Find') and resource ('nearby Wendy's restaurant locations'). It also specifies the search input ('address or zip code'), distinguishing it from sibling tools that deal with menu, nutrition, and ordering.
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?
Clear context is provided: the tool is for finding nearby locations. There are no explicit exclusions or alternatives, but the sibling tools are all order-related, so the usage context is unambiguous. A brief note on when not to use it would push this to a 5.
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:

[![mcp-wendys MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-wendys/badges/card.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-wendys)

Score Badge

Copy to your README.md:

[![mcp-wendys MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-wendys/badges/score.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-wendys)

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/markswendsen-code/mcp-wendys'

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