company-intelligence

place_order

Place an order for a priced product — creates a quote you can pay and then fulfill.

This is the missing middle of the buy path: price_product tells you what it costs, place_order creates the actual quote (owned by YOUR agent account), and fulfill_paid_order delivers it once settlement clears.

Requires a token with the mcp:buy scope AND a Velarion commerce account — a self-serve token issued at POST /agent/v1/token/self-serve has both.

CUSTOM-* cohort products (CUSTOM-PEER-COHORT / CUSTOM-SOP-WINDOW / CUSTOM-GOV-EXTENDED): the ticker list is the comparison cohort, capped at 15 distinct tickers (a 16th is a clean too_many_tickers rejection, never a silent truncation). The subject is the first in-coverage ticker unless subject_ticker names another cohort member.

Returns quote_id, the price, and how to pay. Nothing is charged here.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tickers`	Yes
`agent_token`	No
`product_type`	Yes
`scope_params`	No
`subject_ticker`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description bears full burden. Discloses mutation (creates quote, not final charge), scope of action (owned by agent account), and specific rejection behavior (too_many_tickers). Lacks details on potential errors or idempotency.

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?

Front-loaded with one-sentence summary, then structured sections for context, requirements, and cohort details. Slightly lengthy but each sentence adds value. No wasted words.

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?

Given output schema exists (return format not needed), description covers key aspects: buy path positioning, authentication, cohort constraints, and rejection behavior. Could mention error states or additional parameters.

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?

Schema coverage is 0% per context signals. Description adds meaning: explains tickers cap at 15, subject_ticker default, and cohort product rules. However, agent_token and scope_params are not explained.

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

Purpose5/5

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

Clearly states 'Place an order for a priced product — creates a quote you can pay and then fulfill.' Differentiates from sibling tools price_product and fulfill_paid_order by positioning itself in the buy path.

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

Usage Guidelines5/5

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

Explicitly states when to use: after price_product, before fulfill_paid_order. Lists prerequisites (mcp:buy scope, Velarion commerce account) and notes rejection behavior for excessive tickers.

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

All company-intelligence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct purpose: pay benchmarking, multi-company comparison, governance card generation, risk prediction, compensation lookup, product pricing, ordering, fulfillment, and catalog listing. No two tools overlap significantly; descriptions clearly differentiate them.

Naming Consistency5/5

Tool names consistently follow a verb_noun pattern (e.g., benchmark_executive_pay, compare_companies, place_order). The pattern is uniform across all 9 tools, with no mixed conventions or abbreviations that break consistency.

Tool Count5/5

With 9 tools, the server covers its domain—executive compensation, governance, risk, and commerce—without being too sparse or overwhelming. Each tool has a clear role, and the count fits the scope well.

Completeness4/5

The tool surface covers core needs: pay benchmarking, multi-company comparison, governance card, risk prediction, compensation data, and product commerce (pricing, ordering, fulfillment). Minor gaps exist, such as lacking a tool for historical data retrieval or quote updates, but the set is largely complete for its stated purpose.

Resources

Need Help?