company-intelligence
Server Details
Exec comp benchmarking, say-on-pay risk, and governance cards for US public companies.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 9 of 9 tools scored. Lowest: 3/5.
Tools cover distinct areas: benchmarking, comparison, compensation lookup, governance, ordering, and pricing. There is some overlap between benchmark_executive_pay and lookup_company_compensation, but descriptions clarify differing purposes (benchmark vs. lookup). Overall, agents should be able to select appropriate tools without confusion.
All tools follow a consistent verb_noun pattern in snake_case (e.g., benchmark_executive_pay, compare_companies, price_product). Naming is predictable and clear, aiding agent selection.
9 tools is well-scoped for the company intelligence domain. Each tool serves a distinct function without redundancy, and the count is neither too sparse nor overwhelming.
The tool set covers the core workflow: pricing, ordering, fulfillment, and key intelligence (compensation, governance, risk). Missing a generic company search or profile tool, but the main use cases are addressed. Minor gap but not critical.
Available Tools
9 toolsbenchmark_executive_payBInspect
Benchmark executive pay vs. disclosed peers using Velarion's canonical percentile data.
Returns pay percentile, performance (TSR) percentile, P4P gap, and an alignment label based on canonical_metrics columns (ceo_percentile, tsr_percentile, p4p_gap). No LLM.
role is currently CEO-only (only CEO percentile is pre-computed in canonical_metrics).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | CEO | |
| ticker | Yes | ||
| agent_token | No | ||
| fiscal_year | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'No LLM' (deterministic) and role limitation. With no annotations provided, description carries full burden but lacks details on side effects, permissions, or other behavioral traits.
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?
Concise at 4 sentences, front-loads purpose and returns. Every sentence adds value, though structure could be improved.
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 core function and return values but lacks parameter details and usage context. With output schema present, return values need not be detailed, but parameter gaps reduce completeness.
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 0%; description does not explain parameters ticker, agent_token, or fiscal_year beyond implying role is CEO-only. Fails to add meaning for 3 of 4 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?
Description clearly states the tool benchmarks executive pay vs. disclosed peers using specific percentile data and lists returned metrics. It identifies the resource and action but does not explicitly differentiate from siblings like compare_companies or lookup_company_compensation.
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 guidance on when to use this tool vs. alternatives. The only usage hint is that role is currently CEO-only, but no alternative tools are suggested for other roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_companiesAInspect
Compare multiple companies on pay, performance, and governance metrics.
Returns a ranked table from Velarion's canonical_metrics — no LLM narrative invention. The data-based summary describes observed patterns in the returned data only. Out-of-coverage tickers are excluded (listed separately). Max 20 tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | ||
| agent_token | No | ||
| fiscal_year | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns a ranked table, uses canonical_metrics, excludes out-of-coverage tickers, imposes a max 20 ticker limit. This covers key behavioral traits without 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?
Four tight sentences, no fluff. Critical constraints (max 20, data-based) are front-loaded. Every sentence adds value.
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?
Tool has 3 params (1 required) and output schema exists. Description explains return type, constraints, and metric dimensions. It is sufficient for usage, though fiscal_year and agent_token could use brief mention.
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 0%; description only explains the `tickers` parameter implicitly (companies to compare). It does not describe `agent_token` or `fiscal_year`, leaving their purpose unclear. Given the low coverage, the description should compensate more.
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 the verb 'compare' with resource 'multiple companies' on specific metrics (pay, performance, governance), clearly distinguishing its multi-company comparison purpose from siblings like `lookup_company_compensation` or `benchmark_executive_pay`.
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 context: returns data-based summaries (no LLM narrative), max 20 tickers, handles out-of-coverage tickers explicitly. However, it does not explicitly state when to use this tool vs. alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fulfill_paid_orderAInspect
Fulfill a paid custom quote by compiling and delivering its artifact.
Ownership gate: you may only fulfill a quote your own agent account owns. (The REST buyer rail has always enforced this — routes.py:656 — and this tool did not, which meant any valid token could fulfill, and therefore download, an artifact somebody else had paid for. Latent while every token was owner-issued; a live artifact leak the moment self-serve issuance opened. Closed here.)
Settlement gate (fail-closed): if the quote is priced and settlement is not verified on any rail, returns settlement_unverified — compile_and_deliver is NOT called.
On verified settlement: calls compile_and_deliver (fulfillment.py:121) — the same path used by Danny and the agent bridge. No forked fulfillment logic.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| agent_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: ownership gate (must own the quote), settlement gate (fail-closed if not verified), success path (calls compile_and_deliver), and security implications (artifact leak previously). This is comprehensive.
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 front-loaded with the main purpose but includes verbose internal details (file paths, historical context) that add length without essential guidance. A more concise version could improve 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?
Given the output schema exists (not shown), the description adequately covers success and failure conditions, gates, and background. However, it lacks parameter details and could briefly explain what 'artifact' refers to for completeness.
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%, and the description does not explain the two parameters (quote_id, agent_token) beyond implying quote_id is needed. The description should compensate for the lack of schema documentation but fails to describe parameter formats, sources, or defaults.
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 'Fulfill a paid custom quote by compiling and delivering its artifact.' This specifies the verb (fulfill), resource (paid custom quote), and action (compile and deliver artifact), distinguishing it from sibling tools like place_order or price_product.
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: ownership gate and settlement gate. It tells when to use (after payment/price verification) and when not (not owner or settlement not verified). However, it lacks explicit comparison to sibling tools or when to prefer this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_governance_alpha_cardAInspect
Generate a Governance Alpha Card for a company.
Composite deterministic card: pay alignment (ISS P4P), governance scorecard, SoP risk band, peer quality, top risks/strengths. Requires the company to be in Velarion's coverage universe with current-period data.
Calls generate_alpha_card (lib/agent_merchant/compilers/governance_alpha_card.py:441) after confirming deliverability via evaluate_deliverability (deliverability.py:219), which includes the period-currency gate (_governance_alpha_card_period_gate at :312).
FREE-TIER CAP: this is the free sample of a $100 marketplace product (GOVERNANCE-ALPHA-CARD, pricer.py:59). Each agent gets ALPHA_CARD_FREE_DAILY_CAP cards per UTC day; beyond that the tool returns free_tier_cap_reached with the purchase path. Unlimited free issuance of the paid anchor product is the contradiction the catalog's PRICE_INTEGRITY blocker named — the cap is what resolves it.
Structured errors returned (not raised) for:
not_in_coverage: ticker unknown
not_deliverable: coverage too thin / stale period
free_tier_cap_reached: daily free allowance spent (buy it, or wait for 00:00 UTC)
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| ticker | Yes | ||
| agent_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It reveals the tool is deterministic, calls internal functions, enforces a free-tier cap, returns structured errors instead of raising them, and includes a period-currency gate. This is highly 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?
The description is verbose, including internal file paths and line numbers (e.g., lib/agent_merchant/compilers/governance_alpha_card.py:441) that are not useful for an AI agent. The free-tier cap explanation is overly detailed. A more concise description would maintain clarity while removing implementation clutter.
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 description covers prerequisites, card contents, error conditions, and the free-tier cap. The presence of an output schema (indicated by context) reduces the need to describe return values. Minor gaps remain about parameter details, but overall it is fairly 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 coverage is 0% and the description does not explain the parameters. 'ticker' is obvious as required, but 'year' and 'agent_token' are not described. The mention of 'current-period data' hints at 'year' but lacks clarity. The agent receives minimal help 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 generates a Governance Alpha Card for a company and lists its composite components. It distinguishes itself by requiring Velarion coverage and current-period data, which are specific to this 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?
The description explains prerequisites (coverage, current-period data) and error scenarios (not_in_coverage, not_deliverable, free_tier_cap_reached), but does not explicitly compare to sibling tools like benchmark_executive_pay or predict_say_on_pay_risk, leaving the agent to infer when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_skusAInspect
List the Velarion catalog — every product an agent can see and (where APPROVED_SELLABLE) buy.
Returns all APPROVED_SELLABLE SKUs with full detail by default (sku_id, name, price, currency, fulfillment type, latency, caveats, classification). Set include_non_sellable=true to also return NEEDS_OWNER_APPROVAL / UNSELLABLE / KILLED rows, each clearly tagged with its classification and blockers so inventory is never hidden — only de-prioritized. No price is fabricated: unverified prices are surfaced as-is with their classification, never quoted as billable.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_token | No | ||
| include_non_sellable | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: default filtering, the effect of include_non_sellable, and an important policy about not fabricating prices. This goes beyond basic functionality to build trust.
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 well-structured with a clear first sentence for purpose, followed by details on default behavior, the optional parameter, and a transparency note. No redundant sentences.
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, the description covers purpose, parameter usage, behavior, and output fields comprehensively. Edge cases like price handling are also addressed.
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 thoroughly explains include_non_sellable, but does not mention agent_token at all. Partial compensation.
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 the Velarion catalog and specifies what is returned by default (APPROVED_SELLABLE SKUs with full detail). It distinguishes itself from sibling tools which are unrelated to catalog listing.
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 explains the default behavior and how to use the include_non_sellable parameter to broaden results. It does not explicitly mention when not to use this tool, but the sibling tools are distinct, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_company_compensationAInspect
Look up executive compensation for a company in Velarion's coverage universe.
Returns CEO/NEO total compensation, pay mix breakdown, and canonical metrics for the requested fiscal year (latest available if omitted). All data sourced from Supabase production tables — no LLM, no invented values.
Out-of-coverage tickers return a structured error (not_in_coverage).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| agent_token | No | ||
| fiscal_year | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It discloses data source (Supabase production tables), assures no invented values (no LLM), and explains error handling for out-of-coverage tickers. It does not mention auth or rate limits, but for a read-like lookup tool this is sufficient.
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 paragraphs, direct and without fluff. The first sentence front-loads the main purpose. Every sentence adds value: data description, data source assurance, and error handling.
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 has an output schema (so return values are documented elsewhere), three parameters, and no annotations, the description covers the essential semantic and behavioral aspects thoroughly. It explains what data is returned, source reliability, and error scenarios, making it complete for selecting and invoking the 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?
Schema description coverage is 0%, so description must compensate. It explains the fiscal_year parameter (optional, defaults to latest). However, the agent_token parameter is not described at all, leaving its purpose unclear. The ticker parameter is mentioned implicitly but not detailed.
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 it looks up executive compensation for a company in a coverage universe, listing specific data returned (CEO/NEO total comp, pay mix, canonical metrics). It distinguishes from siblings like benchmark_executive_pay and predict_say_on_pay_risk by being the basic lookup 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?
The description implies when to use: for compensation data within coverage, with optional fiscal year. It notes that out-of-coverage tickers return a structured error, guiding expected behavior. However, it does not explicitly contrast with sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
place_orderAInspect
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.
Returns quote_id, the price, and how to pay. Nothing is charged here.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | ||
| agent_token | No | ||
| product_type | Yes | ||
| scope_params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes that the tool creates a quote, returns quote_id/price/payment info, and does not charge. It also mentions required scope and account. However, it does not discuss rate limits or potential 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?
Well-structured with a front-loaded core sentence, followed by context and prerequisites. Each sentence adds value, though it could be slightly more concise.
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 presence of an output schema (not shown) and the description's coverage of high-level flow, prerequisites, and return info, it is fairly complete. However, the lack of parameter explanations due to 0% schema coverage reduces completeness.
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 description must compensate. While it implies product_type and tickers are needed, it does not explain agent_token or scope_params in detail. The description lacks parameter-level guidance beyond what the schema names provide.
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 function: 'Place an order for a priced product — creates a quote you can pay and then fulfill.' It distinguishes itself from sibling tools price_product and fulfill_paid_order by explaining the role 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after price_product and before fulfill_paid_order. Also specifies prerequisites: requires token with mcp:buy scope and a Velarion commerce account, and clarifies that nothing is charged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_say_on_pay_riskBInspect
Predict Say-on-Pay risk for a company using Velarion's deterministic risk compilers.
Returns trend phrase, peer cohort distribution note, governance friction summary, and overall risk band. No LLM — fully deterministic from canonical_metrics + say_on_pay data.
Compilers: compile_sop_trend_phrase, compile_sop_peer_cohort_distribution, compile_governance_friction_summary (lib/agent_merchant/compilers/say_on_pay_risk.py).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| agent_token | No | ||
| fiscal_year | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is deterministic (no LLM) and specifies the return fields and compilers used. However, it lacks details on side effects, permissions, or limitations. Given no annotations, this is moderate coverage.
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, then returns and implementation. Every sentence provides distinct value with 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?
Given the tool has 3 parameters, no annotations, and the output schema exists, the description covers purpose and returns but omits parameter semantics and usage context. It 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?
With 0% schema description coverage and 3 parameters (ticker, agent_token, fiscal_year), the description adds no explanation of any parameter. The agent must infer parameter meaning solely from names, which is insufficient.
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 predicts Say-on-Pay risk for a company, using a specific verb 'predict' and resource 'Say-on-Pay risk'. It distinguishes from siblings like benchmark_executive_pay and lookup_company_compensation by focusing on risk prediction with deterministic compilers.
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 guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, required data, or situations where another tool (e.g., benchmark_executive_pay) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_productAInspect
Price a Velarion product. Handles EVERY catalog SKU in its real state.
product_type may be a sku_id (e.g. "SKU-002") OR a custom_artifact_family (e.g. "peer_disclosure_custom_cohort"). Returns the row's classification and, when APPROVED_SELLABLE, the price a buyer is actually charged:
APPROVED_SELLABLE → proposed_price_cents + currency + fulfillment_type + latency + caveats. No price floor touches it (deleted 2026-07-14); the catalog/pricer anchor IS the billed price.
NEEDS_OWNER_APPROVAL → {status: "needs_owner_approval"} structurally — price is known but the row is pending Andy's approval flip.
UNSELLABLE / KILLED → structured error with the reason.
custom_band families price via the profit-aware pricer (respecting MERCHANT_MIN_MARGIN); one_off_fixed SKUs price at the canonical catalog price_cents. No fabricated price is ever returned (price_verified gate enforced upstream in classify_sku).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| buyer_type | No | ||
| agent_token | No | ||
| product_type | Yes | ||
| scope_params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: handling of real state, three outcomes (APPROVED_SELLABLE, NEEDS_OWNER_APPROVAL, UNSELLABLE/KILLED), no price floor, profit-aware pricer, and no fabricated prices. This is comprehensive and beyond minimal.
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 well-structured with bullet points and front-loaded purpose. It includes detailed information without redundancy. Slight verbosity in some lines (e.g., price_verified gate mention) but overall 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?
The description covers return types and logic well, but missing parameter explanations (buyer_type, agent_token, scope_params) and no usage examples. An output schema exists, but parameter details are lacking for completeness.
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 0%, so the description should compensate. It elaborates on product_type only (sku_id vs custom_artifact_family) and implies ticker. Parameters like buyer_type, agent_token, and scope_params are not explained, leaving agents guessing about their roles.
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: 'Price a Velarion product. Handles EVERY catalog SKU in its real state.' It provides specific verb (price) and resource (Velarion product), and distinguishes from siblings like list_skus or place_order by focusing on pricing logic.
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 context (pricing products after classification) but does not explicitly state when not to use or mention alternatives among siblings. It provides clear context but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!