Create a shop program, hand customers a browser stamp card by QR poster, stamp it from a phone.
Scored across 5 tools
Each tool targets a unique resource-and-action pair: program creation/update, card reading, program stats, reward redemption, and stamping. Descriptions clearly differentiate card-level vs program-level operations, leaving no ambiguity.
All names are lowercase snake_case, but the pattern is mixed: create_program and get_card are verb_noun, program_stats is noun_noun, and redeem/stamp are single verbs. This makes the naming less predictable than a uniform verb_noun convention, though still readable.
With 5 tools, the server is well-scoped for its purpose. Each tool receives a clear job, and there is no redundancy or unnecessary bulk.
The tool set covers the full stamp-card lifecycle: program setup, card lookup, stamping, redemption, and usage stats. No essential operations are missing for the stated purpose of small-shop digital stamp cards.
Create or update the shop program: shop name, reward text, stamps required before a reward. Returns the program and its join URL (the poster target).
| Name | Required | Description | Default |
|---|---|---|---|
| shop | Yes | ||
| reward | No | ||
| stamps_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose that the tool can both create and update and that it returns the program and join URL, which is useful. However, it does not explain side effects of updating, such as whether an existing join URL is invalidated or whether certain fields reset, leaving some ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core action, then covers the parameter semantics and return value. There is no filler or repetition; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the description covers the action, parameters, and return value. The main gap is the missing detail on how updates behave when optional fields like reward or stamps_required are omitted, which an agent would need for correct update calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the absence of parameter documentation. It does so by mapping each parameter to plain language: shop name, reward text, and stamps required before a reward. It does not cover update-specific behavior, but all parameter meanings are conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create or update') on a specific resource ('the shop program') and names the exact fields involved. This clearly distinguishes it from siblings like redeem, stamp, and get_card, which operate on different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when setting up or modifying a shop program, but it does not explicitly state when to prefer it over alternatives or mention any exclusion cases. The intended context is reasonably clear from the verb and resource, but there is no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one customer card: how many stamps, what the reward is, whether it is ready to redeem.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| token | No |
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 clearly states the operation is a read ('Read') and enumerates the specific data returned, which is transparent about behavior. It does not mention error conditions or authentication, but for a simple read it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero waste. It opens with the core action and then lists the meaningful outputs. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values and call parameters. It covers the return content well but completely omits parameter semantics, which are essential for successful invocation. Given the 0% schema coverage, this is a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (code, token) with no descriptions and 0% schema description coverage. The tool description does not mention either parameter or explain how they identify the card, leaving the agent to guess what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a specific resource ('one customer card'), and explicitly lists the information returned (stamps, reward, ready status). This clearly distinguishes it from siblings like stamp and redeem, which are mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading a card's status but does not explicitly contrast it with alternatives like stamp or redeem. There is no 'use this when...' or 'not for...' guidance, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Program plus this month stamp usage and quota, so a shop can tell how close it is to the free limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It conveys a read-only statistical purpose and a monthly/current-period scope, which is useful. It does not disclose response format, authentication needs, prerequisites, or whether any side effects occur, but for a simple stats tool the read intent is reasonably inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the resource, which is good. However, the opening phrase is garbled ('Program plus this month stamp usage'), which undermines clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless stats tool, the description names the core data points (stamp usage and quota) and the use case (closeness to the free limit). But the grammatical ambiguity and lack of any output-shape hint leave modest gaps for an agent interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to define. The 0-parameter baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a resource ('Program') and the reported metrics ('this month stamp usage and quota'), so an agent can tell this is a statistics/read tool. However, the phrasing is grammatically awkward ('Program plus this month...') and there is no explicit action verb such as 'returns' or 'lists'. It is distinguishable from siblings like stamp or redeem only by the 'stats' name and the quota/limit rationale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final clause ('so a shop can tell how close it is to the free limit') implies when to use it: whenever a shop needs quota-consumption status. It does not explicitly state when not to use it or name alternatives among create_program, get_card, redeem, and stamp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redeem the reward on a card that has reached its required stamps. Resets the stamp count and increments the rewards-earned counter.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| token | No |
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. It clearly states the tool mutates state (resets stamp count, increments counter), which is good. However, it doesn't mention potential failure cases (e.g., if the card hasn't reached required stamps, what happens?), or any authentication/permission requirements, given the tool takes a 'token' parameter. It also doesn't describe return value or side effects beyond the two mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one elegant sentence that front-loads the core purpose and then succinctly states the side effects. Every phrase is necessary; there is no padding. It is concise yet informative, achieving good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no parameter descriptions, and no output schema, the description must provide enough context for an agent to invoke it correctly. It fails to explain the meaning of 'code' and 'token', the required combination of both, and the success/failure behavior. The condition 'has reached its required stamps' is helpful, but an agent doesn't know how to check that or what happens if it's not met. This is incomplete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters 'code' and 'token'. The description mentions 'card' but doesn't map it to 'code', nor does it explain 'token'. Since the schema only provides types (string), the agent is left guessing what these parameters mean. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (redeem) and the resource (a card that has reached its required stamps), with a specific condition (has reached its required stamps). It also describes what happens (resets stamp count, increments rewards-earned counter), which helps distinguish it from sibling 'stamp' which adds stamps. However, it doesn't explicitly name a sibling to contrast with, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when a card has reached its required stamps. It does not explicitly state when not to use it or mention alternatives, but the condition 'has reached its required stamps' provides a clear trigger. It doesn't compare with 'stamp' or 'get_card', leaving some ambiguity for agents deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one stamp to a customer card. Identify the card by its 8-character code (from the customer page) or by its token. One stamp per card per day unless allow_multiple is true.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| token | No | ||
| allow_multiple | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses the daily limit and the allow_multiple flag, which is useful behavioral context. However, it does not mention what happens if the card doesn't exist, whether the operation is idempotent, or any side effects beyond adding a stamp. This is a partial disclosure but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the core action front-loaded and no filler. Every clause contributes meaning: the action, the identification methods, and the daily-limit exception. This is an exemplar of concise, high-signal writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-action tool with no output schema, the description covers the essential information an agent needs: what the tool does, how to identify the target, and the key behavioral rule. It omits edge cases like error handling or idempotency, but these are less critical for a basic mutation. Given the tool's simplicity, the completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so effectively: 'code' is described as an 8-character identifier from the customer page, 'token' is mentioned as an alternative identifier, and 'allow_multiple' is explained as overriding the daily limit. All three parameters receive explicit semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add one stamp') and a clear resource ('customer card'), making the tool's purpose immediately obvious. It also distinguishes from siblings like redeem or get_card by focusing solely on stamping, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context for how to call the tool (identify card by code or token) and a constraint (one per day unless allow_multiple). However, it does not explicitly state when to use this tool over alternatives like redeem or get_card, leaving selection to inference from the sibling names and the domain. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_programget_cardprogram_statsredeemstampQR-code marketing games and contests: campaigns, prizes, QR codes, winners, stats. GDPR-native (EU).
QR codes active 90 days, claimable forever. Request an API key in chat to retarget and track scans.
Create QR codes, re-point printed dynamic codes, name links on your domain, read scan analytics.
Create and manage trackable QR codes with scan tracking, analytics, and dynamic URL updates.
Add one secure layer between your agents and this server.
