An MCP server for designing and ordering custom NFC tap discs for organizations, including churches, nonprofits, restaurants, coffee shops, and local businesses. Keyless discovery and pricing; order setup by API key; payment handed off by a hosted invoice link. Tap.Giving (https://tap.giving) makes custom NFC tap discs: a visitor holds a phone against a disc and the organization's page opens, no app to install. Discs work with any platform the organization already uses and include a free Redirect Dashboard to change where a disc points in seconds. One-time hardware, no subscription.
Scored across 12 tools
The tools mostly have distinct roles across a clear lead-to-order journey, and descriptions explicitly route between similar-sounding steps. Some boundaries are still nuanced, especially get_discovery vs get_product, get_order_questions vs get_recap, and start_order_intent vs create_order, but the descriptions make them workable.
All tool names use consistent snake_case with predictable verb_noun structure. Read operations use get_, while lifecycle actions use create_, start_, submit_, request_, and register_.
Twelve tools is well within a reasonable range for a guided ordering and artwork workflow. Each tool appears to earn its place by covering a distinct step in the process.
The surface covers the core journey from discovery and quoting through artwork submission, order creation, invoicing, and status checks. Minor gaps remain around order modification/cancellation, listing orders, and webhook delivery, which is explicitly pending.
Set up an order for the key's organization through the same front door a website order takes (an INVREQ record the hourly adoption resolves into the CRM, indistinguishable downstream). This is the lock-in write behind both recap exits; it carries the recapRef and a required idempotencyKey (a retry with the same key and payload returns the original orderRef; the same key with a different payload is a conflict naming the differing fields). The 100-disc minimum is enforced here. Sizes other than the two built-ins return manual_exception. Returns the orderRef (the reference every later call uses), the exact quote, the chosen exit, and the next step. Failure modes: a recap whose inputs differ from the order is refused as a conflict naming the differing fields; a reused idempotencyKey with a different payload is a conflict naming the original order; a missing or mismatched contact email for the key is refused. Routing: start_order_intent is the earlier keyless contact capture, get_recap must run immediately before this call over the same inputs, and request_invoice follows it. Design approval stays human: a person approves the final proof by email before production. No tool on this server records or implies an approval. Payment stays human: this server moves no money itself. It returns a hosted invoice link and a person pays on Stripe's hosted page.
| Name | Required | Description | Default |
|---|---|---|---|
| exit | No | The person's chosen exit, recorded on the order and the invoice metadata. Both exits write the same record shape. | |
| note | No | Optional free-text note carried on the order for the team. | |
| size | Yes | 100mm-round or 100mm-square; anything else is a manual exception handled by hand through the Tap.Giving team. | |
| shipTo | Yes | The shipping address for the finished discs; every field is required. | |
| mounting | Yes | How the discs mount: adhesive backing, or pre-drilled screw holes plus adhesive. | |
| quantity | Yes | Discs in the order, 100 to 7000. | |
| recapRef | Yes | The reference get_recap returned for these same inputs; the order is refused if its inputs differ from that recap. | |
| artworkRef | No | The artwork reference submit_artwork returned for this order's design. | |
| contactName | Yes | The contact person's name for the order. | |
| contactEmail | Yes | Must belong to the key's organization. | |
| contactPhone | Yes | A phone number that reaches the contact. | |
| antiMetalCount | No | How many discs sit on metal surfaces and need the $1 shielding layer. Omit when unknown. | |
| idempotencyKey | Yes | 8 to 128 characters, minted per intended order, reused on retries. | |
| linkDestination | No | Any http or https URL; optional, changeable anytime; the Redirect Dashboard is the default. | |
| organizationName | No | Organization name; defaults to the key's organization name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the annotations, it explains idempotency semantics (same key+payload returns the original orderRef; same key with different payload is a conflict naming differing fields), the 100-disc minimum enforced here, manual_exception for non-built-in sizes, and the human approval and payment boundaries. It stops short of stating auth requirements or rate limits, so it is not quite maximal.
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?
Front-loaded with purpose, then idempotency, then constraints, then routing and human-boundary notes, so the structure is well ordered. It is dense and a few clauses ('indistinguishable downstream', 'the lock-in write behind both recap exits') add flavor rather than instruction, keeping it just short of a 5.
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 15-parameter, 9-required mutation with no output schema, it covers return values (orderRef, quote, chosen exit, next step), the specific failure modes (recap mismatch, key reuse with different payload, contact email mismatch), and the human approval/payment boundaries. Nothing an agent needs in order to call it correctly is missing.
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 coverage is 100%, so the baseline is 3; the description adds real meaning on top: quantity's 100-disc floor is enforced at this call, size values other than the two built-ins return manual_exception, recapRef inputs must match the recap, and idempotencyKey behavior is spelled out. It does not cover optional params like artworkRef, antiMetalCount, or linkDestination beyond the 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?
States a specific verb and resource (set up an order) and pins down the mechanism ('an INVREQ record the hourly adoption resolves into the CRM'), which distinguishes it from sibling reads like get_order_status or get_quote. It also positions it in the flow relative to start_order_intent, get_recap, and request_invoice.
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 Routing section gives explicit ordering: start_order_intent is the earlier keyless contact capture, get_recap must run immediately before this call over the same inputs, and request_invoice follows. It also states exclusions indirectly by assigning contact capture and invoicing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The production artwork spec for the chosen shape: 106 mm artboard, cut, bleed, and safe-zone geometry as structured millimetre data plus plain guidelines, the format wanted back (vector, SVG preferred), house template examples to react to, and the optional logo ask. The agent builds the artwork with its own tools; this server has no design-generation tool. No key needed. Choose the shape first (the discovery call names it the first choice), then call this for that shape; call get_discovery instead when the person has not chosen yet, and submit_artwork once the artwork file exists. The shape argument selects round or square geometry; chosenExampleRef carries the house example direction the person picked, from the examples this tool returns.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | The disc shape to return geometry for: round or square. Omit it to return both shapes. | |
| chosenExampleRef | No | The house example the person picked: an example id from a previous call, or its pick-list number within the chosen shape. It is carried with the spec as the design direction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new context: no API key is needed and the server has no design-generation tool, so the agent must build the artwork with its own tools. It does not cover response size or any limits, but the key behavioral surprise (no generation capability) 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded with the payload description, then the workflow, then parameter meaning. It is dense and slightly long-winded in places, but nearly every clause carries information an agent needs.
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 describe return values, and it does: geometry data, plain guidelines, expected format, example templates, and the logo ask. Combined with the workflow guidance, an agent has everything needed to call this correctly.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: shape selects round or square geometry, and chosenExampleRef carries the house example direction the person picked from examples this tool returns. That clarifies the provenance and purpose of the reference parameter beyond the schema text.
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 names a specific verb and resource ('The production artwork spec for the chosen shape') and enumerates the payload: 106 mm artboard, cut, bleed, safe-zone geometry as millimetre data, plain guidelines, expected return format, house template examples, and the optional logo ask. This is clearly distinguishable from siblings like get_discovery and submit_artwork.
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?
It gives an explicit sequence: choose the shape first, call get_discovery when the person has not chosen yet, and submit_artwork once the artwork file exists. Both the when-to-use and the alternatives are named with their triggering conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. One call orients a cold agent: the builder's introduction (NFC Tap Builder by Tap.Giving), the product in plain words, the first choice (shape: round or square), the pricing tiers, the artwork spec summary, and the full capability list with the human gates. No key, no email, nothing asked. Call this first when an agent is new to the server; call get_product for product facts alone, get_artwork_spec when a shape is chosen and artwork comes next, and get_order_questions only with a key in hand. The optional intent argument is echoed back as guidance with a quantity headline when it names a disc count. Payment stays human: this server moves no money itself. It returns a hosted invoice link and a person pays on Stripe's hosted page.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Optional free-text description of what the person wants (for example an organization type and a rough disc count). It is echoed back as guidance, and a disc count in it produces a price headline for that quantity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world, so the description's added value is the access profile ('No key, no email, nothing asked') and the human-gate framing ('Payment stays human'). The closing two sentences about a hosted invoice link are ambiguous in subject — it is unclear whether get_discovery itself returns that link or whether this describes the server's order flow — which slightly blurs rather than sharpens behavior.
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?
Front-loaded with the imperative 'Start here' and then a tight inventory of what one call returns; the alternative-routing sentence is dense but purposeful. The final two sentences about payment and hosted invoices are tangential to a read-only discovery tool and dilute the otherwise sharp focus.
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 carries the return-value burden and does so by listing the exact contents of the orientation payload. Combined with the auth profile, the sibling routing, and the intent-parameter behavior, nothing an agent needs to call this correctly is missing.
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 coverage is 100% and the single optional intent parameter is already documented, so the baseline is 3. The description adds real meaning beyond the schema by explaining the echo-back behavior and the conditional side effect ('a quantity headline when it names a disc count'), which tells the agent why passing intent is worthwhile.
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 and resource ('Start here. One call orients a cold agent') and explicitly enumerates the payload: introduction, product blurb, shape choice, pricing tiers, artwork spec summary, and capability list. It also names the siblings it is not (get_product, get_artwork_spec, get_order_questions), so an agent can separate the onboarding entry point from the focused lookups without opening a schema.
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?
Explicit routing: 'Call this first when an agent is new to the server', with each alternative paired to its condition ('get_product for product facts alone', 'get_artwork_spec when a shape is chosen and artwork comes next', 'get_order_questions only with a key in hand'). Both the when-to-use and the when-to-use-instead cases are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The order questions as structured data, returned in the exact order to ask them. The questions cover every field create_order requires: shape, quantity, metal count, and mounting with the picture assets. Then the link destination. Then contact name, email, and phone. The shipping address comes last. The result also returns the key's own organization block: the organization name and the contact email orders must use. The journey captures the contact email before this step, through start_order_intent. Key required. Call this once a key exists and the person is ready to order; for a first orientation without a key, call get_discovery.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, closed-world read, so the safety profile is covered. The description adds real behavioral value beyond that: the exact content and ordering of the returned questions, the fact that the organization block (name and mandated contact email) is included, and that a key is a prerequisite for the call. It stops short of describing the structured-data shape or size of the payload.
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 purpose is front-loaded in the first sentence, and the subsequent short sentences convey ordering information that genuinely matters to the caller. The staccato fragments ('Then the link destination. Then contact name, email, and phone.') are slightly choppy but each carries the sequence, not filler.
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, read-only tool with no output schema, the description covers what is returned, in what order, what ancillary data comes with it, the prerequisite key, and the alternative tool. Nothing an agent needs to select and invoke it correctly is missing.
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?
With zero schema parameters the baseline is 4, and the description adds a hidden requirement the empty schema cannot express: a key must exist before this call. That is meaningful input-side context beyond the structured fields.
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 concrete resource — the ordered list of questions required to place an order — and enumerates what those questions cover (shape, quantity, metal count, mounting with picture assets, link destination, contact fields, shipping address). It also distinguishes itself from get_discovery by naming that sibling and its different purpose. The fetch verb is only implied rather than stated outright, which keeps it just short of 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?
It gives explicit preconditions ('Key required', 'Call this once a key exists and the person is ready to order') and names the alternative for the opposite case ('for a first orientation without a key, call get_discovery'). It also notes the contact email is captured earlier via start_order_intent, clarifying sequencing relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where an order stands, from the records fulfillment reads: the CRM stage, the fulfillment state with tracking when present, and the invoice state with its hosted link. An order not yet adopted returns stage "received" with the adoption expectation, not an error. Key required; only the key's own organization's orders. Give exactly one identifier: orderRef (the reference create_order returned; the usual key for an order) or invoiceId (the Stripe invoice id request_invoice returned; use it when the invoice is what you hold). Call this to check an existing order; it never changes anything. Use get_recap before an order exists, get_order_questions to gather an order's inputs, and request_invoice to mint or fetch the payment link.
| Name | Required | Description | Default |
|---|---|---|---|
| orderRef | No | The order reference create_order returned (begins with mcp:). The usual identifier; give this or invoiceId, not both. | |
| invoiceId | No | The Stripe invoice id request_invoice returned. Use it when the invoice is the identifier you hold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real context: the 'received' stage for not-yet-adopted orders instead of an error, and the organization-scoping/auth requirement ('only the key's own organization's orders', 'Key required'). The 'it never changes anything' clause duplicates the annotations rather than extending them, which is the only wasted behavioral sentence.
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?
It is front-loaded with what the tool returns, then the edge case, then the identifier rule, then alternatives – a sensible order with no filler sentences. The parenthetical phrasing ('the usual key for an order', 'use it when the invoice is what you hold') is dense and helpful, though the paragraph is longer than strictly necessary.
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 no output schema, the description enumerates the returned fields, covers the notable non-error edge case, states the auth/org scoping, and specifies identifier selection and mutual exclusion. Nothing an agent needs to call this correctly appears to be missing.
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 coverage is 100% and both parameter descriptions already explain provenance (create_order, request_invoice) and the 'not both' rule, so the schema does most of the work. The description's contribution is the explicit 'give exactly one identifier' constraint and the rule for choosing invoiceId when the invoice is what you hold, which is a modest but genuine addition on top of a complete schema. Baseline 3 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 opening sentence names the verb (retrieve where an order stands) and enumerates the concrete payload: CRM stage, fulfillment state with tracking, invoice state with hosted link. It is clearly a read/status lookup, distinguishable from create_order, request_invoice, and get_order_questions without opening a schema.
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?
Explicitly states when to call it (to check an existing order) and routes three alternatives by condition: get_recap before an order exists, get_order_questions to gather inputs, request_invoice to mint or fetch a payment link. It also tells the agent which of two identifiers to prefer and why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full product facts, with no key needed. Returns one block per topic: discs (the locked tap chip, 0.85 mm double-laminated matte waterproof PVC, the 100 mm (4 inch) round and square built-ins; every other size is a manual exception), mounting (options and the metal caveat), stands and badges (table stands and lanyard badges, priced for information), and shipping (free; 2 to 3 weeks from artwork approval), plus the free Redirect Dashboard. Pass the optional topic argument to return only one block. Call this for product facts alone; for a first orientation call get_discovery, and for the price at a quantity call get_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: return only this one product block (discs, stands, badges, mounting, or shipping). Omit it to return every block. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: no key is required, the response is structured as one block per topic, and there are caveats (non-standard disc sizes are manual exceptions, stands/badges are 'priced for information'). It stops short of describing pagination or response size, but for a static fact lookup that is minor.
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?
Purpose and content scope are front-loaded, then the argument, then the alternative routing — a sensible order with no filler sentences. The long parenthetical spec details (lamination, 0.85 mm, 100 mm sizes) are dense but serve the purpose of telling the agent what facts live in each block, though the list is heavier than strictly necessary.
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?
With no output schema, the description carries the burden of describing return content, and it does so block by block, plus auth ('no key needed') and filtering behavior. For a one-optional-parameter read tool, nothing an agent needs to call it correctly is missing.
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 100% and the enum already documents all five topic values with an 'omit to return every block' note. The description's 'Pass the optional topic argument to return only one block' largely restates the schema, adding no syntax or edge-case detail beyond it, so the baseline 3 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 uses a specific verb and resource ('the full product facts') and then enumerates exactly which blocks are returned: discs, mounting, stands, badges, shipping. It explicitly names the two sibling tools it is not (get_discovery, get_quote), so an agent can route correctly without inspecting schemas.
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?
It gives an explicit routing rule: use this for product facts alone, use get_discovery for first orientation, and use get_quote for the price at a quantity. It also states when to pass the topic argument versus omitting it, leaving no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The binding quote for a prospective order (also known as get_pricing): quantity, tier, list totals as the headline, the first-order 10 percent discount (code WELCOME10, 7-day renewing window) shown as a conditional line, add-ons, free shipping as its own line, and the exact grand total. No tax line: Tax, where it applies, is calculated on the invoice. Quantities below the 100-disc minimum are refused by this tool itself. No key needed. Call this when the person names a quantity and wants the exact price; for product facts without a quantity, call get_product instead. The next step after a quote is get_artwork_spec for the artwork, then start_order_intent.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | Yes | Discs wanted. Minimum 100, maximum 7000. | |
| antiMetalCount | No | How many discs go on metal surfaces and need the $1 shielding layer. Omit when unknown (unknown bills nothing). Counts above the quantity are clamped and the clamp is reported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, it discloses that no key is needed, that the 10% WELCOME10 discount is conditional with a 7-day renewing window, that free shipping appears as its own line, that no tax line is returned (tax is invoiced), and that sub-100 quantities are refused by the tool itself. These are exactly the behaviors an agent cannot infer from the annotations.
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 content is front-loaded with the output shape, then constraints, then routing, and nearly every clause carries information. The single long run-on sentence packs multiple distinct facts together, which slightly hurts scannability but wastes little.
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?
With no output schema, the description carries the full burden of explaining the return structure — tier, list totals, discount line, add-ons, shipping, grand total, and the deliberate absence of tax. Combined with auth and sequencing notes, nothing needed to call this tool correctly is missing.
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 coverage is 100%, so quantity (min 100, max 7000) and antiMetalCount are already fully documented. The description reinforces the 100-disc minimum and mentions add-ons in the output, but adds no meaning to antiMetalCount beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.
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 and resource ('the binding quote for a prospective order'), names its alias get_pricing, and enumerates the exact contents of the quote. It explicitly distinguishes itself from get_product, so an agent can pick the right tool without opening either schema.
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?
It gives the trigger condition ('when the person names a quantity and wants the exact price'), the exclusion with an alternative ('for product facts without a quantity, call get_product instead'), and the downstream sequence (get_artwork_spec, then start_order_intent). This is close to ideal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full recap, the last thing before the exits: it validates the same order inputs create_order will carry (quantity from 100 to 7000, one of the two built-in sizes, adhesive or screws mounting, a complete shipping address) and returns the submitted artwork (displayUrl plus image content where renderable), the quantity, the shipping address as entered, the exact cost from get_quote, and both required notes. Returns a recapRef; create_order carries it, and an order whose inputs differ from the recap is refused as a conflict. Key required.
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | The built-in size and shape: 100mm-round or 100mm-square. | |
| shipTo | Yes | The shipping address for the finished discs; every field is required, and the phone is its own field. | |
| mounting | Yes | How the discs mount: adhesive backing, or pre-drilled screw holes plus adhesive. | |
| quantity | Yes | Discs in the order, 100 to 7000; priced from the published tiers. | |
| artworkRef | No | Optional: the artwork reference submit_artwork returned, shown on the disc in the recap. | |
| contactName | No | Optional display only: the contact person's name, echoed in the recap. | |
| contactEmail | No | The order contact email; it must be the key organization's contact email, and the final proof is emailed there. | |
| contactPhone | No | Optional display only: the contact phone, echoed in the recap. | |
| antiMetalCount | No | How many discs sit on metal surfaces and need the $1 shielding layer. Omit when unknown; an unknown count bills nothing. | |
| linkDestination | No | Optional: the page a tap opens. Any http or https URL, changeable anytime; the Redirect Dashboard is the default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds real context on top: the validation rules mirrored from create_order, the contents of the response, the recapRef handoff, and the conflict-on-mismatch consequence. It doesn't say whether generating a recap has side effects on stored state, but the safety profile is well covered.
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 content is dense and mostly earns its place, but it is delivered as one long run-on with a metaphorical opener ('the last thing before the exits') and a cryptic trailing fragment ('Key required'). Front-loading the core function ahead of the validation inventory would make it easier to scan.
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 10-parameter tool with a nested address object and no output schema, the description explains what comes back and how the result feeds create_order, while annotations cover safety. Remaining gaps are the unclear 'required notes' and the unexplained 'Key required' note.
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 100%, so the baseline is 3. The description restates the quantity range, size choices, mounting options, and complete-address requirement that the schema already documents, and it adds only a little (the recapRef round-trip). The phrase 'both required notes' is ambiguous about which of contactEmail/contactName/contactPhone is actually mandated.
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 names a concrete operation: it validates the exact order inputs that create_order will carry and returns a recap (artwork, quantity, address, cost, notes, recapRef). The relationship to create_order and get_quote is spelled out, so an agent can distinguish it from every sibling without opening a schema.
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?
It clearly positions the tool as the final step before the exits and states that create_order carries the returned recapRef, with a conflict refusal if inputs diverge — that pins down sequencing and prerequisites. It stops short of an explicit 'call this before create_order instead of X' instruction, so a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register (or replace) the organization's one webhook subscription for proof_ready and shipped events. The subscription secret is shown once, here. Registration is live in v1; delivery is pending and lands in v1.1, so until then get_order_status is the state read. Nothing about registration implies live push. Key required.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| callbackUrl | Yes | The https URL deliveries will POST to. It must be publicly reachable (no localhost or private addresses) and answer with a 2xx status; verify deliveries with the subscription secret shown once in the result (deliveries are signed with it). Failed deliveries are retried with backoff. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by disclosing that the secret is returned once and only here, that registration is a replace of the single existing subscription, and that registration does not imply live delivery in v1. This also explains why idempotentHint=false is correct (a fresh secret per call), so there is no annotation conflict.
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?
Front-loaded with the core action and constraint, and the v1/v1.1 caveat appears before alternative routing. Slight redundancy between "delivery is pending" and "Nothing about registration implies live push" is deliberate disambiguation, but it is still restated twice.
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?
With a mutation tool, no output schema, and auth context provided ("Key required"), the definition covers the critical unknowns: secret-once return, replace semantics, and non-live delivery. It stops short of describing the response payload shape or what happens to the previous secret on replace, which would fully close the loop.
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?
At 50% schema coverage, callbackUrl already carries a detailed schema description (https, public, 2xx, signed deliveries, retries) and events carries its enum inline. The description names the event types but adds no format or validation detail beyond the schema, so baseline-level credit is appropriate.
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?
Specific verb+resource: "Register (or replace) the organization's one webhook subscription for proof_ready and shipped events." It also states the cardinality constraint (one subscription per org), which no sibling shares, so an agent can distinguish it from create_order/start_order_intent style tools immediately.
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?
Explicitly routes the agent away from expecting push behavior and names the alternative read path: "delivery is pending and lands in v1.1, so until then get_order_status is the state read." That is an explicit use-this-instead instruction tied to a named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the payment handoff for an order this key's organization created: call create_order first, because this tool needs that call's orderRef (the mcp: reference in its result). It returns a real, finalized Stripe hosted invoice and its link, minted under the invoice playbook (send_invoice collection, 7 days to due, first-order coupon when eligible, the free shipping line, finalized with auto_advance=false so Stripe emails nothing). If the customer already has an open or draft invoice, that invoice's link is returned flagged existing. Both test-mode and live-mode keys mint here; the minted invoice shape passed the field-for-field parity check against Stripe test mode on 2026-11-07. This server moves no money itself: it returns a hosted invoice link for a person to pay.
| Name | Required | Description | Default |
|---|---|---|---|
| orderRef | Yes | The order reference create_order returned (it begins with mcp:); the invoice is minted for that order. | |
| idempotencyKey | Yes | Per invoice request; retries return the same invoice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the write/idempotent/non-destructive profile; the description goes well beyond with the invoice playbook (send_invoice collection, 7-day due, coupon eligibility, free shipping line, auto_advance=false so Stripe sends no email). It also discloses test-vs-live key behavior, the existing-invoice case, and that no money moves — exactly the side-effect detail an agent needs before invoking a write 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 prerequisite is front-loaded in the first sentence where an agent will see it, and the parenthetical playbook details are compact. The middle sentence is overloaded with parenthetical clauses, but every clause carries operational information rather than filler.
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, and the description compensates by stating what comes back — a finalized Stripe hosted invoice link, flagged 'existing' when one already exists — plus the no-email and no-money-movement guarantees. For a two-parameter write tool, nothing an agent needs to call and interpret it is missing.
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 coverage is 100%, so baseline is 3, but the description adds real meaning by making orderRef's provenance a hard requirement ('call create_order first') rather than just a format note. The idempotencyKey retry semantics are left entirely to the 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 opening clause gives a specific verb and resource ('Return the payment handoff for an order') and immediately scopes it to orders 'this key's organization created.' It also names the sibling dependency (create_order) and the required input, so an agent can distinguish it from create_order, get_quote, and get_recap without opening any schema.
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?
Explicit ordering guidance is given: 'call create_order first, because this tool needs that call's orderRef.' It also states the behavior when an order already has an open or draft invoice (link returned flagged existing). It lacks an explicit when-not-to-use statement or a named alternative for that case, which keeps it off a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The kickoff and the journey's first ask: capture a contact email through the same public capture endpoint the website's email-first door uses, so follow-up rides the existing lead machinery. No key needed. An intent is a lead, not an order: it creates no invoice and reserves nothing. Returns an intentRef, links an artworkRef when given, and says plainly what follow-up to expect. Completing an order needs an organization API key (issued by the Tap.Giving team; get_discovery says how to ask). Call this once per contact: a repeat call with the same email creates a second lead record rather than updating the first. This call captures the contact only; create_order is the later, keyed call that sets up the order itself.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The contact email to capture; follow-up goes to this address. | ||
| artworkRef | No | Optional: link an earlier submit_artwork reference to this intent. | |
| sourceNote | No | Optional free-text note about where this contact came from or what they asked about; it travels with the lead for the team. | |
| quantityHint | No | Optional rough disc count the person mentioned; it shapes the follow-up and is not a binding quote. | |
| organizationName | No | Optional organization name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read, non-idempotent, non-destructive behavior, and the description adds substantive context beyond them: repeat calls with the same email create a second lead rather than updating (concretely explaining the non-idempotency), no invoice is created and nothing is reserved, and the return includes an intentRef plus a stated follow-up expectation.
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?
Front-loaded with the core action and the key distinctions (lead vs order, keyless vs keyed) packed efficiently. Minor flourishes like 'the journey's first ask' cost a little, but every sentence carries actionable information.
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?
No output schema exists, yet the description covers the return (intentRef, optional artworkRef linkage, follow-up expectation), auth requirements, and duplicate-call behavior. For a five-parameter write tool this is as complete as an agent needs to call it correctly.
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 100%, so the schema already documents all five parameters including artworkRef linking and optional hints. The description adds only the framing that the email drives follow-up routing and that linking an artworkRef ties an earlier submission to the lead, which is marginal beyond the schema; baseline 3 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?
States a concrete verb and resource: capture a contact email as a lead/intent through the public capture endpoint. It explicitly contrasts the intent with an order ('an intent is a lead, not an order') and names create_order as the separate keyed path, so an agent can distinguish it from siblings without opening the schema.
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?
Gives explicit when-to-use (kickoff of the journey, once per contact) and when-not (completing an order requires create_order with an API key), plus the 'no key needed' precondition. It even directs the agent to get_discovery for how to obtain the key, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the finished artwork back. Intake is permissive by ruling: a real image is accepted in any format and rejected only on three sanity grounds (malicious or masquerading content, over 5 MB decoded, or not decodable as the type it claims). Production fitness is judged later in the normal proof flow, never here. No key and no email are needed on the cold path; a keyed submission binds to the key's organization. The file argument carries the artwork file (filename, mediaType, contentBase64); sha256 is the hex SHA-256 of those file bytes; shape optionally names the shape the artwork was designed for; orderRef optionally attaches the submission to an existing order; logo optionally carries the source logo the artwork was built from; note is free text for the team. Each call creates a separate submission: resubmitting the same file mints a new artworkRef rather than replacing the earlier one. Returns the artworkRef every later step carries, a displayUrl, and a preview of the person's own design composited on the disc (cut shape applied). Design approval stays human: a person approves the final proof by email before production. No tool on this server records or implies an approval.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | The artwork file itself: its filename, its media type, and its bytes as base64. | |
| logo | No | Optional source logo the artwork was built from; travels with the submission as source material. | |
| note | No | Optional free-text note for the Tap.Giving team, carried with the submission. | |
| shape | No | Optional: the shape the artwork was designed for; the on-disc preview uses its cut. Omit it and the preview shows both shapes. | |
| sha256 | Yes | Hex SHA-256 of the file bytes. | |
| orderRef | No | Optional: attach the submission to an order this key's organization already created (the orderRef create_order returned). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it enumerates the exact acceptance policy and the three rejection grounds, states a concrete 5 MB decoded size limit, and explains what gets created ('resubmitting the same file mints a new artworkRef rather than replacing the earlier one') — which independently corroborates idempotentHint=false. It also discloses the return payload (artworkRef, displayUrl, disc preview) and the human-approval boundary, so an agent understands side effects and follow-up obligations.
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?
Purpose and intake policy are front-loaded, then parameters, then return/approval behavior — a sensible order for a six-parameter write tool. It is dense but mostly earns its length; the approval sentence is slightly doubled ('Design approval stays human ... No tool ... records or implies an approval'), which is defensible as a guardrail but is the one 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?
For a six-parameter, nested-object write tool with no output schema, the description supplies what is otherwise missing: the return values, the non-idempotent creation behavior, the size/validity gate, and the fact that approval is out of band. Nothing an agent needs to call this correctly or interpret the result is absent.
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 coverage is 100% and nested objects are fully described, so the schema already carries the parameter semantics. The description restates most of it (file contents, sha256 as hex digest of those bytes, shape, orderRef, logo, note) with only marginal added meaning, such as noting that omitting shape makes the preview show both shapes — which the schema also says. Baseline 3 is correct.
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?
States a specific verb and resource ('Send the finished artwork back') and immediately delimits scope: intake only, not production fitness, not approval. That scope framing distinguishes it cleanly from siblings like create_order and get_artwork_spec without the reader opening any schema.
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?
Gives explicit context for the two access paths ('No key and no email are needed on the cold path; a keyed submission binds to the key's organization') and clear exclusions ('Production fitness is judged later ... never here', 'No tool on this server records or implies an approval'). It also routes one parameter to a sibling ('the orderRef create_order returned'). It stops short of naming an outright alternative tool to use instead, so 4 rather than 5.
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_orderget_artwork_specget_discoveryget_order_questionsget_order_statusget_productget_quoteget_recapregister_webhookrequest_invoicestart_order_intentsubmit_artworkPublic, read-only MCP server for FarmNeural company facts, packages, and capabilities.
MCP server for Lemon Squeezy — stores, products, orders, subscriptions, license keys.
The official Planning Center MCP server for interacting with your ministry's data.
Tenzro Network MCP server: wallet, identity, payments, inference, staking, bridges, verification.
Add one secure layer between your agents and this server.
