MCP GraphQL Sales Server

by JamBelg

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct query pattern: order by ID, all orders, by customer name/ID, date ranges, summary, and raw GraphQL. get_orders_by_customer_name and get_orders_by_customer_id are similar but clearly differentiated by the lookup key. graphql_query could overlap with any tool but is explicitly raw and optional.
Naming Consistency4/5
Most tools follow a get_* pattern (get_order_by_id, get_all_orders, get_total_spent_by_customer), but graphql_query, test_connection, and the date-based tools (orders_after_date, orders_between_dates) deviate slightly. The naming is still intuitive and readable.
Tool Count5/5
10 tools is a well-scoped size for a sales query server. Each tool provides a distinct, useful capability without unnecessary redundancy, and the count fits comfortably within the ideal range for a focused server.
Completeness4/5
The server covers a comprehensive set of order-read operations: retrieval by ID, all, customer name/ID, date filtering, total spend, and summary statistics. A raw GraphQL query tool fills in gaps. Missing write operations and customer resource tools, but for a read-focused sales query server this is substantial.
Average 3.9/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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the return is a dict containing total spent or error information, which gives some transparency. However, it does not explicitly state that the operation is read-only, how errors are represented, or whether customer_name requires exact match.
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 compact and well-structured with Args/Returns sections. Every sentence earns its place, and there is no redundant fluff beyond the slightly repetitive parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is adequate for basic invocation. However, it lacks usage context relative to sibling tools, making it less complete for an agent deciding between options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (coverage 0%), so the description must compensate. Yet it only repeats the parameter name ('customer_name') with a near-identical phrase, adding no extra meaning about format, case sensitivity, or examples. Minimal value 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 action ('Get the total amount spent') and the resource (a customer). It distinguishes itself from sibling tools like 'get_orders_by_customer_name' or 'get_order_summary' by focusing specifically on total spend.
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 alternatives. There is no mention of required input format, exact matching, or scenarios such as 'use this for aggregated spending' versus other order-level tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It states it returns a dict with response or error information, but does not clarify whether this can execute mutations, require special permissions, or have rate limits. The term 'raw' hints at power but does not explicitly disclose risks.
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 concise and well-structured, with a clear purpose followed by Args and Returns sections. Every line adds value without redundant explanation.
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 description covers the basic purpose, arguments, and return type, and the presence of an output schema reduces the need to detail return values. However, it lacks guidance on when to use this raw tool versus siblings and does not mention potential side effects or use cases, leaving gaps for an AI agent deciding how to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters, so the description's Args section adds meaning by specifying that query is the GraphQL query string and variables are optional. This is helpful, though it does not provide examples or constraints beyond optionality.
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 runs a raw GraphQL query against the sales API, using a specific verb and resource. The word 'raw' distinguishes it from the specialized sibling tools like get_order_by_id, indicating it is a low-level, flexible query mechanism.
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?
There is no explicit guidance on when to use this tool versus the specialized sibling tools. The description mentions it is a 'raw' query but does not state when it should be preferred (e.g., for custom queries not covered by get_* functions).
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 the full burden. It does disclose that the return is a dict and may contain error information, but it does not mention specifics like exact matching behavior, duplicate customer names, or authentication requirements. Some behavioral details are present, but key operational nuances remain undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with an opening sentence followed by Args and Returns sections. It contains no filler and is easy to parse, though the Args section is redundant with the schema but necessary due to schema lacking descriptions.
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 one-parameter tool with an output schema, the description covers the core behavior and parameter, but it omits usage alternatives and edge cases (e.g., multiple customers with the same name). It is adequate but not fully complete.
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 coverage is 0%, so the description's Args section provides the only meaning for the parameter: 'customer_name: The customer name to search for'. This is a basic definition but does not add depth like case sensitivity, full vs. partial name, or formatting requirements.
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 all orders') and the scope ('for a specific customer by name'), using a specific verb and resource. It distinguishes itself from sibling tools like get_orders_by_customer_id (by ID) and get_all_orders (all customers).
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 that this tool should be used when a customer name is available, but it does not explicitly mention alternatives or exclusion criteria. Sibling tools like get_orders_by_customer_id are not referenced, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it tests a connection and returns a status dict, but doesn't mention whether it's read-only, performs a network call, or what failure behavior looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short sentences, with the main purpose front-loaded. There is no redundant information, making it efficient and clear.
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 tool, the description adequately covers purpose and return type. The presence of an output schema fills in return details. However, a brief note on when to use it (e.g., as a health check) would enhance completeness.
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 is empty (no parameters), so the description is not required to explain parameters. The baseline for zero parameters is 4, and no additional parameter semantics are 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 uses a specific verb ('Test') with a clear resource ('connection to the GraphQL endpoint') and states the return type (Dict with connection status). This clearly distinguishes it from sibling tools that query order data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. There is no mention of use cases, exclusions, or prerequisites, leaving the agent to infer appropriate usage.
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 the full burden. It discloses the return format ('Dict containing the order details or error information'), which is helpful. However, it does not explicitly state that the operation is read-only, mention permissions, or describe error conditions beyond 'error information', limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured with clear Args and Returns sections. Every sentence earns its place, with no 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 tool's simplicity (one parameter, no nested objects, output schema present), the description covers purpose, parameter, and return behavior. However, it could be more complete by explicitly guiding usage relative to the many sibling order-related tools, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains order_id as 'The order ID to search for', adding meaning beyond the schema's bare 'Order Id' title. This adequately describes the parameter for a simple lookup, though it lacks examples or format constraints.
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 'Retrieve a specific order by its ID', which is a specific verb+resource+scope. This distinguishes it from sibling tools like get_all_orders and get_orders_by_customer_name, which operate on different criteria or return multiple orders.
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 when you have an order ID and need that specific order, but it does not explicitly state when to use it over alternatives. No mention of when not to use or reference to sibling tools, so guidance is only implied.
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?
There are no annotations, so the description carries the burden of behavior. It states the return type 'Dict containing the customer's orders or error information' but does not explicitly mention read-only semantics, pagination, or side effects. While it gives some transparency, more detail would be beneficial.
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 concise, front-loaded with the purpose, and follows a clear structure with Args and Returns sections. No redundant text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description covers the core purpose, argument, and return shape. An output schema exists, so return details are presumably available, but the description also mentions 'error information' for completeness. It lacks explicit notes on error behavior or pagination, but these are not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 'customer_id: The customer ID to search for,' adding meaning to the schema's bare string type. With schema description coverage at 0%, this compensation is necessary and adequately clarifies the parameter's purpose.
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 'Retrieve all orders for a specific customer by ID,' providing a specific verb and resource. It distinguishes from siblings like get_order_by_id by indicating 'all orders' for a customer.
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 when a customer ID is available and all orders are needed, but it does not explicitly mention alternatives or when not to use this tool. No exclusions are provided, making the guidance implicit rather than explicit.
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 the burden. It mentions the return type (Dict with summary stats), but does not explicitly state that this is a read-only operation, whether any side effects exist, or if special permissions are required. The verb 'get' hints at safety but does not fully disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and a returns note. No filler words; 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?
Given it is a simple 0-param tool with an output schema, the description covers the essential purpose. It could explicitly contrast with get_all_orders for richer context, but the current information is sufficient for a correct invocation.
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 info, which is fine since there are no parameters to explain.
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 'Get a summary of all orders including counts and totals' - a specific verb, resource, and scope. This clearly distinguishes it from siblings like get_all_orders which likely returns individual orders.
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 aggregated summary rather than detailed order lists, but it does not explicitly say when to use this tool versus get_all_orders or other alternatives. No when-not-to-use or exclusion guidance is provided.
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 bears full responsibility for behavioral disclosure. It does reveal that the operation returns a dictionary containing all orders or error information, which is useful, but it does not explicitly state safety (e.g., read-only nature) or any potential side effects. For a simple retrieval, this is adequate but not rich.
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 concise and front-loaded: a single clear sentence stating the action, followed by a brief return description. Every word adds value, and there is no redundancy or filler.
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 nested objects) and the presence of an output schema, the description sufficiently covers behavior. It states the return format (dict of all orders or error info) and does not need to elaborate further. The context signals indicate the output schema exists, so return structure details are already captured.
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 zero parameters, and the schema description coverage is 100% (vacuously). Per the baseline rule for 0 parameters, a score of 4 is appropriate since the description does not need to explain parameters that do not exist.
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 'Retrieve all orders with complete details,' which is a specific verb+resource combination. The phrase 'all orders' distinguishes it from sibling tools like get_order_by_id or get_orders_by_customer_name, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need all orders, but it does not explicitly mention when not to use it or provide alternatives. There is no comparison to sibling tools, so the guidance is only 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.
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 mentions 'inclusive' boundaries and describes the return value as a dict with filtered orders or error information, which provides useful behavioral context. However, it does not disclose potential pitfalls like date validation or pagination.
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 well-structured docstring with Args and Returns sections. It is concise, with no fluff, and every sentence contributes to understanding.
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, the description covers purpose, parameters, and return value, and there is an output schema. It lacks mention of edge cases like start_date > end_date, but remains fairly complete for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), but the description compensates by explicitly stating the YYYY-MM-DD format for both start_date and end_date. It adds required meaning beyond the schema's simple titles.
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 all orders between two dates (inclusive). This is a specific verb and resource, and it is distinct from sibling tools like orders_after_date or get_all_orders.
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 date-range queries but does not explicitly differentiate from orders_after_date or other sibling tools. It lacks exclusions or alternative recommendations, so the agent may not know when to choose this over similar date-based tools.
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 carries the full burden of disclosing behavior. It explicitly states that filtering is done locally (a key implementation detail) and that the return is a dict containing filtered orders or error information. This adds meaningful behavior beyond what a static schema would reveal, though it could mention performance implications of fetching all orders first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It opens with the core purpose, includes a brief note on filtering behavior, and then clearly lists arguments and returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the input format, return type, and filtering behavior. It could specify whether 'after' includes the given date, but this is a minor gap and not essential for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'date' as a string with no description. The tool's description adds critical format information (YYYY-MM-DD) in the Args section, which is essential for correct invocation. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve all orders after a given date (YYYY-MM-DD)' with a specific verb, resource, and scope. It distinguishes itself from siblings like orders_between_dates (range) and get_all_orders (no filter) by emphasizing the date-based filtering.
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 note 'This filters locally since the GraphQL schema doesn't have date filters' provides helpful context on why this tool exists and when to use it. However, it does not explicitly mention alternatives like orders_between_dates for range queries or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![MCP-graphql-Claude MCP server](https://glama.ai/mcp/servers/JamBelg/MCP-graphql-Claude/badges/card.svg)](https://glama.ai/mcp/servers/JamBelg/MCP-graphql-Claude)

Score Badge

Copy to your README.md:

[![MCP-graphql-Claude MCP server](https://glama.ai/mcp/servers/JamBelg/MCP-graphql-Claude/badges/score.svg)](https://glama.ai/mcp/servers/JamBelg/MCP-graphql-Claude)

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/JamBelg/MCP-graphql-Claude'

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