voucherify-core-mcp

Official

by voucherifyio

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or operation: customer lookup, campaign retrieval/listing/summary, promotion tier, voucher, qualifications, best deals, loyalty points, and product listing. Even overlapping areas like qualifications and get_best_deals are clearly differentiated by descriptions and use cases.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_campaign, list_campaigns, find_customer, etc.). The outlier is 'qualifications', which is a noun without a verb prefix, but overall the pattern is consistent and predictable.
Tool Count5/5
10 tools is well-scoped for a core API server covering customers, campaigns, promotion tiers, vouchers, qualifications, deals, loyalty points, and products. It provides essential operations without being overwhelming.
Completeness2/5
The tool set is entirely read-only; there are no create, update, or delete operations for any resource (customers, campaigns, vouchers, products, etc.). Additionally, listing tools are missing for vouchers and promotion tiers. This creates significant gaps for agents needing to manage resources.
Average 4.7/5 across 10 of 10 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers return format, error handling (ToolError), and critical warnings about required parameter. It does not explicitly state read-only nature or auth requirements, but provides good transparency overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite verbose with multiple sections and emojis. While well-structured, it could be more concise without losing 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?
Given the tool's complexity (2 parameters, nested objects), the description is complete: it covers all scenarios, provides correct/wrong examples, and explains return values and errors. Output schema exists but description still adds value.
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?
Given low schema description coverage, the description adds significant meaning: it details the customer object structure (required fields, optional metadata) and explains each scenario value with its purpose, vastly exceeding the schema's minimal type definitions.
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 finds redeemables applicable to a given customer, which is specific and distinguishes it from sibling tools like get_voucher or get_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use each scenario (CUSTOMER_FOCUSED, PRODUCT_FOCUSED, ADVANCED) with common usage patterns. It also emphasizes that customer is always required. However, it does not explicitly exclude cases where sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details parameter constraints (paired dates, format) and error conditions (ToolError for invalid inputs). It does not mention potential side effects or performance, but as a read-only analytics tool, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for parameters, rules, examples, and returns. It is front-loaded with the core purpose. Some redundancy exists (date rules repeated), but overall it is clear and informative.
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 moderate complexity, no annotations, and existence of an output schema, the description covers usage, parameter constraints, examples, errors, and return structure comprehensively. It leaves little ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It explains the campaign_id prefix, date format (ISO 8601), the rule that both dates must be provided together or omitted, and invalid empty strings. This adds significant meaning beyond the schema's type/title.
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 retrieves a comprehensive analytics summary for a specific campaign, detailing included metrics like validations, redemptions, and publications. This distinguishes it from sibling tools such as get_campaign (basic info) and list_campaigns (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples and parameter rules, including when to omit dates. It does not directly state when not to use this tool versus alternatives, but the context from sibling names and the detailed explanation of analytics scope implies appropriate use cases.
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?
Since no annotations are provided, the description bears full burden. It discloses that the tool automatically fetches and processes validation rules, provides processed data, and raises ToolError for invalid inputs. It could explicitly state it's a read-only operation, but the behavior is well-described.
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 long but well-structured with clear sections (Overview, Enhanced Features, Parameters, etc.). It is front-loaded with the core purpose. While some detail could be condensed, the organization aids readability and every section 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?
Given the tool's single parameter, no output schema, and unrelated siblings, the description covers the tool's purpose, parameters, return structure (with detailed fields), use cases, and error handling. It is comprehensive for the tool's simplicity.
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 input schema has 0% description coverage, so the description must compensate. It thoroughly documents the parameter's purpose, required format (must start with 'promo_'), case sensitivity, and validity requirement. It also provides an example that clarifies the expected format.
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 action ('Retrieve detailed information') and the resource ('specific promotion tier by its ID'). It distinguishes the tool's purpose from siblings like get_voucher and get_campaign by focusing on promotion tier details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (e.g., 'Analyze promotion tier configuration', 'Understand validation rules'), a concrete example, and identifier requirements. It does not explicitly state when not to use this tool or mention alternatives, but the use cases strongly imply appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states behavior: retrieves up to 1000 campaigns, no filtering, single request, sorted by creation date. Includes limitations and example output.
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?
Description is verbose but well-structured with sections (primary use case, behavior, no parameters, returns, example, usage pattern, limitations). Every sentence adds value; front-loaded with key information.
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?
Tool has no parameters and output schema exists (example given). Description covers purpose, behavior, limitations, usage pattern, and return structure. Completely adequate for a simple list 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?
No parameters, schema coverage 100%. Baseline 4 for 0 params. Description adds value by explicitly stating no parameters needed and explaining that no input is required.
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?
Description clearly states it lists all campaigns for campaign resolution, with specific verb 'list' and resource 'campaigns'. Distinguishes from siblings like get_campaign by returning comprehensive list for name-based matching.
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?
Explicit primary use case is resolving campaign ID from name. Provides usage pattern and warns against multiple calls. Does not explicitly state when NOT to use, but limitations (no filtering) imply alternatives may be needed for filtered results.
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?
With no annotations provided, the description carries full burden and delivers complete behavioral details: ID vs email lookup behavior, case-insensitive search, complete object return including loyalty summary, and error conditions. No contradictions.
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 well-structured with sections for lookup behavior, parameters, validation, examples, returns, and raises. It is front-loaded with the main purpose. Slightly verbose but every section adds value. Could be slightly more concise.
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 simple task of finding a customer with two parameters, and an output schema present, the description fully covers the input requirements, validation, return data structure, and error handling. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% as the schema only provides type and default. The description compensates thoroughly by specifying exact validation rules (email format, id prefix cust_), requiring exactly one parameter, and providing examples. This adds significant meaning beyond the 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 verb 'Find' and resource 'customer', with explicit lookup methods by email or ID. It distinguishes itself from sibling tools like get_campaign and list_products by focusing on customer retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, including validation rules that exactly one parameter must be provided and format requirements. It implicitly indicates not to use when data is not a customer, but lacks explicit when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses enhanced features (fetching and processing validation rules), provides detailed return structure, and mentions error raising. Rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured with clear sections. Every sentence adds value, though it could be slightly more concise. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and detailed output, the description is very complete. It covers purpose, parameter semantics, output structure, examples, use cases, and error handling. No gaps.
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?
Only one parameter (campaign_id) and schema coverage is 0%, but description adds extensive meaning: identifier requirements, format ('camp_' prefix), case-sensitivity, examples, and validation rules.
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?
Description clearly states 'Retrieve detailed information about a specific campaign by its ID.' It uses specific verb and resource. It distinguishes from siblings like list_campaigns (list all) and get_campaign_summary (summary).
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?
Description lists use cases like analyzing campaign configuration and validation rules. While it doesn't explicitly say when not to use or contrast with alternatives, the context is clear enough for an agent to decide.
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?
With no annotations provided, the description fully covers behavior: it discloses automatic processing of validation rules, return structure, and error conditions (raises ToolError). It also describes the 'Enhanced Features' that add value beyond a simple lookup.
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 fairly long but well-structured with clear sections (Enhanced Features, Parameters, Examples, Returns, Use Cases). It is front-loaded with purpose. Some redundancy exists (e.g., repeating identifier types), but overall it is organized and informative.
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 single-parameter tool with a complex return (many fields), the description provides a detailed breakdown of all return fields, error handling, and use cases. It also references external documentation for validation rules. Given the output schema exists, the description adds significant contextual completeness.
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 single parameter 'identifier' has 0% schema description coverage, but the description compensates richly: it explains both identifier types (code vs ID), case-sensitivity, validation rules, and provides examples. This fully documents the parameter's semantics.
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 explicitly states 'Retrieve detailed information about a specific voucher by its code or ID.' It clearly identifies the verb (retrieve), resource (voucher), and scope (specific voucher via code or ID). This distinguishes it from sibling tools like 'list_campaigns' or 'find_customer'.
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 includes explicit use cases, examples, and identifier type guidance. It does not explicitly state when not to use or contrast with siblings, but the 'Use Cases' section provides context for appropriate usage.
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?
Despite no annotations, the description thoroughly explains behavior: it analyzes order items against promotions, returns validation results with partial applicability, details return structure, pricing rules, item configuration options, and error handling. No contradictions; fully transparent.
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 well-structured with sections (purpose, use case, important note, parameters, examples, returns, errors). Front-loaded with goal. Minor redundancy: 'Parameters:' appears twice. Otherwise efficient for the complexity.
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 minimal schema and absence of annotations, the description covers all necessary aspects: parameter details, examples, return format, error handling, and differentiation from siblings. The output schema is not provided but its structure is described. Complete for a complex tool.
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?
Input schema has no description coverage (0%), but the description compensates with detailed explanations for both parameters. It describes customer and order structure, provides four item configuration formats, pricing rules, examples, and required fields. Adds significant meaning beyond the minimal 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 'Find top 5 best deal promotions for customer's order with validation analysis.' It specifies the action (find best deals), resource (promotions), and scope (top 5). It explicitly distinguishes from the sibling 'qualifications' tool by warning not to combine them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (upselling/cross-selling optimization) and includes a clear 'Important' note: 'Do not combine with 'qualifications' tool as they serve different purposes.' It guides when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses pagination behavior (100 per page, sorted by created_at descending), pricing conventions (cents), return structure (products, total, has_more), error handling (ToolError for invalid filters), and limitations (no custom sorting). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with core purpose. While lengthy, each section (params, filters, operators, examples, return, errors) adds unique value. Could be slightly tighter but remains effective and easy to scan.
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 2 optional parameters, no schema descriptions, and no output schema provided, the description covers all necessary aspects: purpose, parameters, filter semantics, return format, pagination, pricing, and error conditions. It is fully self-contained for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully. It explains both parameters: page (optional, default 1, hint for page 2+) and filters (detailed structure with supported fields, operators by type, and multiple examples). Adds meaning far beyond the raw 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?
Clearly states 'List products with optional filtering and pagination.' The verb 'list' and resource 'products' are specific. The description distinguishes this tool from siblings (which handle customers, campaigns, vouchers, etc.) by focusing on product catalog operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for product discovery, inventory analysis, catalog management. Details parameter usage, filter structure, operators, and examples. Includes exclusions like 'Custom sorting not supported' and error conditions, leaving no ambiguity about when and how to use.
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?
The description fully discloses behavioral traits: it returns an estimation, not precise; only works for 'Order paid' earning rules; limitations about tiers; error cases (400, 404). No annotations are present, so the description carries the full burden and does so thoroughly.
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 well-structured with sections (Critical, Limitations, Use Case, Parameters, Examples, Returns, Errors), front-loaded with purpose and critical notes. Every sentence adds value, and the length is appropriate for the complexity.
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?
The description covers all necessary context: purpose, limitations, parameter details, examples, error cases, and response format. Despite having an output schema, the description enhances understanding. No gaps remain for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all parameters in detail, including object structures, required fields, examples, and the relationship between loyalty_card and campaign_id. It fully compensates for the lack of schema descriptions.
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 estimates loyalty points for a given order, distinguishing from siblings by mentioning 'Combine with get_best_deals for comprehensive loyalty estimations.'
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?
Explicit use cases (checkout flows, before order placement) and limitations (estimation only, works only for 'Order paid' earning rules) are provided, along with when not to use and alternative tool suggestions.
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:

[![core-mcp MCP server](https://glama.ai/mcp/servers/voucherifyio/core-mcp/badges/card.svg)](https://glama.ai/mcp/servers/voucherifyio/core-mcp)

Score Badge

Copy to your README.md:

[![core-mcp MCP server](https://glama.ai/mcp/servers/voucherifyio/core-mcp/badges/score.svg)](https://glama.ai/mcp/servers/voucherifyio/core-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/voucherifyio/core-mcp'

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