KiezelPay Sales MCP

Overview Schema Related Servers Score Discussions

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 aspect of sales data: products, account summary, daily stats, raw purchases, and product-level aggregates. The only close pair, get_sales_today and get_sales_yesterday, are clearly separated by the day in their names and descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (list_products, get_sales_summary, get_sales_today, get_sales_yesterday, get_purchase_history, get_product_sales). The mix of 'list' and 'get' is standard and predictable, with no camelCase or chaotic variations.
Tool Count5/5
Six tools is well-scoped for a sales-focused MCP server. Each tool covers a distinct need without redundancy, making the set feel intentional and manageable.
Completeness4/5
The tool surface covers the core sales questions: summary, daily performance, raw history, product listing, and per-product breakdowns. Minor gaps exist, such as no arbitrary date-range sales tool or explicit trial/refund analytics, but these can be worked around via purchase history and product sales.
Average 4.3/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
- 1 commit 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that output is derived from purchase history and is deduplicated ('distinct'), which is useful behavioral context. It lacks details such as ordering, time window, or that 'limit' controls scans rather than results, which is only covered in the schema. Without annotations, the description carries a moderate burden but is not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, front-loading the action and purpose. It is appropriately concise and every sentence earns its place.
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 tool is straightforward, and the description covers functionality and intended use. However, it omits return format and the meaning of 'recently,' and with no output schema or annotations, the agent gains limited context beyond basic usage.
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 single parameter 'limit' is fully described in the schema with a clear explanation ('How many recent purchases to scan'), providing 100% coverage. The tool description adds no additional parameter-specific semantics, only reinforcing the data source, so the baseline of 3 is appropriate.
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 states a specific action ('List the distinct product names sold recently') and clarifies its purpose ('discover which products exist before analyzing one'). This distinguishes it from sibling tools like get_product_sales that focus on metrics.
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 instructs when to use it ('Use this to discover which products exist before analyzing one'), giving clear context for tool selection. However, it does not explicitly name alternatives or exclusion criteria, falling just short of full guidance.
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 transparency burden. It discloses that revenue is included only conditionally ('if the history records carry a price'), which is a meaningful behavioral nuance. It also implies the tool aggregates from purchase history rather than direct sales data. It does not cover edge cases like empty history or limit-based truncation, but the core behavior is well conveyed.
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, tightly written sentence that front-loads the purpose and lists concrete output components. Every phrase adds information, with no redundancy or filler.
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 is sufficiently complete for a simple aggregation tool without an output schema. It covers the main return values and the conditional revenue behavior. Minor gaps remain around limit behavior and edge cases like no matching history, but these are not critical 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (product and limit) are already described in the schema. The description adds no extra semantic detail beyond what the schema provides, such as the fact that limit controls how many purchases are scanned. This meets the baseline for full schema coverage but does not exceed it.
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 a specific verb ('Get') and clearly identifies the resource ('aggregated sales for a single product'). It enumerates the exact outputs (purchase count, first/last sale, breakdowns by country, platform, trigger) and distinguishes this tool from generic sales summaries or raw purchase history.
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 context by emphasizing 'single product' and 'derived from purchase history,' which differentiates it from broader summary tools. However, it does not explicitly state when to prefer this tool over get_sales_summary or get_purchase_history, nor does it mention alternatives 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?
No annotations are present, so the description carries the full burden. It lists all fields returned per record (paidDate, product, productId, country, platform, device, gross, net, status, isRefunded), which is valuable beyond the input schema. The read-only nature is implied by 'Get' and no side effects are mentioned, but the return-field disclosure compensates.
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 long, front-loaded with the core action, and every phrase adds value. The first sentence states what it does, the second lists output fields and gives usage guidance. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description compensates by enumerating the returned fields. It also provides usage context. However, it does not mention pagination or the constraint that recent is bounded by the limit parameter, though that is in the schema. Overall, it is adequately complete for a read-only list 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 already provides 100% coverage for all parameters (sort, limit, platform) with descriptions. The description does not add any semantics beyond what the schema says (e.g., 'recent' aligns with sort/limit defaults). Baseline 3 is appropriate because the 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 says 'Get recent individual purchases' with a specific verb and resource, and clarifies it returns granular purchase-level data. It distinguishes itself from sibling summary tools like get_sales_summary and get_product_sales by stating 'Use for detailed, purchase-level questions.'
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 gives clear context for when to use the tool: 'Use for detailed, purchase-level questions.' It implies not to use it for summary/aggregate questions but does not explicitly name alternative tools or state when not to use it, so it misses a 5.
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 adds a valuable behavioral detail about using the local timezone for the day boundary and clarifies that the output includes a merchant rank, which is not obvious from the name alone. It does not disclose rate limits or side effects, but as a read-only 'get' operation, that is acceptable.
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 concise sentences effectively front-load the main purpose and then add a relevant timezone note. There is no redundant or filler content, making it highly efficient.
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 tool with one optional parameter and no output schema, the description adequately explains what the tool does, what it returns, and the relevant timezone behavior. It is complete enough for an agent to understand the tool's function and invoke it 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?
The schema already provides a complete description for the platform parameter, including valid values ('fitbit' or 'garmin') and behavior when omitted. The tool description adds no additional parameter semantics beyond what the schema states, so the baseline of 3 is appropriate.
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 today's sales, specifying the metrics returned (number of purchases, revenue amount, rank). It distinguishes from siblings like get_sales_yesterday by explicitly scoping to today and noting the local timezone boundary.
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 clear context that this tool is for today's sales and uses the local timezone. While it doesn't explicitly name alternatives or exclusions, the 'today' scope and sibling names like get_sales_yesterday make the usage context clear without needing further guidance.
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 the full burden. It discloses the return fields (purchases, revenue, rank) and the timezone behavior, which is valuable context. It does not discuss side effects or auth, but for a read-only sales query this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover all essential information without padding. The first sentence lists the outputs, and the second clarifies the timezone detail—no wasted words.
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 query with one optional parameter and no output schema, the description is complete: it names every returned field and the timezone nuance. There is no missing behavior that the agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (platform) with allowed values and default. The description adds no extra parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically identifies the resource (yesterday's sales), the verb (get), and the exact outputs (purchases, revenue, rank). It clearly distinguishes from siblings like get_sales_today by the explicit 'yesterday' scope.
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 by specifying the time period (yesterday) and timezone boundary, making it obvious when to use this tool. However, it does not explicitly mention alternatives or exclusions relative to sibling tools like get_sales_summary or get_sales_today.
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 thoroughly discloses the return contents (current balance, total purchases, income, active trials, paid out, payout details), which is the key behavior. It does not explicitly state read-only or side effects, but the verb 'Get' implies a safe read 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, front-loaded sentence that names the resource and enumerates all the aggregated data points without redundant words or fluff.
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 is complete. It lists all the data points returned, leaving no ambiguity about the tool's scope.
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, so schema coverage is trivially 100%. The description need not provide any parameter details, and the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('KiezelPay account sales summary') and enumerates the key metrics (balance, purchases, income, trials, payouts). This clearly distinguishes it from sibling tools like get_sales_today and get_sales_yesterday which focus on specific periods.
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 clearly implies the tool is for an overall account summary, which provides clear context. However, it does not explicitly state when to use this over sibling tools like get_sales_today or get_sales_yesterday, nor does it mention exclusions. This is close to 'clear context, no exclusions'.
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:

[![KiezelPay-Sales-MCP MCP server](https://glama.ai/mcp/servers/skusVV/KiezelPay-Sales-MCP/badges/card.svg)](https://glama.ai/mcp/servers/skusVV/KiezelPay-Sales-MCP)

Score Badge

Copy to your README.md:

[![KiezelPay-Sales-MCP MCP server](https://glama.ai/mcp/servers/skusVV/KiezelPay-Sales-MCP/badges/score.svg)](https://glama.ai/mcp/servers/skusVV/KiezelPay-Sales-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/skusVV/KiezelPay-Sales-MCP'

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