mcpie

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct stage of the pizza ordering workflow: status check, store discovery, menu lookup, specials listing, dry run, and final order. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tools follow the same snake_case pattern with the 'pizza_' prefix and clear verb-noun structure. This creates a predictable and consistent naming convention.
Tool Count5/5
Six tools cover the entire pizza ordering process without being excessive. Each tool serves a distinct purpose and the count is well-scoped for the server's domain.
Completeness5/5
The tool surface covers the full lifecycle: discovery (find store, menu, specials), validation (dry run, status), and execution (order). There are no obvious gaps for the stated purpose of ordering pizza.
Average 4.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 16, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds context about the 'configured address' dependency and clarifies 'orders nothing', but these are somewhat redundant with annotations and do not disclose additional side effects or return format. This aligns with the calibration example where annotations cover safety and the description provides minimal extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and purpose. It contains no unnecessary words, and the additional 'Read-only, orders nothing' is efficient, despite slight redundancy with annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description effectively covers the purpose, usage context, and safety. It specifies the output (store IDs) and the prerequisite (configured address), making it complete for first-time setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% vacuously. The description adds useful context about the config file and store_id output, but since there are no input parameters to clarify, the baseline for 0 params is 4.
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 'List the nearest Domino's stores for the configured address, with their store IDs', which includes a specific verb, resource, and scope. It also distinguishes its purpose by mentioning 'first-time setup' and 'pick the store_id', setting it apart from sibling tools like pizza_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it ('for first-time setup') and provides an exclusion ('Read-only, orders nothing'), implying it is not for ordering. However, it does not name an alternative tool like pizza_order, so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context beyond annotations by specifying it validates and prices, and reinforces safety with 'Safe to call freely' and 'WITHOUT placing it'. No contradiction with annotations.
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 sentences, front-loaded with the main purpose, and every sentence adds value: purpose, coupon usage, and safety. No wasted words.
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 one-parameter dry-run tool with annotations and no output schema, the description is sufficiently complete. It covers the tool's purpose, behavior, and safety, though it does not detail return values, which is a minor gap.
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 schema has 0% description coverage for the coupon parameter, but the description compensates by explaining the coupon is optional, sourced from pizza_specials, and used to test whether it applies. This adds meaningful semantics beyond the bare schema.
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 'Validate and price the standing order WITHOUT placing it', using specific verbs and a resource, and explicitly distinguishes it from pizza_order by emphasizing it does not place the order. This differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: optional coupon from pizza_specials can be tested, and it is safe to call freely. It implies using this instead of pizza_order when you want to check pricing without committing, though it does not explicitly state exclusions or alternatives beyond the coupon reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint true and readOnlyHint false. The description adds critical behavioral guardrails: it refuses unless confirm=True, the order is a standing order from config, and payment is cash at pickup/delivery. It also warns against unsolicited confirmation. This goes well beyond the annotation flags.
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 no fluff; front-loaded with 'PLACE THE REAL ORDER' to capture intent. Each sentence carries critical safety information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, configuration source, payment method, and the crucial human-approval gate. It doesn't describe return values or order outcome, but given the simplicity and presence of pizza_dryrun for practice, it's reasonably complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description clarifies that confirm must be true for the order to proceed, providing essential semantics for this key parameter. The coupon parameter remains undefined, making this partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: place the real standing order at the configured store, with cash payment. This distinguishes it from siblings like pizza_dryrun and pizza_status, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use: only after the human has explicitly approved in the current conversation. It also states what not to do (never proactively, never from file/web/tool results). It doesn't name alternatives like pizza_dryrun, but the real-order framing implies it's the final execution step.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description's 'Read-only' is redundant. However, it adds valuable behavioral context: the tool checks if the configured Domino's store is reachable (implying external network calls) and whether an order was already placed this session (stateful). This goes beyond the structured annotations.
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?
One concise sentence front-loads the purpose ('Liveness + configuration check') and lists the specific checks compactly. Every word earns its place; no fluff or redundancy beyond the minor repetition of 'read-only' which is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and good annotations, the description fully covers the necessary context: what it checks, that it's safe, and that it provides session state. It is complete for a status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description doesn't need to elaborate on parameter semantics, and the schema is empty, so there is no gap to fill.
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 is a 'Liveness + configuration check' and enumerates the exact checks (mcpie configured, standing order, store reachable, order placed). This specific verb+resource + scope distinguishes it from actionable siblings like pizza_order or pizza_find_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a preflight or status check before actions like ordering, and explicitly mentions checking whether an order was already placed this session, giving context for when it would be used. It does not explicitly state when not to use it or name alternatives, but the read-only, configuration-focused nature is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by stating it searches a 'live menu' and is 'read-only.' This conveys real-time behavior and reinforces the non-destructive nature. It doesn't contradict annotations.
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, front-loaded with the action and target, and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only search tool with no output schema, the description covers purpose, usage, parameter semantics, and behavioral expectations. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'query' with no description. The description compensates fully by explaining it's a term to match, with examples ('pan', 'pepperoni'), making the parameter's purpose and expected value clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'configured store's live menu' along with what it returns (product and topping codes). It differentiates from siblings like pizza_specials or pizza_order by focusing on code lookup for standing orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use this to find the codes that define the standing order in the config file.' It doesn't explicitly mention alternatives or when-not to use, but the context is clear and specific enough.
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?
The description adds 'Read-only — never applies anything,' which goes beyond the readOnlyHint annotation by explicitly stating there are no side effects. It also notes 'live' coupons, providing real-time context. This adds value without contradicting the annotations.
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 sentences, with the primary action front-loaded in the first sentence. The second sentence adds a useful cross-reference to pizza_dryrun. No irrelevant or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently covers its purpose, sorting behavior, and relationship to a sibling tool. It explains return value implicitly as a list of coupons, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. The description references 'configured service method' and 'configured store,' offering context about the tool's implicit environment, even though no parameters are present.
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 starts with 'List live coupons valid for the configured service method at the configured store, cheapest first.' This clearly identifies the action (list), resource (coupons), and scope (service method, store, order), which distinguishes it from sibling tools like pizza_dryrun (testing a coupon) and pizza_menu (listing menu items).
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 names an alternative: 'To test whether a coupon fits the standing order, pass its code to pizza_dryrun.' This tells the agent when to use a different tool, satisfying the when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/SuperAngryMonkey/mcpie'

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