BARMAN by CeoAgentAI

place_order

Idempotent

Order one item: beer 0, sponsor 300, report 500, listing copy 900 EUR cents.

    Paid orders return a Stripe-hosted checkout URL for the payer to approve;
    this tool cannot itself charge a card. Use public_credit only for explicit
    opt-in sponsor display. A prepared diagnosis requires its private
    diagnostic_id/token and the same buyer reference. The legacy report
    without a diagnosis accepts only a public HTTPS Agent Card URL.
    Listing copy requires a saved free preview's work_id/work_token and the
    same buyer reference. It purchases the prepared AI draft, not future work.
    Public buyer identity is self-declared. Never provide card details, secret
    keys, or private endpoint URLs. Save the private receipt token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_id": "<product_id>",
      "agent_name": "<agent_name>",
      "agent_reference": "<agent_reference>",
      "accept": "<accept>",
      "expected_total_cents": "<expected_total_cents>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "place_order"
  }
}

Input Schema

Name	Required	Description	Default
`accept`	Yes
`work_id`	No
`agent_name`	Yes
`product_id`	Yes
`target_url`	No
`work_token`	No
`diagnostic_id`	No
`public_credit`	No
`agent_reference`	Yes
`idempotency_key`	Yes
`diagnostic_token`	No
`expected_total_cents`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 24, 2026

changedInput schema / properties / product_id / enum

Previous value: -[
-  "virtual-beer",
-  "sponsor-round",
-  "integration-report"
-]New value: +[
+  "virtual-beer",
+  "sponsor-round",
+  "integration-report",
+  "listing-copy-pack"
+]

addedInput schema / properties / work_id

Added value: +{
+  "default": "",
+  "pattern": "^(?:work_[a-f0-9]{32})?$",
+  "title": "Work Id",
+  "type": "string"
+}

addedInput schema / properties / work_token

Added value: +{
+  "default": "",
+  "pattern": "^(?:[a-f0-9]{64})?$",
+  "title": "Work Token",
+  "type": "string"
+}

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / diagnostic_id

Added value: +{
+  "default": "",
+  "pattern": "^(?:diag_[a-f0-9]{32})?$",
+  "title": "Diagnostic Id",
+  "type": "string"
+}

addedInput schema / properties / diagnostic_token

Added value: +{
+  "default": "",
+  "pattern": "^(?:[a-f0-9]{64})?$",
+  "title": "Diagnostic Token",
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the annotations, the description explains that this does not charge a card directly but returns a Stripe-hosted checkout URL, that buyer identity is self-declared, and that sensitive payment/secret data must not be provided. It also says to save the private receipt token, which is important operational context not covered by 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The price list is front-loaded and most sentences add necessary business rules. The description is dense but appropriately sized for a payment-producing order tool with multiple product-specific prerequisites.

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

Completeness4/5

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

For a complex order tool with an output schema and useful annotations, the description covers the critical payment flow, product-specific prerequisites, and safety constraints. It leaves some gaps around required parameters like expected_total_cents and idempotency_key, but the core calling context is present.

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

Parameters3/5

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

With 12 parameters and 0% schema description coverage, the description must carry the burden, and it does explain product_id variants, public_credit, diagnostic_id/token, work_id/work_token, target_url, and the buyer reference concept. However, required parameters such as accept, expected_total_cents, idempotency_key, and agent_name are not given meaning beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it orders exactly one item, and it names the four products with their prices. The purpose is clear, though it does not explicitly route the agent to sibling tools such as get_catalog or prepare_listing_copy.

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

Usage Guidelines4/5

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

It gives clear conditions for each product variant: public_credit only for explicit sponsor opt-in, diagnosis orders need diagnostic_id/token, legacy reports need a public HTTPS Agent Card URL, and listing copy needs saved preview tokens. It does not name the sibling tools that produce those prerequisites, so the routing is implicit rather than explicit.

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

All BARMAN by CeoAgentAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?