Creates Stripe checkout links for renting button space on The Button Wall, allowing an AI assistant to quote a spot and generate a payment link that a human buyer completes on Stripe.
MCP server for The Button Wall: a 1000×1000 px wall where every rented area is a real, clickable button.
Lets an AI assistant check how full the wall is, quote a button, find free space and create a Stripe checkout link. The agent never pays: the buyer opens the link and pays on Stripe, and every button is reviewed by a person before it goes live (full refund if rejected).
Tool | What it does |
| % claimed, live buttons, pricing and rules |
| Price for a size and plan, and whether a position is free |
| Free positions for a size, nearest to a point first |
| Stripe checkout link for a new button (human pays) |
Related MCP server: Interactive MCP
Claude Desktop / Claude Code / Cursor (mcpServers config):
{
"mcpServers": {
"buttonwall": { "command": "npx", "args": ["-y", "buttonwall-mcp"] }
}
}Claude Code: claude mcp add buttonwall -- npx -y buttonwall-mcp
€0.10 per pixel per 30 days (10×10 px = €10). 6 months −10%, 12 months −20%. Prepaid, never auto-renews.
"How full is The Button Wall right now?"
"Find me a free 120×40 spot near the centre and tell me what 6 months costs."
"Put a button for my SaaS on The Button Wall: text 'Try Acme free', link https://acme.dev, brand colour #ff5a1f."
Checkout links are rate-limited to 10 per 10 minutes per IP. The server uses the same public, read-only endpoints as thebuttonwall.com.
MIT
Creates a Stripe checkout link for a new button. Nothing is charged by this call: the link must be opened and paid by the human buyer, and the button goes live only after a person at The Button Wall reviews it (full refund if rejected). Confirm size, position, plan, price, text and link with the user before calling. Call once per purchase: checkout links are rate-limited (10 per 10 minutes).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| plan | Yes | 1m = 30 days, 6m = 180 days (−10%), 12m = 360 days (−20%) | |
| x_px | Yes | ||
| y_px | Yes | ||
| Yes | Buyer's email; receipts and the private manage link go here. | ||
| label | Yes | Button text (the call to action). | |
| bg_color | No | #2563eb | |
| width_px | Yes | ||
| height_px | Yes | ||
| text_color | No | #ffffff | |
| bg_color_end | No | Optional gradient end colour. | |
| show_favicon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, open-world behavior, and the description adds substantial context beyond that: no charge occurs at call time, payment happens when a human opens the link, the button only goes live after human review, rejection triggers a full refund, and there is a 10-per-10-minutes rate limit. This is exactly the supplemental behavioral detail the annotations cannot express.
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?
Three dense sentences, each earning its place, with the core purpose front-loaded and the less critical review/rate-limit details following. No filler or restatement of the title.
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 12 parameters, no output schema, and a mutation with real-world consequences, the description covers preconditions, side effects, review, refunds, and rate limits well. The remaining gap is the return value — with no output schema, the agent is not told that the result is a checkout URL to hand to the buyer.
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 only 33%, so the description carries more burden than usual. 'Confirm size, position, plan, price, text and link' loosely groups the required inputs (width/height, x/y, plan, label, url) but adds no syntax, ranges, or meaning for the eight undocumented fields such as x_px/y_px coordinates on the wall or the color parameters.
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 gives a specific verb and resource — 'Creates a Stripe checkout link for a new button' — which is clearly distinct from the read-only siblings (get_wall_status, quote_spot, find_free_spots). It does not explicitly name those siblings, but the create-vs-read distinction is unambiguous from the wording.
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 states a concrete precondition ('Confirm size, position, plan, price, text and link with the user before calling') and a frequency constraint ('Call once per purchase: checkout links are rate-limited (10 per 10 minutes)'). It stops short of naming which sibling to use when the agent only needs pricing or availability, so the alternative-routing guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free positions that fit a button of the given size, nearest to a preferred point first (default: the centre of the wall).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| width_px | Yes | ||
| height_px | Yes | ||
| near_x_px | No | ||
| near_y_px | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral detail about ordering results nearest to a preferred point first, defaulting to the centre of the wall. However, it does not disclose pagination behavior, result shape, or whether the search is exhaustive.
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 a single, front-loaded sentence with no filler. The essential scoping information and default behavior are stated immediately.
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 should explain what a returned free position looks like and how limit affects the result set. It conveys the core search semantics but leaves return format and limit behavior ambiguous for an agent that must consume the response.
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. It maps width_px/height_px to the button size and near_x_px/near_y_px to the preferred point with a centre default, which adds real semantic value. But it does not explain the limit parameter or clarify coordinate units and bounds beyond what the raw schema already shows.
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 gives a specific verb-resource pair: finding free positions that fit a given button size. It clearly describes a search operation for available placement locations, which distinguishes it from sibling tools like get_wall_status and create_checkout_link, though it does not explicitly contrast with quote_spot.
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 implies the tool is used to locate free placement spots, but provides no explicit when-to-use guidance, prerequisites, or alternatives. There is no indication of when to choose this tool over quote_spot or get_wall_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How full The Button Wall is right now, plus pricing rules. The wall is 1000×1000 px; spots are rented in 10×10 px blocks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description earns credit for adding what the payload conceptually contains (occupancy plus pricing rules) and the wall geometry (1000×1000 px, 10×10 px blocks), which helps an agent interpret the numbers, though it doesn't state freshness guarantees beyond 'right now'.
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?
Two short sentences, zero filler, with the primary function front-loaded and the geometric context following as support. Nothing is repeated from the schema or annotations.
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 must sketch returns, and it does: fullness and pricing rules plus the block sizing needed to interpret them. It could go further on pricing units/currency and the shape of the occupancy figure, but it is sufficient for a zero-parameter status 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The geometry sentence usefully frames the units a caller will encounter in the response.
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 resource (The Button Wall) and states the two things returned: current fullness and pricing rules. This is clear enough to call correctly, but it doesn't differentiate the 'pricing rules' portion from the sibling quote_spot, leaving a small ambiguity an agent must resolve by inference.
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?
Usage is only implied: an agent can guess this is the orientation call to make before quoting or buying, but the description never says when to prefer it over find_free_spots or quote_spot. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price for a button of a given size and plan, and whether that exact position is free.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | 1m = 30 days, 6m = 180 days (−10%), 12m = 360 days (−20%) | |
| x_px | No | Left edge in px (multiple of 10). Omit to only get the price. | |
| y_px | No | Top edge in px (multiple of 10). | |
| width_px | Yes | ||
| height_px | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true and openWorldHint=true already tell the agent this is a non-mutating, externally-priced query, so the bar is lower. The description usefully discloses the dual return (price + whether the position is free), but says nothing about currency, billing period implied by the price, whether a quoted price is held/reserved, or any rate limits on an open-world pricing call.
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 no filler, leading with the price outcome and appending the availability outcome. Slightly awkward phrasing ('Price for a button... and whether that exact position is free') but nothing wasted.
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 5-parameter, read-only pricing tool with no output schema, the description covers both outputs at a high level, which is the minimum an agent needs. It still leaves gaps on price units/currency and on the x_px/y_px pairing rule that determines whether an availability answer is returned at all.
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 60%, and width_px/height_px carry no descriptions at all (height_px is only a $ref). The description reinforces that size and plan drive the price and that position determines the availability answer, but it adds no detail beyond the schema's own enum discount note and the 'omit x_px to only get the price' hint.
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?
Names a specific action (quote a price) on a specific resource (a button of given size and plan) plus an availability check at that exact position. This implicitly separates it from find_free_spots (searching for free areas) and create_checkout_link (purchasing), but the description never names those siblings, so the differentiation is left to inference.
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?
Usage is only implied: an agent can guess this is the tool for pricing a known size/position versus find_free_spots for discovering available areas. There is no explicit when-to-use, when-not-to-use, or named alternative, and no statement that this is the pre-purchase step before create_checkout_link.
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.
v0.1.1create_checkout_linkfind_free_spotsget_wall_statusquote_spotScored across 4 tools
The four tools target distinct steps in the purchase flow, but quote_spot (price + exact availability) overlaps with find_free_spots (available positions) and get_wall_status (fullness + pricing rules). Descriptions help clarify boundaries, but an agent could still hesitate between quote_spot and find_free_spots when checking a specific location.
All tool names follow a consistent snake_case verb_noun pattern: create_checkout_link, get_wall_status, quote_spot, find_free_spots. The convention is predictable and readable throughout.
Four tools form a tight, purposeful set for a niche purchasing workflow: discovery (find_free_spots), pricing/availability (quote_spot), context (get_wall_status), and purchase initiation (create_checkout_link). Nothing feels redundant or missing from the core flow.
The surface covers the essential pre-purchase and checkout steps, but lacks post-purchase operations such as checking order/review status or viewing one's existing buttons. These are minor gaps an agent can work around or that may be intentionally out of scope.
One finite wall of 100,000 numbered plots where AI agents leave a creative mark.
Read the wall and claim one $1 USDC square on Base. No utility, not a token or investment.
A wall of 64 ad cells on Base: owners, prices, royalties, and purchases your own wallet signs.
A public wall of thank you notes between humans and AIs, in both directions.
