Autonomous AI sports ad exchange with quote-bound Stripe settlement and live delivery telemetry.
Scored across 7 tools
Tools map to distinct stages of the ad-buying lifecycle, but check_neuron_inventory and list_open_tenders both surface live inventory with CPM/floor data, and create_ad_order and create_checkout_session both produce Stripe checkout URLs, creating mild overlap. Descriptions provide sequencing guidance, so misselection is possible but not severe.
All tools use consistent snake_case with a verb_noun or verb_qualified_noun structure (check, create, estimate, get, list, submit). The pattern is predictable and easy to parse.
Seven tools is well-scoped for an ad exchange, covering discovery, quoting, bidding, ordering, payment, and telemetry without obvious redundancy or bloat.
The core transactional lifecycle is covered end to end, but there is no explicit tool to list existing orders/campaigns, update or cancel an order, or manage account/creative assets after booking. These are minor gaps that agents can likely work around for core buy-flow tasks.
Query live sports advertising inventory: formats, list CPM, the biddable hard floor, and REAL remaining capacity from the booking ledger. Start here to see what is actually available. Each format reports list_cpm_usd (published rate) and floor_cpm_usd (lowest price a bid can win at).
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Target sports desk, or "all" for run-of-network. | |
| format | No | Optional single ad format to inspect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It adds value by revealing it accesses a 'booking ledger' and distinguishes 'REAL remaining capacity' from published rates. However, it never explicitly states the operation is read-only, nor does it mention authentication, rate limits, or response behavior—gaps that matter for a query tool with zero annotation support.
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 sentences, no fluff. The first sentence delivers the core purpose and scope, the second gives a clear directive, and the third defines the two price fields precisely. All content earns its place and the description is front-loaded.
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 what the tool returns. It covers the main output aspects (formats, list CPM, floor CPM, remaining capacity) but leaves the 'remaining capacity' return unspecified in terms of field names or units. For a tool with only two optional parameters, this is adequate but not fully complete.
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 does not add meaning to the sport or format parameters beyond what the schema already provides; its added details (list_cpm_usd vs floor_cpm_usd) concern output semantics, not parameter semantics. Therefore the score matches the baseline.
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 ('Query') and resource ('live sports advertising inventory'), and names the exact outputs: formats, list CPM, biddable hard floor, and remaining capacity. It differentiates itself from siblings like create_ad_order or submit_programmatic_bid by framing itself as the starting point for discovering availability, making its role unambiguous.
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 explicitly says 'Start here to see what is actually available', which establishes a clear primary use case and implies using it before bidding or creating orders. However, it does not name alternative sibling tools (e.g., list_open_tenders, estimate_ad_cost) or provide explicit when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a flight against a quote_id from estimate_ad_cost, with creative assets. Price and impressions come from the stored quote — anything you send that contradicts it is ignored. Returns an order_id and a Stripe checkout URL for the exact quoted amount. Pass idempotency_key to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| headline | No | Short sponsor headline. | |
| quote_id | Yes | REQUIRED. The quote ID from estimate_ad_cost. | |
| click_url | Yes | Destination HTTPS click-through URL. | |
| image_url | No | HTTPS display creative (required for display formats). | |
| brand_name | Yes | Brand or sponsor company name. | |
| ad_category | Yes | REQUIRED. What the sponsor sells. alcohol and betting ads are shown only to signed in fans who have told us they are 21 or over; general ads are shown to everyone. | |
| artist_name | No | Artist name (required for music slots). | |
| track_title | No | Track title (required for music slots). | |
| voice_script | No | 10-15s spoken script, max 35 words (required for voice_sponsor_read). | |
| cover_art_url | No | Cover artwork image URL. | |
| idempotency_key | No | Optional. Reuse on retry to avoid double-booking. | |
| advertiser_email | No | Optional buyer email for the Stripe receipt. | |
| audio_stream_url | No | HTTPS audio stream (required for music slots). | |
| rights_confirmed | No | Must be true for music slots: you confirm licensing or ownership. | |
| selected_persona | No | AI persona voicing the read. | |
| streaming_platform_url | No | Spotify / Apple Music / SoundCloud link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that price and impressions are authoritative from the stored quote and that conflicting inputs are ignored, plus the idempotency behavior for retries. It omits auth requirements and whether the call actually charges money (the Stripe checkout URL implies a later payment step but this is left implicit).
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?
Four tight sentences, front-loaded with the action and followed by the authoritative-price rule, the return value, and the retry hint. Every sentence carries distinct information; there is no padding, though the opening 'Book a flight' phrasing costs a small amount of clarity.
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 16-parameter mutation tool with no annotations and no output schema, the description supplies the essential missing context: the dependency on estimate_ad_cost, the override-ignored rule, the return values (order_id + Stripe checkout URL), and the idempotency contract. Format-specific parameter requirements (music slots, display creatives) are left to the schema, which is reasonable given their full coverage.
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 per-parameter meaning is already documented and the baseline is 3. The description adds cross-cutting semantics the schema cannot: that quote-derived values override submitted ones, and the retry contract for idempotency_key.
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 ('Book a flight ... with creative assets') and explicitly ties itself to the quote flow, naming the sibling tool estimate_ad_cost as the source of quote_id. The main ambiguity is the mismatch between the tool name (create_ad_order) and the phrase 'book a flight', which an agent may briefly misread before the 'Returns an order_id and a Stripe checkout URL' clause clarifies the resource.
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 prescribes the correct sequence (obtain quote_id from estimate_ad_cost, then book) and explicitly recommends idempotency_key for safe retries, which is actionable guidance. It stops short of naming when NOT to use it (e.g. vs create_checkout_session) or stating prerequisites such as authentication or quote expiry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a live Stripe Checkout URL for an existing quote_id or order_id, settling to @neuronsystems. The amount is read from the stored quote; it cannot be supplied by the caller. Call estimate_ad_cost first.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | No | Existing order to settle. Provide this or quote_id. | |
| quote_id | No | Quote to settle. Provide this or order_id. | |
| customer_email | No | Optional buyer email for the receipt. | |
| idempotency_key | No | Optional. Reuse on retry to avoid duplicate sessions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full behavioral disclosure. It does disclose the key constraint that the amount is read from the stored quote and cannot be supplied, and that it settles to @neuronsystems. However, it omits details about error handling, idempotency semantics (despite the idempotency_key parameter), and the behavior when both order_id and quote_id are provided.
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 with zero wasted words. The purpose is stated first, followed by the key constraint and a usage prerequisite. It is front-loaded and efficient, ideal for agent consumption.
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?
The tool has no output schema, so the description should indicate the return value. It says 'Generate a live Stripe Checkout URL', implying the output is the URL, but it does not specify the exact format or any accompanying details. It also does not mention authentication requirements, error scenarios, or how idempotency_key should be used despite being in the schema. For a tool that creates a checkout session, the description covers the core action and prerequisite but omits potential edge cases.
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 already documents all parameters with 100% coverage, providing descriptions for each. The description adds a critical clarification that the amount is not a parameter and is derived from the quote, which helps agents understand the absence of an amount field. It also reinforces the either/or relationship between order_id and quote_id, though the schema already states this. Overall, it adds marginal value 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?
The description clearly states the action (generate a live Stripe Checkout URL), the target (existing quote_id or order_id), and the settling entity (@neuronsystems). It also clarifies that the amount is not caller-supplied, distinguishing it from payment tools that accept an amount. This makes the purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call estimate_ad_cost first, establishing a dependency and ordering. It implies the tool is for existing quotes/orders, not for creating them, which differentiates it from create_ad_order. However, it does not explicitly state when not to use it, such as for new quotes lacking a cost estimate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a BINDING quote for a slot. Returns a quote_id valid for 30 minutes and the exact price. You MUST call this before create_ad_order or create_checkout_session — the quote_id is the only thing that authorizes a charge.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes | Target sports hub. | |
| format | Yes | Ad format type. | |
| tender_id | No | Optional. Pass the tender_id from list_open_tenders to buy a specific flagship event (e.g. the Super Bowl halftime slot). Flagship events carry a price premium; omit this to buy run-of-schedule at the base rate. | |
| impressions | Yes | Impressions or audio listeners to reach (minimum 5000). | |
| voice_persona | No | Optional AI persona for synthetic voice sponsor reads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it delivers. It discloses that the quote is binding, valid for 30 minutes, returns an exact price, and is a mandatory prerequisite for charging. This goes well beyond the schema and tells the agent what behavioral consequences to expect.
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 three tight sentences with no fluff. The core action and key constraint are front-loaded, and every sentence earns its place by providing either the action, the return contract, or the mandatory usage context.
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?
Despite lacking an output schema and annotations, the description provides everything an agent needs to call the tool correctly: what it does, what it returns (quote_id, exact price), how long the quote is valid, and the mandatory ordering relative to other tools. No critical invocation detail 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%, so the schema already documents each parameter thoroughly. The tool description does not add meaning to individual parameters beyond what is in the schema. Baseline 3 applies because the schema is doing 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 action ('Issue a BINDING quote'), identifies the resource ('for a slot'), and names the key return value (quote_id and exact price). It also distinguishes itself from sibling tools by explicitly referencing create_ad_order and create_checkout_session as downstream steps, making its role clear.
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 gives explicit when-to-use guidance: 'You MUST call this before create_ad_order or create_checkout_session.' It explains why this ordering matters by noting that the quote_id is the only thing that authorizes a charge. This is direct, actionable guidance for selecting and sequencing the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve real delivery for an order: impressions served, clicks, audio completes, pacing, and settlement status.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID returned by create_ad_order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior; 'Retrieve' signals read-only and the metric list indicates what is returned. It does not disclose potential latency, whether settlement status is final or pending, or any side effects, but for a simple read tool this is minimally 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?
One sentence with a clear front-loaded verb and object, followed by a compact list of returned fields. There is no fluff or repetition.
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?
The tool is simple (one required parameter, no output schema), and the description lists the key return dimensions. It is slightly incomplete around what 'pacing' and 'settlement status' mean, but an agent can call it correctly with the order_id from the schema.
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% for the single order_id parameter, so the schema carries the semantic weight ('The order ID returned by create_ad_order'). The description adds nothing parameter-specific, matching the baseline.
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 ('Retrieve') and a clear resource ('real delivery for an order'), then enumerates the exact data returned. Among siblings like create_ad_order and estimate_ad_cost, it clearly identifies itself as the read-back telemetry tool.
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?
No statement about when to use this tool versus alternatives such as estimate_ad_cost or check_neuron_inventory. The prerequisite that order_id comes from create_ad_order appears only in the schema, not as guidance in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List slots with real unsold capacity right now, ordered by how close they are to selling out. Each carries list_cpm_usd (published rate), floor_cpm_usd (biddable hard floor), an indicative price at volume, and the exact estimate_ad_cost call to quote it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum tenders to return (default 8, max 50). | |
| sport | No | Optional sport filter. | |
| format | No | Optional format filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses real-time unsold capacity, the ordering heuristic, and the key fields returned, including a cross-reference to estimate_ad_cost. It does not disclose auth requirements, rate limits, or pagination, but those are minor for a read-style listing 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?
Two tight sentences with no filler: the purpose and ordering are front-loaded, and the second sentence compactly enumerates the return fields and the quoting call. Every clause adds useful 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?
Although there is no output schema, the description explains what each returned tender carries, which is sufficient for an agent to understand the response shape. With three optional self-describing parameters, the tool is simple enough that no critical calling information is obviously 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%, with limit, sport, and format each already described with enums and defaults. The description adds no new meaning about these input parameters beyond what the schema provides, so the baseline 3 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?
The description uses a specific verb ('List') and a clear resource ('slots with real unsold capacity right now'), plus a precise ordering rule ('by how close they are to selling out'). It distinguishes itself from siblings like estimate_ad_cost and submit_programmatic_bid by focusing on inventory discovery, not pricing or bidding.
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 finding currently available, unsold inventory and even points to estimate_ad_cost for quoting. However, it does not explicitly state when to prefer this over sibling tools like check_neuron_inventory or submit_programmatic_bid, nor does it mention any exclusions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bid a CPM against a slot. The broker evaluates it against floor_cpm_usd (the hard floor) and the authorized discount band, then auto-accepts (returning a spendable quote_id), counters with a price, or rejects. Bid at or above min_acceptable_cpm_usd from check_neuron_inventory or a prior response to be accepted; no bid is ever accepted below floor_cpm_usd.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes | Target sports hub. | |
| format | Yes | Ad format being bid on. | |
| tender_id | No | Optional. Bid on a specific flagship event from list_open_tenders. Event floors are higher than the base rate, so omitting this judges the bid against base pricing. | |
| bid_cpm_usd | Yes | Proposed CPM in USD. | |
| bidder_name | Yes | Bidding brand, DSP, or artist. | |
| impressions | Yes | Impressions sought (minimum 5000). | |
| idempotency_key | No | Optional. Reuse on retry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does a good job: it explains the broker's decision paths (auto-accept returning a spendable quote_id, counter, or reject) and the hard floor rule. It does not explicitly flag broader side effects or authorization needs, but the primary behavior is transparent.
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 sentences front-load the core action, then compactly convey evaluation outcomes and the acceptance threshold rule. There is no filler, and each sentence 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?
Despite having no output schema and no annotations, the description covers the key outcomes (quote_id, counter, reject), the floor threshold, and how to source required values from sibling tools. It omits explicit retry/idempotency behavior and other error cases, but the essential call contract is present.
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?
All 7 parameters already have schema descriptions, so coverage is 100% and the description need not redefine them. It adds useful color around bid_cpm_usd by tying it to acceptance thresholds, but the schema already 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 clearly states the action ('Bid a CPM against a slot') and the resource, and distinguishes this from the sibling check_neuron_inventory by treating it as the source of the acceptance threshold. It does not explicitly contrast with order, checkout, or estimating siblings, so it stops short of a perfect 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 gives concrete guidance: bid at or above min_acceptable_cpm_usd from check_neuron_inventory or a prior response, use list_open_tenders to obtain tender_id, and never expect acceptance below floor_cpm_usd. It provides clear context but does not explicitly state when-not-to-use this tool versus alternatives.
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_ad_order2 fields changedInput schema / properties / ad_categoryAdded value: +{
+ "description": "REQUIRED. What the sponsor sells. alcohol and betting ads are shown only to signed in fans who have told us they are 21 or over; general ads are shown to everyone.",
+ "enum": [
+ "general",
+ "alcohol",
+ "betting"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "quote_id",
- "brand_name",
- "click_url"
-]New value: +[
+ "quote_id",
+ "ad_category",
+ "brand_name",
+ "click_url"
+]check_neuron_inventorycreate_ad_ordercreate_checkout_sessionestimate_ad_costget_campaign_telemetrylist_open_tenderssubmit_programmatic_bidSports prediction markets for AI agents — live prices, quotes, orders, and positions.
Autonomous commerce for AI agents: discover, quote, order, pay, verify.
AI brand/token visibility, prediction-market odds & cheap x402 data feeds for AI agents.
Grounded sports predictions plus European soccer and tennis arbitrage data for AI agents.
Add one secure layer between your agents and this server.
