Spark Customer Agent MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: the product browsing, cart management, coupon, and ordering operations are all separate. The only potential overlap is get_products_by_category and get_smartphones_by_price, but the latter explicitly narrows to a specific category and price filter, making the distinction clear.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case. Retrieval operations start with 'get', cart modifications use 'add_to'/'remove_from', coupon actions use 'apply'/'remove', and ordering uses 'place'. This uniform structure makes the tool names predictable and easy to navigate.
Tool Count5/5
Ten tools is well-scoped for a customer agent focused on e-commerce. The set covers product discovery, cart management, coupon handling, and order placement without superfluous or redundant tools, making it neither too sparse nor bloated.
Completeness4/5
The tool set covers the core shopping lifecycle: browse by category/price, manage cart with items and coupons, place order, and view history. However, it lacks a direct product detail lookup or search by name/attribute, which is a notable but non-critical gap for agents handling product-specific queries.
Average 3.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
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?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states the operation ('Fetch all products') but does not mention response format, pagination, read-only nature, permissions, or any potential side effects. For a simple fetch this is minimal but lacks meaningful transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the purpose, and the second sentence provides the list of valid categories, which is useful for quick agent reference. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the basics: what it fetches and the allowed categories. However, it omits any mention of the return structure, sorting, or whether 'all' products could be paginated or limited. Given the lack of annotations, this is a moderate gap, but the tool's simplicity keeps it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'category' parameter with a complete enum and description. The tool description repeats the category list without adding additional semantic meaning, so it neither enhances nor detracts from the schema. Baseline of 3 is appropriate.
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 ('Fetch all products') and resource ('from a specific category'), and lists the exact categories available. It is distinguishable from siblings like get_cart_items or get_order_history, though it does not explicitly contrast with get_smartphones_by_price, which is a narrower category-specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever you need products from a listed category—and the category list provides concrete context. However, it does not explicitly state when not to use it or mention alternatives like get_smartphones_by_price for price-filtered results, leaving some ambiguity.
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 for behavioral disclosure. It only states the basic action and quantity parameter, but does not disclose potential side effects, error conditions, behavior for duplicate items, or whether the cart is user-specific. This is a significant gap for a mutation 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 a single, clear sentence that is front-loaded with the action and resource. It contains no wasted words and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with complete schema documentation, the description is minimally adequate. However, the lack of behavioral context (e.g., what happens if productId is invalid or quantity is beyond stock) and the absence of annotations make it less complete than it could be. It does not explain return values or errors, but since there is no output schema, that responsibility falls to the description.
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 itself documents both parameters. The description adds minimal value beyond the schema, only echoing 'with specified quantity'. However, since the schema is complete, the baseline score 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 verb 'Add' and the resource 'product to shopping cart', which directly distinguishes it from sibling tools like remove_from_cart and get_cart_items. It also mentions the key parameter 'quantity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to add items to the cart. However, it does not explicitly mention when to use it versus alternatives or any exclusions, such as whether the product must exist or whether the cart must be active. The sibling names provide context but the description itself lacks this guidance.
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 action but does not mention side effects (e.g., replacing an existing coupon, validating against available coupons), error behavior, or reversibility. This is a significant gap for a mutation 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 a single, concise sentence that communicates the essential action immediately. There is no redundant or superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the absence of annotations and output schema means the description must cover expected outcomes and errors. It does not explain what happens on success/failure or whether the coupon replaces an existing one. This leaves gaps, though the core purpose is clear.
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 100% coverage for the single parameter coupponCode with a description. The tool description adds no additional meaning or format details, so it meets the baseline without exceeding 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 uses the specific verb 'apply' with the resource 'discount coupon to the shopping cart', clearly distinguishing it from sibling tools like remove_coupon and get_available_coupons. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use ('apply a discount coupon'), but it does not provide explicit context such as prerequisites (e.g., cart must exist) or when not to use it (e.g., if a coupon is already applied). It is functional but lacks guidance on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Remove a product' without detailing side effects, quantity behavior, error conditions, or return values. The removeAll parameter is handled by the schema, but the description itself does not clarify, for example, whether a single unit or all units are removed by default.
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, grammatically correct sentence with no unnecessary words. It is front-loaded with the key verb and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description is minimally adequate: it states the operation and the schema covers parameter semantics. However, it lacks any usage guidance or behavioral context (e.g., what happens when the product is not in the cart, or the return payload), making it incomplete for an AI agent facing unfamiliar situations.
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 'productId' and 'removeAll' adequately. The tool description adds no additional parameter context, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (a product), and the context (shopping cart). It is immediately distinguishable from sibling tools like 'add_to_cart' and 'get_cart_items', conveying a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage but does not explicitly say when to use this tool versus alternative tools such as 'add_to_cart' or 'remove_coupon'. No exclusions or conditional context are provided, leaving the usage to be inferred from the tool name.
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 responsibility for behavioral disclosure. 'Place an order' implies a mutation but does not disclose important side effects such as whether the cart is cleared, whether payment is required, whether an order record is created, or what the return value will be.
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, direct sentence with no filler or repetition. Every word earns its place, and it is appropriately sized for a tool with no parameters.
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?
Without annotations or an output schema, the description needs to convey more about post-conditions and return values, but it only states the action itself. For an order-finalization tool, important behavioral context such as cart clearing, order confirmation, and error cases is missing.
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 zero properties and schema description coverage is 100%, so there are no parameter semantics to document. The baseline score of 4 is appropriate because the description does not need to compensate for missing parameter documentation.
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 ('Place an order') and identifies the resource/scope as 'current cart items', distinguishing it clearly from sibling tools like get_cart_items, get_order_history, and add_to_cart. It conveys a finalization action rather than a query or cart modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current cart items' implies this should be used after building a cart, but it does not explicitly state when to use it versus alternatives like apply_coupon or when not to use it. There is no mention of prerequisites or alternatives, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states 'Fetch' which implies a read-only operation, but it does not disclose whether authentication is required, what data is returned (e.g., fields, order of results), or if there are any side effects. This is a minimal description with no safety guarantees or behavioral 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?
The description is a single short sentence that clearly states the tool's purpose without wasted words. It is well-structured and front-loaded with the action verb and resource.
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 has no parameters and no output schema, the description is relatively simple. However, it does not explain what 'transaction details' include, how far back history goes, or how results are ordered. For a zero-parameter read tool, this is adequate but leaves gaps about the return value and 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 the baseline is 4. The description adds no parameter semantics because there are no parameters to document. Schema coverage is trivially 100% with an empty properties object, so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Fetch') and resource ('order history and transaction details'), which distinguishes it from sibling tools like get_cart_items (current cart) and get_products_by_category (catalog). The verb+resource combination is specific and unambiguous.
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 usage is implied by the tool name and description: it is for retrieving past order information. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., when to use get_cart_items for current cart, or place_order for creating orders). No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. 'Fetch' implies a read-only operation, but it does not explicitly state that it does not modify state or any limitations like pagination. The qualifier 'available' suggests only valid coupons, but this is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. Every word earns its place with no wasteful 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?
For a zero-parameter, simple fetch operation, the description is largely sufficient. It clearly states the action and scope. However, the absence of an output schema means it does not hint at the return structure (e.g., array of coupon objects), which would be useful.
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 the description does not need to explain parameter meanings. The schema coverage is trivially 100%, and the description's focus on 'all available' adds a scope nuance beyond the empty 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 uses a specific verb 'fetch' and a clear resource 'available coupons and discount codes'. It distinguishes itself from sibling tools like apply_coupon and remove_coupon by focusing on retrieval rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like apply_coupon or get_cart_items. There is no mention of context such as 'use before applying a coupon' or exclusions.
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 only states the core action without revealing behavior such as whether it fails gracefully when no coupon exists, idempotency, or what the response looks like. For a mutation tool, this is insufficient.
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?
A single concise sentence that gets directly to the point, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation (no parameters, no output schema), the description adequately conveys the main purpose. It could be improved by addressing edge cases like the absence of an applied coupon, but overall it is complete enough for a straightforward removal action.
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 is trivially 100% covered. The description does not need to add parameter semantics, and the baseline of 4 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 'remove' and clearly identifies the resource ('the applied coupon') within the context of the shopping cart. This distinguishes it from sibling tools like apply_coupon and remove_from_cart.
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?
Usage is implied: the tool is for removing a coupon that is currently applied to the cart. However, it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or conditions like what happens if no coupon is applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Fetch', which implies a read-only operation, but with no annotations provided, it does not disclose additional behavioral details such as side-effect-free guarantees, return format, or any prerequisites. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, with no redundant words 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?
For a zero-parameter, zero-output-schema tool, the description sufficiently conveys the tool's purpose and scope. There are no complex behaviors or inputs to explain, though it does not detail the return structure in added depth.
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 defined, so the description has nothing to clarify in terms of parameter semantics. Per rubric, zero parameters earns a baseline score of 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 uses a specific verb 'Fetch' and clearly identifies the resource as 'all items currently in the shopping cart'. This unambiguously distinguishes it from sibling tools like get_order_history or add_to_cart, and there is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing current cart contents, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or scenarios, so the usage context is only implied rather than clearly stated.
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 discloses the filtering behavior (by max price) and scope (smartphones only), which is transparent for a simple read-only operation. It lacks mention of return format or no-match behavior, but these are less critical for a straightforward filter 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?
Two concise sentences with zero waste. The first sentence states the function; the second adds the crucial qualification that it is smartphone-specific. Excellent structure.
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's simplicity (one parameter, no output schema, no annotations), the description covers all essential aspects: what it does and its scope. It also differentiates from sibling tools. Omission of return format is acceptable for a basic filter 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?
Schema coverage is 100% and the schema already describes maxPrice well. The description only repeats the concept of maximum price without adding new semantic details. Thus the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Filter' with resource 'smartphones' and constraint 'maximum price'. The second sentence explicitly states it filters smartphones only, clearly distinguishing it from sibling tools like get_products_by_category. This is more than a tautology; it adds valuable 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 clearly implies when to use this tool: when you need smartphones filtered by max price. The 'smartphones only' phrasing indicates it is not for other product categories, giving context. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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