MCPizza - Enhanced

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, 'get_menu' retrieves the full menu, while 'search_menu' filters it, and 'add_item_to_order' and 'add_pizza_with_toppings' handle different item types. The descriptions clearly differentiate their functions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as 'create_order', 'get_menu', and 'place_order'. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming style.
Tool Count5/5
With 12 tools, the server is well-scoped for a pizza ordering domain. Each tool serves a specific role in the ordering workflow, from store lookup to order placement, without being excessive or insufficient for the intended functionality.
Completeness5/5
The tool set provides complete coverage for the pizza ordering domain, including store discovery, menu browsing, order creation and management, coupon retrieval, and final placement. There are no obvious gaps, as all essential CRUD and lifecycle operations are covered, ensuring agents can handle the full process without dead ends.
Average 3.1/5 across 12 of 12 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
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. It states the tool 'Handles proper product + topping configuration', hinting at validation or processing, but lacks details on behavioral traits such as error handling, permissions needed, whether it modifies an existing order or creates a new one, or any side effects like rate limits. This is inadequate for a mutation tool with 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 brief and front-loaded, consisting of two concise sentences that directly state the tool's purpose. There's no unnecessary information, making it efficient, though it could be slightly more structured by explicitly separating purpose from context.
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 has no annotations, no output schema, and involves mutation (adding a pizza), the description is incomplete. It doesn't explain what the tool returns, error conditions, or how it interacts with other order-related tools. For a 4-parameter tool with complex configuration, more context is needed to guide effective use.
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%, so the schema fully documents all parameters (coupon_code, size, crust, toppings) with descriptions and defaults. The description adds minimal value by mentioning 'using a coupon code' and 'topping configuration', but doesn't provide additional semantics beyond what's in the schema, such as format details or usage tips.
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 action ('Add a customized pizza with toppings') and resource ('pizza'), specifying it involves product + topping configuration. However, it doesn't explicitly differentiate from sibling tools like 'add_item_to_order' or 'create_order', which might handle similar order-related functions.
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 mentions using a coupon code, implying a context for discounts, but provides no guidance on when to use this tool versus alternatives like 'add_item_to_order' or 'create_order'. There's no mention of prerequisites, exclusions, or specific scenarios for tool selection.
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 states the tool returns 'coupon codes, descriptions, and prices,' which hints at read-only behavior, but doesn't explicitly confirm it's non-destructive or safe. It also omits details like rate limits, authentication needs, or error handling, leaving significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two clear sentences that state the purpose and return values. There's no unnecessary fluff, and every sentence earns its place by providing essential information. It could be slightly improved by integrating usage hints, but it's efficient as-is.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return types, but lacks details on behavioral traits, usage context, or error handling. Without annotations or an output schema, more completeness would be beneficial, but it's not entirely inadequate for such 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?
The input schema has 100% description coverage, with the 'store_id' parameter fully documented in the schema itself. The description adds no additional parameter semantics beyond implying the tool fetches coupons for a specific store, which is already covered by the schema. This meets the baseline of 3 for high schema coverage without extra value from the description.
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's purpose: 'Get available coupons and deals for a store.' It specifies the verb ('Get') and resource ('coupons and deals'), and distinguishes it from siblings like 'get_menu' or 'get_store_info' by focusing on promotional content. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a 'search_coupons' tool), keeping it at 4 rather than 5.
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 versus alternatives. It doesn't mention prerequisites (e.g., needing a store_id from 'find_stores' or 'get_store_info'), exclusions, or comparisons to sibling tools like 'get_menu' for non-promotional items. This lack of contextual usage information results in a low score.
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. It mentions analysis and suggestions but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like (e.g., structured advice vs. text). For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 and front-loaded, with the core purpose stated first. Both sentences earn their place by elaborating on analysis and strategy. However, it could be slightly more structured by explicitly separating purpose from details.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., guidance format, error handling), and with 2 parameters, it lacks details on behavioral aspects like side effects or dependencies. For a tool that provides AI guidance, more context on output and usage is needed.
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%, so the schema already documents both parameters ('store_id' and 'user_request') with descriptions. The description adds marginal value by implying parameters are used for analysis and suggestions (e.g., 'store_id' for deals, 'user_request' for preferences), but doesn't provide additional syntax or format details beyond what the schema provides.
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's purpose: 'Get AI guidance on how to build the best order based on user preferences.' It specifies the verb ('Get AI guidance') and resource ('order'), and mentions analysis of deals, pizza counts, and ordering strategy. However, it doesn't explicitly differentiate from siblings like 'search_menu' or 'get_menu' which might also provide ordering information.
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 versus alternatives. It doesn't mention prerequisites, exclusions, or compare to siblings like 'search_menu' for menu items or 'get_coupons' for deals. The context is implied (building an order), but no explicit usage rules 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't state whether it requires authentication, has rate limits, or what the return format looks like (e.g., JSON structure). For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the key information: the action and resource. There's no wasted verbiage, and it directly states the purpose without unnecessary details, making it appropriately concise.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes beyond 'hours and services', nor does it cover behavioral aspects like error handling or response format. For a tool with no structured metadata, more context is needed to fully guide the agent.
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 input schema has 100% description coverage, with the 'store_id' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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's purpose: 'Get detailed information about a specific Domino's store including hours and services.' It specifies the verb ('Get'), resource ('Domino's store'), and scope ('detailed information'), though it doesn't explicitly differentiate from sibling tools like 'find_stores' or 'view_order'. This makes it clear but not fully sibling-distinctive.
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 versus alternatives. It doesn't mention sibling tools like 'find_stores' (which might list stores) or 'view_order' (which might show order details), nor does it specify prerequisites or exclusions. This leaves the agent with no contextual usage hints.
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 filtering capabilities but doesn't describe key behaviors like whether this is a read-only operation, if it requires authentication, what the output format is, or if there are rate limits. This leaves significant gaps for a search 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 appropriately sized and front-loaded with a clear purpose in the first sentence. It consists of two concise sentences with zero wasted words, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of items, error handling) or behavioral aspects like permissions. For a search tool with three parameters, this leaves the agent under-informed about how to use it effectively.
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%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'filter by category and search term', which aligns with the schema but doesn't provide additional syntax or usage details beyond what's in the structured 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's purpose with a specific verb ('Search') and resource ('menu items at a store'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_menu' or 'find_stores', which might offer similar or overlapping functionality.
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 versus alternatives. It doesn't mention sibling tools like 'get_menu' (which might list all items without search) or 'find_stores' (which might search for stores instead of menu items), leaving the agent to guess based on names alone.
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 full burden but only states the action ('clear and start over'). It doesn't disclose behavioral traits such as whether this is destructive (likely yes, but not confirmed), what happens to existing order data, or any side effects like resetting pricing or coupons.
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, efficient sentence that directly states the tool's function with no wasted words. It is front-loaded and appropriately sized for a zero-parameter tool.
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?
For a tool that likely performs a destructive reset operation, the description is incomplete. With no annotations and no output schema, it fails to explain what 'clear' entails (e.g., data deletion, state reset) or what 'start over' results in, leaving gaps in understanding the tool's full behavior.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining focus on the tool's purpose without redundancy.
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 action ('clear') and target ('current order'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_order' or 'view_order' beyond the specific reset action, which keeps it from a perfect score.
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 implies usage when starting over an order, but provides no explicit guidance on when to use this tool versus alternatives like 'create_order' for a new order or 'view_order' to check current status. No prerequisites or exclusions are mentioned.
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 the return values ('store IDs, addresses, and phone numbers') but lacks details on error handling, rate limits, authentication needs, or whether the search is real-time or cached. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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?
The description is highly concise and front-loaded, consisting of two efficient sentences that directly state the tool's purpose and return values. Every word contributes to understanding without redundancy, making it easy for an agent to parse quickly.
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 low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and returns, but lacks behavioral details like error cases or search limitations. Without annotations or output schema, it should provide more context for reliable use, yet it meets the minimum for a simple lookup 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?
The description adds minimal meaning beyond the input schema, which has 100% coverage for the single parameter 'query'. It reiterates that the query is an 'address or zip code', matching the schema's description. Since the schema already documents this well, the description provides no additional syntax, format, or constraints, meeting the baseline for high schema coverage.
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's purpose: 'Find nearby Domino's stores by address or zip code.' It specifies the verb ('Find'), resource ('Domino's stores'), and scope ('by address or zip code'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_store_info', which might retrieve details for a specific store rather than searching nearby ones, so it misses full sibling differentiation.
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 versus alternatives. It does not mention when-not scenarios, prerequisites, or direct comparisons to siblings such as 'get_store_info' or 'create_order'. Usage is implied only by the purpose statement, leaving the agent to infer context without explicit direction.
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 states the tool returns 'all available items organized by category,' which hints at read-only behavior, but doesn't clarify if it's a safe operation, whether it requires authentication, or if there are rate limits. For a tool with no annotations, this is insufficient to fully inform the agent about behavioral traits.
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 highly concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and output. The first sentence states the action and resource, and the second adds valuable context about the return format. There is no wasted verbiage, making it easy for an agent to parse quickly.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and the output format, but lacks details on usage guidelines, behavioral traits, or error handling. For a simple read operation, this might suffice, but it leaves gaps that could hinder optimal agent selection.
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 doesn't add any parameter-specific information beyond what the input schema provides. The schema has 100% description coverage, with the 'store_id' parameter clearly documented as 'Store ID to get menu for.' Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Get the full menu for a specific store' specifies the verb (get) and resource (menu), and 'Returns all available items organized by category' adds useful output context. However, it doesn't explicitly differentiate from sibling tools like 'search_menu' or 'get_store_info', which prevents a perfect score.
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 versus alternatives. It doesn't mention when to choose 'get_menu' over 'search_menu' (which likely allows filtering) or 'get_store_info' (which might include menu details), nor does it specify prerequisites like needing a valid store ID. This leaves the agent without contextual usage instructions.
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 provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('view'), implying non-destructive behavior, but doesn't address other important aspects like authentication requirements, error conditions (e.g., what happens if no order exists), response format, or any rate limits. The description provides minimal behavioral context beyond the basic operation.
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, efficient sentence that immediately communicates the core functionality without unnecessary words. Every element ('view,' 'current order,' 'items, prices, and totals') serves a clear purpose. It's appropriately sized for a simple retrieval tool.
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. While it states what data will be returned, it doesn't describe the response structure, format, or potential edge cases. Given the lack of structured documentation about behavior and outputs, the description should provide more contextual information to help the agent understand what to expect from this operation.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing non-existent parameters. This meets the baseline expectation for a zero-parameter tool where the schema handles all parameter documentation.
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 ('view') and resource ('current order') with specific content details ('all items, prices, and totals'). It distinguishes from siblings like 'create_order' or 'place_order' by focusing on retrieval rather than modification. However, it doesn't explicitly differentiate from potential similar read operations like 'get_menu' which might show different data.
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 versus alternatives. It doesn't mention prerequisites (e.g., whether an order must exist first), timing considerations, or comparisons to siblings like 'get_menu' or 'place_order'. The agent must infer usage context solely from the tool name and description.
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. It mentions a prerequisite but doesn't disclose behavioral traits such as whether this is a mutation (implied by 'Add'), error handling, permissions needed, or what happens if the order doesn't exist. This leaves significant gaps for an agent to understand the tool's 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?
The description is two short sentences with zero waste, front-loading the main action. It could be slightly more structured by explicitly listing key parameters or outcomes, but it's efficient and to the point.
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 no annotations and no output schema, the description is minimal. It covers the basic purpose and a prerequisite but lacks details on behavior, error cases, or return values. For a mutation tool with 3 parameters, this is adequate but with clear gaps, making it just viable.
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%, so the schema already documents all parameters well. The description doesn't add any meaning beyond what the schema provides, such as examples or constraints on 'item_code' or 'options'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Add a menu item') and target ('to the current order'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'add_pizza_with_toppings' which might serve a similar purpose but for specific items.
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 includes a prerequisite ('Must create an order first'), which gives some context for when to use it. However, it doesn't explicitly state when to use this tool versus alternatives like 'add_pizza_with_toppings' or 'search_menu', nor does it provide exclusions or detailed scenarios.
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 provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't disclose important behavioral traits like: what permissions are needed, whether the order is saved immediately or temporarily, what happens on failure, or if there are rate limits. It mentions the order type options but doesn't explain their implications.
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 with just two short sentences that are front-loaded with the main purpose. Every word earns its place - the first sentence states what the tool does, and the second provides important workflow context without redundancy.
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?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., does it return an order ID?), error conditions, authentication requirements, or how this tool relates to the complete ordering workflow with siblings like 'place_order' and 'add_item_to_order'.
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%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'delivery or carryout' which relates to the 'order_type' parameter, but doesn't provide additional semantic context about parameter relationships or business logic.
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 action ('Create a new order') and resource ('order'), specifying it's for 'delivery or carryout'. It distinguishes from siblings like 'add_item_to_order' by noting it's 'Required before adding items', but doesn't explicitly differentiate from 'place_order' which might be a finalization step.
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 provides some contextual guidance by stating this tool is 'Required before adding items', which implies it should be used early in the ordering workflow. However, it doesn't explicitly state when to use this versus 'place_order' or other order-related tools, nor does it mention prerequisites or exclusions.
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 and effectively discloses critical behavioral traits: it's a real-world transaction ('PLACES A REAL ORDER with real payment!'), requires payment info, and implies irreversible action. It could improve by mentioning response format or confirmation details.
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 with zero waste: the first conveys the core action and warning, the second states the prerequisite. It's front-loaded with the critical warning and appropriately sized for its purpose.
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 high-stakes mutation tool with no annotations and no output schema, the description is mostly complete—it warns of real consequences and lists requirements. It could be enhanced by specifying what happens after submission (e.g., order confirmation, errors) or return values.
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%, so the schema already documents all four parameters (card_number, card_expiry, card_cvv, card_zip). The description adds no additional parameter semantics beyond implying these are required for payment, meeting the baseline of 3 when schema does the heavy lifting.
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 specific action ('PLACES A REAL ORDER with real payment') and the target resource ('Submit the current order to Domino's'), distinguishing it from siblings like 'add_item_to_order' or 'view_order' which handle order modification or viewing rather than final submission with payment.
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?
It explicitly states when to use this tool ('Submit the current order to Domino's') and includes prerequisites ('Requires payment information'), with clear alternatives implied by sibling tools like 'view_order' for checking status or 'add_item_to_order' for modifications before submission.
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-pizza MCP server](https://glama.ai/mcp/servers/dshanklin-bv/mcp-pizza/badges/card.svg)](https://glama.ai/mcp/servers/dshanklin-bv/mcp-pizza)

Score Badge

Copy to your README.md:

[![mcp-pizza MCP server](https://glama.ai/mcp/servers/dshanklin-bv/mcp-pizza/badges/score.svg)](https://glama.ai/mcp/servers/dshanklin-bv/mcp-pizza)

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/dshanklin-bv/mcp-pizza'

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