Connect your AI assistant to IBO's MCP server and commission cinematic campaign films conversationally. Payment always stays human-approved.
Scored across 8 tools
Each tool serves a distinct purpose: checkout, upload, order verification, brief submission, inquiry, and status checks. Even the two 'submit' tools are clearly separated by payment state (submit_brief for paid, submit_custom_inquiry for unpaid). No ambiguity between tool actions.
All tool names follow a consistent verb_noun pattern with snake_case: create_checkout, create_upload_url, get_inquiry_status, get_order, get_project_status, list_offers, submit_brief, submit_custom_inquiry. Naming is predictable and descriptive.
8 tools cover the full lifecycle of the service: discovery, ordering, payment, upload, brief submission, and status tracking. No redundant tools; each has a unique role. Well-scoped for the server's purpose.
The surface covers core workflows: offers, checkout, payment verification, upload, brief submission, and status. Minor gaps exist like no explicit cancel or update operations, but the provided flow covers the expected journey without dead ends for typical use.
Create a Stripe Checkout for a package's 50% deposit. Returns checkout_url, stripe_session_id, and amount_due. Show the amount to your user and open checkout_url for THEM to approve and pay; agents never complete payment themselves. Prices are fixed server-side. Pass a stable client_request_id so retries do not create duplicate checkouts.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | Offer id from list_offers | |
| client_request_id | Yes | Stable id you generate; makes creation idempotent on retry |
| Name | Required | Description |
|---|---|---|
| note | No | |
| currency | No | |
| offer_id | No | |
| amount_due | No | |
| checkout_url | No | |
| stripe_session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, idempotent=true), the description discloses critical behavioral traits: the checkout_url is for the user to pay, not the agent; prices are fixed server-side (no client-controlled amount); and the idempotency mechanism via client_request_id. This prevents misuse and matches 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 description is three sentences, front-loaded with purpose, and every sentence contributes essential information: the deposit amount, the return fields, user payment flow, and idempotency guidance. 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?
Given the payment complexity and presence of an output schema, the description is complete: it covers the main flow, user involvement, idempotency, and agent constraints. It enables correct invocation without needing additional contextual information.
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 descriptions for both parameters (package enum from list_offers, client_request_id for idempotency). The description reinforces the client_request_id purpose but adds no new semantic detail beyond the schema. 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 clearly states 'Create a Stripe Checkout for a package's 50% deposit' – a specific verb, resource, and scope. It is distinct from sibling tools like list_offers or create_upload_url, so the agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: show the amount to the user, open checkout_url for the user to approve and pay, and agents never complete payment. It also advises passing a stable client_request_id to avoid duplicate checkouts. However, it does not explicitly state when not to use this tool versus alternatives (e.g., full payment flow), but the '50% deposit' implies scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a short-lived presigned URL to upload one brand-asset file to IBO's private storage. Requires order_token from get_order; the storage location is bound to the order server-side. PUT the raw file bytes to url, then reference key in submit_brief files[]. Allowed: jpg png webp pdf svg mp4 mov zip ai psd; 250MB/file, 1GB per order.
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | File size in bytes | |
| filename | Yes | ||
| order_token | Yes | From get_order |
| Name | Required | Description |
|---|---|---|
| key | No | |
| url | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, non-idempotent. Description adds key behaviors: short-lived, bound to order, PUT method, allowed types/sizes, 1GB per order. No contradictions.
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 sentences, front-loaded with purpose and prerequisite, second sentence covers all needed steps and constraints. No extraneous 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?
Covers purpose, prerequisites, steps, constraints, and integration with sibling tool. With output schema present, no need to detail return format. Provides all necessary context for correct invocation.
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 67% but description compensates: explains how filename and size are used, adds file type and size constraints. The POST-upload integration with submit_brief clarifies the key output.
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?
Clearly states the tool gets a short-lived presigned URL to upload one brand-asset file. Verb 'Get' and resource 'presigned URL' are specific. Distinguishes from sibling tools like create_checkout or submit_brief by focusing on upload.
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 prerequisite (order_token from get_order), steps (PUT file then reference key in submit_brief), and constraints (file types, sizes, per-order limit). Provides clear context for when to use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a custom inquiry stands: awaiting_confirmation (customer hasn't clicked the emailed link yet) or confirmed with the studio stage (new, replied, proposal_sent, won, closed). PII-free; pass the inquiry_id returned by submit_custom_inquiry.
| Name | Required | Description | Default |
|---|---|---|---|
| inquiry_id | Yes | From submit_custom_inquiry |
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| stage | No | |
| status | No | |
| updated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a non-modifying, open-world tool. The description adds behavioral details by enumerating the exact status values and their meanings (e.g., awaiting_confirmation, confirmed with stage). It also clarifies PII-free behavior and the required source of the inquiry_id. Nothing contradicts 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 description is two sentences: the first covers purpose and allowed statuses, the second adds safety and input guidance. Every word is necessary; there is no fluff or repetition. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema, the description covers status meanings, input origin, and safety. It does not mention error cases (e.g., invalid inquiry_id) but given the openWorldHint and output schema, this is acceptable. Almost 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?
With only one parameter and 100% schema description coverage, the schema already notes the parameter comes from submit_custom_inquiry. The tool description reinforces this and adds context about the origin, which is helpful. Since the schema description is minimal ('From submit_custom_inquiry'), the description's extra clarification adds value.
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 tool checks the status of a custom production inquiry. It lists specific status values and explains their meanings, tying the tool directly to the sibling tool submit_custom_inquiry. This distinguishes it from other tools like get_project_status or create_checkout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after submitting a custom inquiry via submit_custom_inquiry, making the context clear. However, it does not explicitly state when NOT to use it or mention alternative tools, such as get_project_status for project-level checks. The reference to submit_custom_inquiry provides good contextual linking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify payment after checkout and receive an order-scoped access token. Returns paid, package, deposit, and order_token: use order_token for create_upload_url and submit_brief. Payment status can only be established here, never assumed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Stripe checkout session id (cs_...) |
| Name | Required | Description |
|---|---|---|
| paid | No | |
| total | No | |
| deposit | No | |
| package | No | |
| expires_at | No | |
| order_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds value by detailing returned fields and emphasizing that payment status is authoritative only here. No contradictions.
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 sentences plus a list of return fields, front-loaded with primary purpose. Every sentence adds value, no 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?
With output schema present, description covers when to use, what it returns, and how the output is used in sibling tools. Complete for a single-parameter read operation.
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 session_id fully described in schema. Description does not add new information about the parameter beyond what schema already provides.
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 tool verifies payment and returns an order token, with specific return fields. It distinguishes from siblings by specifying subsequent use of the token with create_upload_url and submit_brief.
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 that payment status can only be established here, indicating when to use. Implicitly suggests using before other order-related tools. No explicit when-not but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a paid order is in production. Returns the studio stage (new, brief_received, in_production, review, delivered) plus paid/package/deposit. PII-free; pass the stripe_session_id from create_checkout/get_order.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Stripe checkout session id (cs_...) |
| Name | Required | Description |
|---|---|---|
| paid | No | |
| stage | No | |
| total | No | |
| deposit | No | |
| package | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true, so the read-only nature is already known. The description adds 'PII-free' as a behavioral trait, but does not disclose other aspects like rate limits or side effects.
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 concise sentences. The first sentence states the purpose and return values, the second gives a usage hint. No unnecessary words, highly efficient.
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 that an output schema exists (not shown but indicated), the description does not need to detail return values. It lists the possible stages and provides the source of the parameter, making it fairly complete for a read-only 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 input schema describes session_id as a Stripe checkout session id. The description adds value by specifying its source (from create_checkout/get_order), providing context 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 tool checks the production status of a paid order, lists the specific stages returned (new, brief_received, in_production, review, delivered), and distinguishes itself from siblings like get_order and get_inquiry_status.
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 advises passing the stripe_session_id from create_checkout/get_order, which implies when to use it, but does not explicitly state when not to use it or compare with all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IBO's production packages: stable ids, prices, 50% deposits, deliverables, review rounds, and the scope/refund policy. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | No | |
| offers | No | |
| studio | No | |
| currency | No | |
| policies | No | |
| how_to_order | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and closed world. The description adds behavioral context by enumerating what the packages contain (stable ids, prices, 50% deposits, deliverables, review rounds, scope/refund policy), and implies id stability. No contradiction.
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 very concise sentences. The first lists key content, the second gives usage direction. No wasted words.
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 list tool with an output schema, the description is sufficiently complete. It tells the agent what to expect and when to call it.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameters; it focuses on what is returned.
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 tool lists IBO production packages with specific details (prices, deposits, deliverables). The verb 'list' is implied by 'Call this first' and the title, and it is distinct from sibling tools like create_checkout or get_order.
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?
Provides explicit guidance to 'Call this first,' establishing this as the entry point before other actions. Does not explicitly mention alternatives, but the 'first' instruction gives clear sequential context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the creative brief for a PAID order: pass order_token (from get_order; session ids are not accepted here) plus project fields (product, goal, audience, channels, resolution, launch, links, constraints) and files[] from create_upload_url. Delivery resolution must be selected before creative kickoff. Customer identity comes from the verified payment. NOTE: unpaid/anonymous submissions are rejected here; for Custom Production inquiries without payment use the submit_custom_inquiry tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| name | No | ||
| No | |||
| files | No | ||
| links | No | ||
| launch | No | ||
| company | No | ||
| package | No | ||
| product | No | ||
| audience | No | ||
| channels | No | ||
| resolution | No | Final master resolution selected before creative kickoff | |
| constraints | No | ||
| order_token | No | From get_order |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral context beyond the annotations: payment-derived identity, resolution timing requirement, rejection of unpaid/anonymous submissions, and the source of files and order_token. Annotations are limited to generic hints, so this extra context is valuable.
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 sentences with information front-loaded: purpose first, then prerequisites, constraints, and alternative tool. Each sentence adds necessary context, though slightly longer than ideal.
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?
Covers the main flow, prerequisites, and alternatives, but the schema indicates zero required parameters while the description implies all listed fields (order_token, project fields, files) are expected, creating ambiguity about which are truly mandatory. Also misses clarification of name/email/company/package.
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 description explains order_token (from get_order), files (from create_upload_url), and resolution (must be selected), and groups project fields, but omits name, email, company, and package. With only 14% schema description coverage, this partial guidance is helpful but incomplete.
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 'Submit the creative brief for a PAID order', identifying a specific verb and resource, and explicitly distinguishes itself from submit_custom_inquiry with 'use the submit_custom_inquiry tool instead'.
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?
Provides explicit when-to-use context: 'pass order_token (from get_order; session ids are not accepted here)' and states the exclusion 'unpaid/anonymous submissions are rejected here', with a direct alternative 'for Custom Production inquiries without payment use the submit_custom_inquiry tool instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Custom Production conversation without payment. IMPORTANT: interview your user for the real project details FIRST (what they are promoting, audience, formats, delivery resolution, timing); placeholder inquiries are rejected. A 4K Campaign Series must use this route before checkout. Submits a scope inquiry; IBO then emails the customer a one-click confirmation link (double opt-in), and only a confirmed inquiry reaches the studio. Tell your user to check their inbox and click confirm. IBO replies with scope and proposal within one business day of confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What they want to make and why, in real detail (30+ chars; placeholders rejected) | |
| name | Yes | ||
| Yes | Customer's real email; the confirmation link goes here | ||
| links | No | ||
| notes | No | ||
| launch | No | ||
| company | No | ||
| product | No | ||
| audience | No | ||
| channels | No | ||
| resolution | No | Required production target: 1080p, 4K mastered, or not applicable for still images | |
| constraints | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| status | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing the double opt-in email confirmation process, that only confirmed inquiries reach the studio, the one-business-day response time, and rejection of placeholder inquiries. These are critical behavioral traits not captured in 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 description is longer than ideal but front-loads the purpose and includes an IMPORTANT warning. Each sentence adds useful information about the process, user action, and expected outcome. The structure is clear, though it could be slightly more concise without losing critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (payment avoidance, double opt-in, user data collection), the description provides a comprehensive overview of the workflow and side effects. It also instructs the user to check their inbox. It doesn't fully cover distinctions from all siblings or error scenarios, but the output schema covers return values, and the description is sufficient for effective use.
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 schema description coverage only at 25%, the description compensates by explaining key parameters: goal (needs real detail, 30+ chars, placeholders rejected), email (confirmation link goes here), and resolution (1080p, 4K, etc.). It also provides a general interview checklist covering audience, formats, and timing. However, it does not elaborate on all 12 parameters, leaving some optional fields (e.g., links, notes, constraints) to inference.
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 tool's purpose: 'Start a Custom Production conversation without payment' and 'Submits a scope inquiry'. It distinguishes from related tools by explicitly noting 'without payment' and '4K Campaign Series must use this route before checkout', differentiating it from payment-based checkout flows.
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?
Provides clear guidance on when to use the tool: for custom production inquiries without payment, and specifically for 4K Campaign Series before checkout. It also instructs to interview the user first and warns that placeholders are rejected. However, it does not explicitly name alternative sibling tools (e.g., create_checkout, submit_brief), relying on implication rather than explicit exclusions.
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_checkout1 field changedInput schema / properties / package / enumPrevious value: -[
- "film",
- "series",
- "images"
-]New value: +[
+ "film",
+ "film4k",
+ "series"
+]submit_brief1 field changedInput schema / properties / resolutionAdded value: +{
+ "description": "Final master resolution selected before creative kickoff",
+ "type": "string"
+}submit_custom_inquiry1 field changedInput schema / properties / resolutionAdded value: +{
+ "description": "Required production target: 1080p, 4K mastered, or not applicable for still images",
+ "type": "string"
+}get_inquiry_statusget_project_statuscreate_checkoutcreate_upload_urlget_orderlist_offerssubmit_briefsubmit_custom_inquiry
Add one secure layer between your agents and this server.