Gameball MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Many tools target distinct resources (balance, tier progress, referrals, activities), but overlaps exist: getCustomer vs getCustomerDetails, removeCustomerTags vs removeCustomerTag, and the docs-lookup-topic/search-docs and get-doc/get-tutorial pairs could confuse agents.
Naming Consistency2/5
The tool set mixes two conventions: docs tools use hyphenated lowercase with a docs- prefix (e.g., docs-lookup-topic), while API tools use camelCase verbs (e.g., createCustomer, getCustomer). Pluralization is also inconsistent (removeCustomerTags vs removeCustomerTag).
Tool Count2/5
40 tools is excessive for a single server, especially with ~15 getCustomer* variations. This makes selection harder and suggests tools could be consolidated into parameterized endpoints.
Completeness3/5
The server covers a broad range of Gameball operations (customers, orders, campaigns, referrals), but lacks obvious operations like updating a customer or fetching a single order. Documentation tools are comprehensive, but the API surface is not fully CRUD-complete.
Average 2.2/5 across 40 of 40 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 disclosing behavior. It only mentions 'Get detail' and a lock emoji, which does not explain any behavioral traits such as required permissions, return format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not appropriately concise; it is under-specified. 'Get detail' conveys no useful information and the lock emoji adds no clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description is completely inadequate. It does not explain what 'details' are returned or how the tool behaves, making it impossible for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, customerId, with no description, and schema description coverage is 0%. The description does not mention customerId or add any meaning to it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detail' is a tautology, merely restating the tool name 'getCustomerDetails' without specifying what resource or scope is involved. It does not distinguish this tool from siblings like getCustomer or getCustomerHash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools. No context, prerequisites, or alternative exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It fails entirely: no mention of side effects, required permissions, data mutations, or return behavior. The verb 'create' implies mutation, but the tool name suggests 'achieve', adding confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. The emoji and fragment 'Create social-challenge' provide no useful structure or front-loaded information that the tool name doesn't already imply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain the tool's functionality, parameter usage, or expected behavior, leaving a critical knowledge gap for an AI agent selecting or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters (email, mobile, customerId, challengeId). The description adds zero meaning beyond the schema, leaving the agent to guess the role of each parameter and which are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create social-challenge' provides a verb and resource, but it contradicts the tool name 'achieveSocialChallenge' (create vs. achieve) and adds no specificity about what the tool actually does. It reads as a rephrasing of the name rather than a meaningful functional description, leaving the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or when to prefer alternatives. No context, prerequisites, or exclusions are provided, and sibling tools offer no clues since no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects, permissions, or mutability, but it does not. The lock emoji is unexplained and adds no actionable behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague phrase, which is under-specification rather than effective conciseness. It does not earn its place because it omits essential information about the tool's purpose and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an inadequate description, the tool lacks all essential context. The two required parameters are undocumented, and the tool's effect on the system is entirely undisclosed, leaving an agent unable to safely select or invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the meaning of customerId or tags. It does not clarify whether tags is a single tag, a comma-separated list, or a JSON array, making correct invocation impossible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create tag' is misleading: the tool name 'attachCustomerTags' implies attaching tags to a customer, but the description says 'create' without mentioning customer or attachment. It may be confused with creating a tag definition rather than attaching existing tags. It does not distinguish from siblings like removeCustomerTags.
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 such as removeCustomerTags or other customer-related operations. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavior. It reveals no side effects, permissions, or output characteristics. The verb 'create' implies mutation, which contradicts the tool name's implication of a calculation, adding confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words long, which is under-specification rather than concise efficiency. It does not convey any actionable information and fails to earn its place as a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (9 parameters, nested objects, no output schema, no annotations), the description is completely inadequate. It provides no context about what the tool computes, what inputs matter, or what the caller should expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 9 parameters and only 22% schema coverage, the description needed to explain key inputs but mentions none. The schema itself has sparse descriptions (e.g., 'This object contains deta'), so the description adds no value in clarifying parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create cashback' uses a different verb than the tool name ('calculate') and omits any reference to orders. It is misleading and does not clarify that this tool calculates cashback for an order. It fails to distinguish itself from sibling tools like calculatePaymentCashback.
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. The description does not mention any context, prerequisites, or exclusions, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information such as read-only status, error behaviors, or response format. The word 'Get' implies a read operation, but this is not explicitly stated, and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks essential information needed for correct tool usage, and the brevity does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic name and the existence of many sibling tools with overlapping purposes, this description is completely inadequate. It does not clarify what the tool returns, what the customerId refers to, or any operational context, making it impossible for an agent to confidently select and use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, customerId, with no description, and the tool description does not explain what this parameter represents or how it is used. Schema coverage is 0%, and the description fails to compensate, offering zero semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get customer' simply restates the tool name without adding any specificity about what customer data is retrieved or how it differs from sibling tools like getCustomerDetails or getCustomerCoupons. It is essentially a tautology, providing no distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 use cases, prerequisites, or exclusions, leaving the agent to guess which 'get' tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 'Get count' reveals nothing about side effects, authentication requirements, rate limits, or return format. The lock emoji hints at security but is unexplained, adding no real transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is under-specified rather than concise. '🔒 Get count' is a fragment that conveys no actionable information, wasting the opportunity to front-load useful content. It does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, one required, and no output schema, the description is completely inadequate. It provides no context about what the count represents, how filters work, or what the response looks like. This is a minimal helper that leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the tool description provides no parameter explanations. The customerId and activityType parameters are not mentioned at all in the description, and the truncated schema description for activityType adds minimal value. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '🔒 Get count' is almost entirely vague, failing to specify what entity is being counted or what resource it operates on. It restates the tool's name ('Count') without adding clarity about customer activities, distinguishing it poorly from sibling tools like getCustomerReferralsCount or getCustomerNotificationsCount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as getCustomerActivities (which likely returns the actual list) or other count tools. There is no mention of preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It does not mention that the operation is read-only (though likely), whether authentication is required, what the response format looks like, or if there are any side effects. The description is completely silent on these critical aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified rather than concise. It does not provide the necessary information about the tool's function or usage, so the brevity is a defect, not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no annotations, and minimal description, the context is wildly incomplete. An agent cannot infer what this tool returns, any pagination or filtering behavior, or how it relates to other coupon or customer tools. The description is inadequate for even basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes a single parameter, customerId, but the description provides no explanation of its meaning, format, or how it affects results. With schema description coverage at 0%, the description must compensate, but it fails to add any value beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get coupon' uses a verb and a resource, but is extremely vague—it does not specify that it retrieves coupons for a customer, what type of coupons, or how the customerId relates. It does not distinguish itself from sibling tools like getCustomerBalance or getCustomerDetails, and reads more like a label than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool, what problem it solves, or when to prefer an alternative. No context is given for typical use cases or exclusions, making it impossible for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 says '🔒 Get streak' – the lock emoji is ambiguous and does not clarify side effects, auth requirements, or return behavior. No useful behavioral information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a vague phrase and an emoji, with no meaningful structure or information. The brevity does not help because it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required parameters, no output schema, no annotations), the description is completely inadequate. It does not explain what the tool returns, any usage constraints, or how it fits into the larger set of customer progress tools. The lack of any explanatory content makes it nearly unusable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. Schema coverage is only 50% (campaignId has a brief 'campaign Id' description, customerId has none), and the description does not compensate for the missing parameter information. It fails to explain what each parameter represents or how they affect the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get streak' is a tautology that essentially restates the tool name 'getCustomerDailyStreakProgress'. It fails to specify that this is about daily streak progress or to distinguish it from sibling tools like getCustomerTierProgress or getCustomerStampsProgress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention any context, prerequisites, or scenarios where this tool is appropriate, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses almost nothing. It neither confirms read-only behavior explicitly nor explains return values, side effects, or required permissions. 'Get' implies a read but is not a sufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. It lacks essential information and does not earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the tool is underspecified for the AI agent. It cannot determine what a 'stamp' is, what the response looks like, or how this relates to similar progress-tracking sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters beyond the schema. The schema already provides a description for challengeId, but customerId is undocumented, and 'Get stamp' does not clarify how either parameter is used or related to stamp progress.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get stamp' provides a verb and a noun but omits the concept of 'progress' and lacks specificity. It does not distinguish this tool from siblings like getCustomerCampaignsProgress or getCustomerTierProgress, making its purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention challenge context, prerequisites, or any scenario where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to state that this is a mutating operation, what side effects occur, permission requirements, or return behavior. The word 'Update' is the only hint of a write operation, but it 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. The phrase 'Update read' provides negligible information and does not earn its place; it is more of a placeholder than a helpful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of output schema, and 0% parameter coverage, this description is completely inadequate. It fails to provide essential context such as function, usage, or side effects, making the tool nearly unusable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It does not explain what customerId or notificationIds represent, leaving the agent to rely solely on the schema which only provides field types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update read' is a vague fragment that fails to clearly state the tool's purpose. It implies updating a read status but does not explicitly mention notifications, making it ambiguous and not distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without direction on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely states 'Delete tag' with no mention of irreversibility, permission requirements, side effects, or scope (e.g., whether it deletes all tags or specific ones). The lock emoji hints at security but provides no factual content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A concise description should pack essential information into few words; this omits critical context about parameters and usage, making it nearly useless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a tool with two required parameters, no annotations, no output schema, and a minimal description, there is insufficient context for an agent to invoke it correctly. The description does not explain what a 'tag' is, how to format the tags parameter, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With an input schema of two required params (tags, customerId) and 0% description coverage, the description must compensate by explaining parameter meanings. It does not mention either parameter at all, leaving the agent to guess what 'tags' means (e.g., comma-separated list?) and how 'customerId' relates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete tag' is a near-tautology of the tool name 'removeCustomerTags', restating the action in simpler words without adding specificity. It fails to mention that tags are customer tags, and the singular 'tag' is ambiguous given the sibling tool 'removeCustomerTag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over its siblings (e.g., 'removeCustomerTag' singular) or any prerequisites, making it impossible for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description "Get validate" reveals nothing about side effects, return values, error behavior, or the meaning of validation. The tool could be read-only or have side effects, but no information is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extreme brevity is not conciseness; the description is under-specified and reads like a placeholder. It has no meaningful structure and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a 2-parameter input schema, the description must compensate but provides nothing. The tool's behavior, return format, and usage context are entirely absent.
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%, with clear parameter descriptions ('The referral code to validate' and 'Customer ID to prevent self-re'). Per rubric, the baseline is 3 even though the tool description adds no parameter-related value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply "Get validate", which is vague and does not identify a specific action or resource. It fails to distinguish this tool from dozens of sibling tools (e.g., getCustomer, getCustomerReferrals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about validation scenarios or the role of forCustomerId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for outlining behavioral traits. 'Create cashback' does not disclose whether the operation is a read-only calculation or a mutating creation, nor does it mention side effects, permissions, rate limits, or return values. The word 'create' actively misleads the agent into thinking this is a write operation, conflicting with the 'calculate' intent in the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, this is under-specification rather than genuine conciseness. The single phrase 'Create cashback' does not earn its place because it adds no meaningful information and is actually misleading. A concise description should still convey the tool's core purpose and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, nested objects, no output schema, and very limited schema descriptions. The description provides no context about how the calculation works, what inputs are critical, what the result represents, or how it relates to sibling tools. This is completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters, but schema description coverage is only 20%, with only 'merchant' and 'paymentDetails' having truncated descriptions. The tool description provides zero information about any parameter semantics, failing to compensate for the low coverage. The agent is left without clues about how to populate fields like 'totalTax', 'totalPaid', or 'customerId', making correct invocation very difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create cashback' is vague and misleading. The tool name suggests calculating payment cashback, but the description uses 'create' which implies a mutation operation rather than calculation. It fails to specify the resource or action clearly and does not distinguish itself from the sibling tool 'calculateOrderCashback'.
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 guidance on when to use this tool versus alternatives like 'calculateOrderCashback'. The description gives no context about triggers, prerequisites, or scenarios where this tool is appropriate. It is merely a two-word phrase with no actionable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as data sensitivity, return format, errors, or side effects. The lock emoji hints at security but is not a substantive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specifies the tool's function. Conciseness is only valuable when it preserves essential information; here, key semantics are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter, the description still fails to clarify what the hash is, how it is computed, or what the caller should expect. The tool is effectively opaque to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not mention customerId or explain its meaning. With only one parameter, the description should at least clarify that the hash corresponds to the given customer ID, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '🔒 Get hash' only restates the tool name without specifying whose hash or what kind of hash is returned. It lacks the resource clarity needed to distinguish it from sibling tools like getCustomer or getCustomerDetails.
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 guidance on when to use this tool or how it differs from alternatives such as getCustomer, getCustomerDetails, or other customer-related tools. The description provides no use-case context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 behavioral disclosure. It does not state whether the operation is read-only, if it requires specific permissions, what filters are applied, or what the returned count represents. The description 'Get count' gives no insight into behavior beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise efficiency. It lacks essential content such as what is being counted, parameter details, or use context. A good description should be brief but informative; this one provides no value, making it inadequate for guiding tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a count endpoint with three parameters, no output schema, and no annotations. A complete description should explain the return value (e.g., integer count), the role of lang and isRead, and the required customerId. The current description is entirely insufficient for an agent to understand the tool's behavior, especially without additional context.
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 input schema has partial coverage: lang and isRead have descriptions, but they are incomplete/truncated ('Language in which notification' and 'Filter notifications based on '), and customerId has none. The description adds no meaning to the parameters, failing to clarify the relationships between them or the purpose of each filter. Overall, the semantics are poorly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get count' is a tautology—it simply restates the tool name ('getCustomerNotificationsCount') without specifying what is counted. It fails to mention that this is a count of notifications for a customer and does not distinguish it from sibling tools like listCustomerNotifications or getCustomerActivitiesCount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the large set of sibling tools (e.g., listCustomerNotifications, markNotificationsRead, getCustomerActivitiesCount), there is no indication of the intended use case or comparisons, leaving the agent without context to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. '🔒 Get count' reveals nothing about side effects, required permissions, return format, or limits. The lock emoji suggests security but is not informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single vague phrase with an emoji does not earn the space; it occupies space without providing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple count tool with one parameter and no output schema, the description is grossly incomplete. It fails to state the entity being counted, the relationship to the customer ID, or any return details, leaving the agent to infer everything from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter customerId with no description, and schema description coverage is 0%. The description does not mention customerId or add any meaning to help the agent understand what to pass or why.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get count' is a tautology that only restates the 'Count' part of the tool name without specifying what resource is being counted. It lacks a clear verb-object-resource structure and fails to distinguish from siblings like getCustomerReferrals.
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 guidance on when to use this tool versus alternatives. Sibling tools like getCustomerReferrals exist, but the description gives no context for choosing the count variant over the list variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 'Get activitie' with a lock emoji reveals nothing about pagination, filtering, permissions, rate limits, or return structure. The lock emoji is ambiguous and not a substitute for explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely informative. A two-word truncated phrase with an emoji does not earn its place; it is a fragment that provides minimal value while failing to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with pagination and filtering parameters, no output schema, and no annotations, the description is grossly incomplete. It omits response format, pagination behavior, activity type options, and any auth or permission context, making it inadequate for an agent to invoke correctly.
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?
Schema coverage is 75% but the descriptions are truncated (e.g., 'Specifies the number of activi'), and the tool description adds no parameter semantics. The required customerId has no description, and limit/startAfter/activityType are only partially explained, leaving their roles unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get activitie' is a truncated tautology of the tool name, stating only a verb and an incomplete resource. It does not differentiate from sibling tools like getCustomerActivitiesCount or getCustomerDetails, and the misspelling undermines clarity.
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 usage guidance is provided. The description does not suggest when to use this tool over alternatives, nor does it mention any exclusions, prerequisites, or context in which it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 says nothing about side effects, permissions, read-only nature, pagination, or return behavior. The tool could be a read operation or something else, with no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is under-specification, not efficient conciseness. No structure, no front-loaded key information, and no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema or annotations, the description fails to provide essential context such as required inputs, what is returned, or any filtering behavior. It is far from complete enough for an agent to select and invoke confidently.
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 description adds no parameter meaning; customerId is undocumented and campaignType's schema description is truncated ('by a '). At 50% schema coverage, the description should compensate, but it is silent on both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get automation' is a vague, truncated restatement of the tool name rather than a precise function. It does not specify that it retrieves customer automation campaigns, nor does it differentiate from siblings like getCampaignsConfigurations or getCustomerCampaignsProgress.
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 given on when to use this tool versus the many sibling customer/getter tools. There is no context, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. The lock emoji is present but unexplained; there is no mention of read-only nature, authentication, pagination, filtering semantics, or what 'progress' means. The description is utterly non-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a fragment ('Get reward-campaigns-progres') with a typo, not a structured sentence. Shortness is not conciseness; it lacks even a subject-verb-object construction and omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and a domain with many similar tools, the description provides almost no context. It does not explain what 'progress' data is returned, how campaignId and campaignType filters work, or what lang controls.
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 75% (3 of 4 params described). The description itself adds no parameter meaning, but the schema already covers most parameters, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get reward-campaigns-progres' is essentially a typo-ridden restatement of the tool name itself, not a clear statement of function. It fails to differentiate from sibling tools like getCustomerStampsProgress or getCustomerTierProgress, which could also be described as 'get progress'.
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 guidance on when to use this tool versus alternatives. Sibling tools such as getCustomerAutomationCampaigns or getCampaignsConfigurations overlap in domain, but the description offers no contextual cues 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 exist, and the description only includes a lock emoji, which hints at authentication but doesn't explain permissions, side effects, or return behavior. The verb 'get' implies read-only, but that's also implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a fragment with a typo ('progres') and an unnecessary emoji. It's too terse to be informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain what the response contains, but it merely states the obvious, leaving the tool's behavior and result format unexplained.
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 provides descriptions for lang and expand, but customerId has none. The description adds no parameter semantics, and the expand value 'ti' remains undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '🔒 Get tier-progres' is essentially a restatement of the tool name with a typo, providing no additional purpose clarification. It doesn't specify what tier progress means or how it differs from sibling progress tools.
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 usage guidance is provided; the description doesn't mention when to use this tool versus getCustomerCampaignsProgress or getTiersConfigurations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not state that this is a read-only operation, what the return format is, or how pagination/filtering works. The description carries the full burden and fails completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely under-specified at just two words. This is not efficient conciseness but rather a lack of substance, providing no actionable information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, no output schema, and no annotations. The description 'Get notification' gives no information about behavior, return values, pagination, or filter semantics, making it severely incomplete for a list operation.
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 80%, so the baseline is 3. The tool description itself adds no parameter meaning, but the schema does provide some descriptions (albeit truncated). The description does not actively confuse, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get notification' is vague and under-specified; it does not clearly state that this tool lists notifications for a customer. It also fails to distinguish itself from sibling tools like getCustomerNotificationsCount or markNotificationsRead, which also relate to notifications.
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 guidance on when to use this tool versus alternatives, nor any mention of pagination, filtering, or prerequisites such as the customerId. The description provides no context for selecting this tool.
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, but it only implies mutation via 'create'. It does not disclose side effects, error behavior, whether multiple events are processed atomically, or any rate limits. The description adds no value beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified rather than concise. It omits essential context and does not earn its place, providing no more information than the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested events object, no output schema, and no annotations, the description is completely inadequate. It fails to describe return values, error conditions, expected input formats, or how to use the tool effectively. The tool is part of a large sibling set, making this especially insufficient.
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?
Schema description coverage is 50% (only 'events' has a brief description). The description does not clarify that customerId is required or what the events mapping should look like. No parameter examples or format hints are provided, so the gap in schema coverage is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create event' is essentially a tautology of the name 'sendEvents' and does not specify that it sends events for a customer or that it accepts multiple events. It also uses the verb 'create' while the tool name says 'send', creating ambiguity. No distinction from sibling tools like trackOrder is provided.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., customer existence) or scenarios in which this tool is appropriate. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It provides none: no mention of pagination, sorting, side effects, or response shape. The lock emoji is not explained and adds no clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. '🔒 Get referral' is a brief phrase but lacks essential structure and information. It is too short to be considered appropriately sized for a tool with three parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, this description is profoundly incomplete. It fails to explain what referrals are, how pagination works, or what the response contains, leaving the agent without adequate context.
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 description adds no meaning to the parameters. While the schema documents 67% of parameters, those descriptions are truncated ('Specifies the number of friend', 'Specifies the page will start '). The tool description does not clarify customerId, limit, or startAfter beyond what the incomplete schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '🔒 Get referral' is vague, stating only a verb and a resource without scope or detail. It does not clarify whether a single referral or a list is returned, nor does it differentiate from siblings like getCustomerReferralsCount. The tool name helps, but the description itself lacks specificity.
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 usage guidance is provided. The description does not indicate when to use this tool versus related tools such as getCustomerReferralsCount or getReferralsConfigurations, nor does it mention any prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It fails to state that this is a read-only operation, what it returns, or any permissions or side effects. 'Get' weakly implies read-only, but no substantive behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words long, but this is under-specification rather than effective conciseness. It omits essential context and provides no structural benefit, similar to a stub.
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?
The tool is simple (one parameter, no output schema), but the description is still inadequate. It does not explain what a 'referral configuration' is or what the response will contain, leaving the agent without enough information 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?
The input schema covers the single parameter 'lang' with a description ('If the lang header is provided'). Since schema coverage is 100%, the baseline score of 3 is appropriate; the description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get referral' is a vague fragment that essentially restates the tool name without adding specificity. It does not clarify that this retrieves configuration settings, nor does it distinguish from getCustomerReferrals.
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 instead of alternatives like getCampaignsConfigurations or getCustomerReferrals. The description gives no context about the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, 'Get tier' reveals nothing about side effects, return values, permissions, or operational characteristics. This is almost no transparency, not even implying a read-only operation clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two words), but this is under-specification rather than effective conciseness. Every word is present, but the phrase fails to communicate essential information, making it insufficient for proper tool selection or invocation.
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?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), one might expect a simple description to suffice, but 'Get tier' lacks any context about what a tier configuration is, how 'lang' affects results, or what the response contains. This is inadequate for an agent to correctly use the tool, especially with sibling configuration tools present.
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 description coverage is 100% (one parameter 'lang'), providing some baseline meaning. However, the description 'Get tier' adds no additional parameter semantics. The schema's description of 'lang' is ambiguous ('If the lang header is provided'), but per the rubric, high coverage yields a baseline of 3, which is maintained here since the tool description neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tier' is essentially a shortened restatement of the tool name 'getTiersConfigurations', offering no additional specification of what configurations or tiers are involved. It does not distinguish this tool from sibling tools like getCampaignsConfigurations or getReferralsConfigurations, making it tautological and vague.
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?
The description provides no guidance on when to use this tool, what scenarios it is appropriate for, or how it relates to alternatives. There is no mention of prerequisites, exclusions, or alternative tools, leaving the agent without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. It only says 'Delete tag', which implies a mutation but gives no details about side effects, irreversibility, permissions, or error conditions. The lock emoji is unclear and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('🔒 Delete tag') and could be considered under-specification rather than conciseness. It lacks enough structure to be useful, and the emoji adds no clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 required parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain the operation's context, return value, or consequences, leaving the agent without essential information.
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?
Schema coverage is 50% (only 'tag' has a description, and it's just 'tag'). The description does not compensate; it doesn't explain what 'customerId' represents or the format/scope of 'tag'. For a 2-parameter tool, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Delete') and resource ('tag'), but it is vague—doesn't specify 'customer' or that it removes a tag from a specific customer. The name 'removeCustomerTag' implies the customer context, but the description omits it, making it ambiguous. It also fails to distinguish from the sibling tool 'removeCustomerTags'.
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 like 'attachCustomerTags' or 'removeCustomerTags'. There is no mention of exclusions, prerequisites, or appropriate contexts.
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 says 'Create order' and offers no information about side effects, authentication, idempotency, or response behavior. The lock emoji hints at security but is too vague to be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise efficiency. For a complex 18-parameter tool, a single phrase like 'Create order' fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, nested objects, no output schema, no annotations), this description is grossly incomplete. It lacks all contextual information needed for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 39% schema description coverage and 18 parameters, the description should compensate by explaining parameter relationships or key fields. It adds no parameter information whatsoever, leaving required fields like customerId, orderId, orderDate, and totalPaid completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create order' clearly states a create operation on an order resource, but it fails to distinguish from sibling tools and directly conflicts with the tool name 'trackOrder', which implies tracking rather than creation. This internal inconsistency reduces clarity.
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?
The description provides no guidance on when to use this tool versus alternatives, no context, and no exclusions. It simply states 'Create order' with no mention of prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 behavioral disclosure, but 'Create customer' reveals nothing about side effects, required permissions, return values, or operational constraints. It does not contradict annotations (there are none), but it is completely silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two words, which is concise but severely under-specified for a tool with 8 parameters and no other documentation. It is not 'earning its place' as a helpful guide; it is a placeholder that fails to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 8 parameters, no output schema, and no annotations, the description is wholly inadequate. It does not explain what creating a customer involves, what the parameters mean, or what the response will be, leaving the agent without the context needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with only 13% description coverage (just a truncated note on customerAttributes). The description adds zero parameter information, failing to compensate for the low schema coverage. The sole required parameter customerId is not even mentioned, making the parameter semantics entirely unclear.
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 'Create customer' clearly states the action (create) and resource (customer), and it distinguishes from sibling tools like getCustomer and deleteCustomer. However, it is essentially a restatement of the tool name without adding any scope or detail, stopping short of the specificity seen in high-quality examples.
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?
The description provides no guidance on when to use this tool versus alternatives such as getCustomer or deleteCustomer. There is no mention of prerequisites, intended scenarios, or exclusions, leaving the agent to infer usage solely 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 must carry the full burden of disclosing behavioral traits. It only says 'Get reward-campaign' and does not mention return format, pagination, permissions, or any side effects, which is insufficient for a tool with no structured behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short fragment 'Get reward-campaign', which is under-specification rather than conciseness. It lacks a complete sentence and omits crucial context, making it more of a label than a useful description.
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?
For a tool with 4 parameters, no output schema, and no annotations, the description is critically incomplete. It does not explain the response structure, filtering logic, or how this tool fits into the broader reward-campaign system, leaving substantial gaps for an AI agent.
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 description adds no information about parameters. Although schema coverage is 75%, some parameter descriptions are truncated (e.g., 'The SKU (Stock Keeping Unit) o') and 'customerId' has no description. The tool description does nothing to clarify parameter usage or compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get reward-campaign' provides a verb and a resource, indicating it retrieves something related to reward campaigns. However, it is vague and doesn't explicitly mention 'configurations' as the name does, nor does it distinguish itself from sibling tools like getTiersConfigurations or getReferralsConfigurations.
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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't specify contexts, prerequisites, or exclusions, leaving the agent without enough information to decide among the many similar configuration-related 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The lock emoji is the only extra cue, but it is not a clear statement of authentication or side effects. The description does not mention permissions, response format, or any operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified rather than optimally concise. It does not provide enough substantive information to be useful, so the brevity is not a strength.
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?
With no output schema, no annotations, and only a terse description, the tool is contextually incomplete. It does not explain what the balance represents, what the response looks like, or when this tool should be invoked relative to other customer-related tools.
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?
Schema coverage is 50% because only the 'expand' parameter has a description, and that description is cryptic ('ti'). The tool description adds no information about customerId or expand, failing to compensate for the schema's gaps or clarify parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('balance'), but the resource is generic and does not explicitly state 'customer balance' or the scope. The parameter name customerId implies the connection, but the description itself is vague and does not distinguish from sibling tools beyond the unique resource.
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 guidance on when to use this tool versus alternatives like getCustomer or getCustomerDetails. The description offers no context, prerequisites, or exclusions, leaving the AI agent to guess based on the name alone.
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 responsibility for behavioral disclosure. It only implies a read operation via 'Get', but provides no details on return format, pagination, error behavior, or side effects. The lock emoji hints at security but is not explanatory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It omits essential information, so the one sentence does not effectively earn its place.
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?
There is no output schema and no description of return values. The tool is simple, but the description leaves uncertainty about whether it returns transaction details, a list, or something else. It is not complete enough for an agent to anticipate the tool's output.
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?
Schema description coverage is 0%, and the description adds no meaning to the single parameter 'orderId'. The parameter name is self-explanatory, but the description does not explain its format, source, or role, so it fails to compensate for the absence of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transaction' states a clear verb and resource, but it is vague: it does not specify that these are order transactions or whether it returns a list or a single item. It also does not differentiate from sibling tools like trackOrder or calculateOrderCashback.
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 prerequisites, context, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 behavioral disclosure. It merely repeats the tool name ('Delete customer') without revealing that deletion is likely irreversible, may cascade to associated data, or requires specific permissions. The description adds zero behavioral context beyond the literal action.
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 extremely concise ('🔒 Delete customer'), with every word (except the decorative lock emoji) contributing meaning. The emoji is extraneous and does not aid understanding, so it loses one point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and an undocumented parameter, the description is severely incomplete. It fails to mention effects (e.g., permanent deletion), return values, or error behavior, offering no safety net for an AI agent invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (customerId) with no description, and schema description coverage is 0%. The description does not attempt to compensate, failing to mention that customerId identifies the customer to be deleted or what format it should take.
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 'Delete customer' clearly states the action (delete) and the resource (customer), which is specific enough to distinguish it from sibling tools like createCustomer and getCustomer. The verb is explicit and the resource is unambiguous.
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?
The description provides no guidance on when to use this tool, any prerequisites (e.g., not deleting active customers, irreversibility), or alternatives. It simply states the action with no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. The verb 'Shows' implies a read-only operation, but the description does not state whether authentication is required, what happens if the server is unhealthy, or any side effects. This is a significant gap for a tool with no structured safety hints.
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 delivers maximum information in minimal words. Every word earns its place, with no redundancy or filler.
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 no-parameter tool with no output schema, the description gives a functional summary of the four areas covered. However, it lacks any detail about the response format, potential error conditions, or how to interpret the status information, leaving the agent with partial context.
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 schema provides complete coverage by default. The description adds value by enumerating the aspects covered (health, subsystem, configuration, cache), giving the agent a sense of what the response will contain.
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's function with a specific verb ('Shows') and resource ('server health, subsystem status, configuration, and cache info'). It is distinct from all sibling tools, which are focused on docs, customers, orders, and events.
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 context (checking server status) but does not explicitly state when to use it versus alternatives. Since no sibling tool offers the same functionality, the need for exclusion is minimal, but the lack of explicit guidance prevents a higher score.
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?
No annotations are provided, so the description carries the full burden. It states what the tool returns (details including schemas and example) and implies a read-only lookup, but it does not disclose any potential side effects, authentication requirements, or error handling. This is adequate for a simple documentation tool but not highly 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, front-loaded with the main purpose and followed by a usage note. There is no redundant information; every word 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?
Despite having no output schema, the description lists the key contents of the response (parameters, schemas, cURL example). It also provides sequencing with docs-lookup-topic. However, it does not explain how the three optional parameters should be combined to identify a specific endpoint, which would improve completeness.
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?
All three parameters have descriptions in the schema (100% coverage), so the schema already documents their semantics. The description does not add any additional parameter meaning beyond what the schema provides, matching the baseline for high 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 the tool's function: 'Get full details of a specific REST API endpoint including parameters, request/response schemas, and a cURL example.' This uses a specific verb and resource and distinguishes it from sibling tools by noting it should be used after docs-lookup-topic.
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: 'Use after docs-lookup-topic when you need details on a specific endpoint.' This tells the agent when to use the tool, but it does not explicitly mention alternatives or when not to use it, so it falls 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.
Behavior3/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 implies a read operation ('Get the full content') but does not disclose response format, error behavior, or authentication/rate-limit requirements. It adds some context (full content, by path) but lacks richer behavioral detail.
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 wasted words. The first sentence states the essential function, and the second provides usage guidance. Every part 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?
For a simple one-parameter get tool, the description gives a clear purpose and usage workflow relative to sibling tools. However, without an output schema, it does not specify the exact return format beyond 'full content', which leaves some ambiguity.
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% for the single parameter 'path', with a clear example provided. The description's mention of 'by path' is redundant with the schema, so it does not add significant meaning beyond what the schema already documents.
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 'Get the full content of a specific doc page by path' clearly identifies the verb (get), resource (doc page), and scope (by path). It also distinguishes from sibling tools by noting it should be used after docs-lookup-topic for reading a specific page in full.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use after docs-lookup-topic when you need to read a specific page in full.' This names the preceding tool and the condition, though it does not explicitly list exclusions or alternatives beyond that.
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?
No annotations are provided, so the description carries full burden. It clearly states the core action but does not disclose behavioral details such as the exact output format, whether it returns only a code snippet or includes explanatory text, or any limitations (e.g., unsupported languages). It adds some context by referencing docs-get-api-endpoint, but this is more usage guidance than behavioral 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 two sentences, front-loaded with the core purpose and followed by a useful usage distinction. No fluff or 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?
Given the low complexity (4 simple params, no output schema, no nested objects), the description is largely complete. It explains what it does, when to use it, and distinguishes it from the sibling. The only minor gap is a lack of description of the generated output's form (e.g., just a code snippet, or with explanation), but this is not critical for such a focused 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 description coverage is 100%, so parameters are already well-documented. The description does not add additional meaning to any parameter beyond what the schema provides, which warrants 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 states a specific verb+resource: 'Generate a code example for a Gameball API endpoint in a specific programming language.' It clearly distinguishes from sibling docs-get-api-endpoint by noting that cURL is already covered there. This makes 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user asks for code in a specific language' and contrasts with cURL, which is 'already included in docs-get-api-endpoint.' This provides clear when-to-use guidance and names the alternative tool.
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 accurately describes what the tool returns (tabs, sections, page slugs) and implies a read-only operation. It does not disclose potential limitations like size or hierarchy, but for a simple listing tool, the described behavior is sufficient.
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: the first states the function, the second states when to use it. No filler or redundancy. Front-loaded with the main action.
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 list tool with one optional parameter and no output schema, the description provides enough context: purpose, usage scenario, and output content (tabs, sections, page slugs). It could specify the exact return format (e.g., array vs. object) but that is a minor gap given the simplicity.
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 covers 100% of parameters with a clear description ('Drill into a specific section by name'). The tool description reinforces the notion of sections in its main text, so the parameter's purpose is evident. Baseline 3 is appropriate because the schema does the heavy lifting, and the description adds minimal extra semantics beyond that.
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 specific action ('List') and resource ('documentation structure') with concrete details ('tabs, sections, and page slugs'). It distinguishes itself from sibling tools like docs-get-doc and docs-lookup-topic by focusing on browsing the structure rather than retrieving specific content.
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 says when to use the tool: 'Use when the user wants to browse available topics or you need to discover page paths.' It gives clear context but does not explicitly contrast it with alternatives by name, though sibling tool names are visible in the context.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (titles and snippets) and full-text behavior, but does not mention any limitations, authentication needs, or the nature of the search (e.g., ranking, exact match). For a read-only search tool, 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?
Two short, front-loaded sentences. The main purpose is stated first, followed by clear usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explains the return content (titles and snippets). With 3 well-documented parameters and explicit usage guidance, the description is complete enough for a search tool. It could mention result ordering or limits, but it is not necessary.
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 all parameters. The description adds minimal meaning beyond saying you can search within a section, which aligns with the `section` parameter. Baseline 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 this is a full-text search across all Gameball docs, returning titles and snippets. It differentiates itself from the sibling `docs-lookup-topic` by explicitly mentioning that use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'Use when docs-lookup-topic did not find what you need or you need to search within a specific section.' This directly instructs the agent on selecting this tool over alternatives.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool retrieves a specific tutorial and returns 'full step-by-step tutorial content,' which implies a read-only operation. However, it does not explicitly mention authentication requirements, potential side effects, or limitations beyond the sibling differentiation, leaving some behavioral details unspecified.
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 with the core purpose. It uses three short sentences to convey what the tool does, when to use it, and how it differs from a sibling, with no redundant 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?
For a simple tool with one parameter and no output schema, the description is complete. It states the exact use case, the alternative for broader queries, and hints at the return content ('full step-by-step tutorial content'). No critical information is missing given the tool's low complexity.
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 covers the single parameter 'topic' with a description and examples, achieving 100% schema_description_coverage. The tool description adds no additional parameter semantics beyond what the schema already 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 clearly states the tool's function: 'Get a specific Gameball tutorial by topic.' It uses a specific verb ('get') and resource ('tutorial'), and distinguishes from sibling tools by explicitly mentioning docs-lookup-topic as an alternative for broad questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use when you need the full step-by-step tutorial content.' It also provides an exclusion: 'For broad questions, use docs-lookup-topic instead,' which clearly directs agents away from this tool for broader queries.
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 of behavioral disclosure. It discloses the return composition (tutorials, related docs, API endpoints), the 'single-call' nature, and positions itself as an entry point. It does not explicitly mention read-only status, response size, or error handling, which keeps it from a 5.
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 three concise sentences, is front-loaded with 'START HERE', and each sentence has a clear purpose: define the tool, give usage guidance with examples, and indicate when to use alternatives. 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential context: purpose, when to use, return types, and relationship to sibling tools. It is complete enough for an agent to select and invoke correctly.
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 already covers 100% of the one parameter 'topic' with a description, so the baseline is 3. The description adds extra value by providing example topics ('order redemption', 'referral', 'points') and explaining how the parameter is used in a broad question, going beyond the schema's generic definition.
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's function: 'Comprehensive single-call lookup that returns tutorials, related docs, AND relevant API endpoints for a topic.' It uses a specific verb and resource, and explicitly distinguishes itself from siblings by saying 'Use this first' and 'Only use the other tools if you need to drill deeper into a specific page or endpoint.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this first for any broad question' with concrete examples like 'how to create an order with redemption' and 'referral setup'. Also gives an exclusion: 'Only use the other tools if you need to drill deeper into a specific page or endpoint.' This clearly covers usage versus alternatives.
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:

[![gbx-mcp-beta MCP server](https://glama.ai/mcp/servers/Ahmedelmonady/gbx-mcp-beta/badges/card.svg)](https://glama.ai/mcp/servers/Ahmedelmonady/gbx-mcp-beta)

Score Badge

Copy to your README.md:

[![gbx-mcp-beta MCP server](https://glama.ai/mcp/servers/Ahmedelmonady/gbx-mcp-beta/badges/score.svg)](https://glama.ai/mcp/servers/Ahmedelmonady/gbx-mcp-beta)

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/Ahmedelmonady/gbx-mcp-beta'

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