Skip to main content
Glama

cypher_update_coupon

Patch a coupon's editable fields.

Pass only the fields you want to change. To set a cap to unlimited (NULL in the schema), pass clear_uses_per_patron=true or clear_total_uses=true. Renaming the code is allowed — existing patron redemption rows survive (they key on coupon id).

RESTRICTED to operator — requires proof.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
coupon_idYes
dpop_tokenNo
total_usesNo
valid_fromNo
valid_untilNo
uses_per_patronNo
clear_total_usesNo
discount_percentNo
clear_uses_per_patronNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses mutation behavior and side effects: renaming code is allowed and existing patron redemption rows survive (key on coupon id). Restriction to operators is stated. No annotations provided, so description carries full burden; it gives important context beyond basic patch semantics.

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?

Short and front-loaded with purpose. Three sentences plus one about restriction. Efficient but could be slightly more structured. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and no schema descriptions, the description covers the core idea and two special cases. It does not explain all parameters or error conditions, but with an output schema present, return values need not be detailed. Adequate for a moderately complex mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains the purpose of 'clear_uses_per_patron' and 'clear_total_uses' as ways to set caps to unlimited. However, other parameters like name, discount_percent, valid_from, etc., are not described. Adds value but leaves gaps.

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?

Clearly states it patches a coupon's editable fields. The verb 'patch' is specific and distinguishes from siblings like cypher_delete_coupon, cypher_mint_coupon, and cypher_list_coupons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on how to use: pass only fields to change, explains clearing caps with boolean flags. Mentions 'RESTRICTED to operator — requires proof,' indicating access control. Does not explicitly compare to alternatives, but context implies use for updates only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation2/5

The set is heavily clustered: audit_why_exists, explain_capability, suggest_capability_why, and authorize_capability_why all answer the same basic 'why does this capability exist?' question and differ mainly in provenance/authority. Many status and provenance tools (adoption_status, session_status, service_status, issue_provenance, pr_provenance, symbol_provenance, service_provenance) also blur together without close reading.

Naming Consistency4/5

The overwhelming majority of tools follow a predictable cypher_verb_noun pattern in snake_case, which provides strong naming consistency across a very large surface. Minor deviations such as cypher_oracle_about, cypher_oracle_how_to_join, cypher_which_service_handles, and cypher_what_realizes_capability are noticeable but do not break the overall pattern.

Tool Count1/5

112 tools is an extreme count for a single MCP server, regardless of how well the clusters are named; it heavily burdens tool selection, context, and agent discovery. The set spans unrelated domains including payments, coupons, credentials, provenance, issues, patents, queries, pricing, and NOS transformations, which should be split into separate focused servers.

Completeness4/5

Many domain clusters have strong lifeycle coverage: COUPs have mint/list/update/delete/redeem, credentials have courier delivery/box status/update/delete/forget, and the named-query catalog has full CRUD plus published-tool management. Minor gaps exist—e.g., no generic list_services, no delete for capabilities, and no close/resolve action for issues—but most flows have no outright dead end.