Agent Central

Profitability review

get_profitability_review

Read-only

Returns ranked ASIN profitability issue signals from Shipment/Refund financial-event net, FBA reimbursements, returns, Business Reports sales and units, and SP/SD product ad spend. Financial-event revenue, fees, tax, and marketplace net are selected by posted_date, not order date; Business Reports use their order-date basis, while ads, returns, and reimbursements use their own source dates. The same requested window can therefore contain different transaction cohorts near its cutoffs and must not be treated as one order-date cohort without accounting for posting lag. Account-level Adjustment/ServiceFee financial events are excluded because they cannot be deterministically attributed to an ASIN. Fees on off-Amazon fulfillment (MCF) orders, which carry no Principal, are excluded from fees, net, and contribution and returned in off_amazon_fulfillment_fees; prior_period_order_share reports how much posted principal came from orders placed before the period. Set include_sponsored_brands=true to return exact SB campaign spend once in summary.account_level_costs as an unallocated account-level cost. It is not allocated to, deducted from, or repeated across ASIN rows. Responses expose date_basis, scope, excluded_costs, and reconciliation_note. DSP ad spend, FBA storage fees, inbound freight, COGS, and account-level Adjustment/ServiceFee events remain excluded. Money is scoped to the marketplace currency by default; set include_all_currencies=true to include mixed currencies. A data gap reports when Refund financial events are absent in the period.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sku`	No	Filter by SKU.
`asin`	No	Filter by ASIN.
`limit`	No	Max review rows to return.
`end_date`	No	Optional. YYYY-MM-DD end date applied independently to each source date. Defaults to today in the marketplace reporting time zone.
`start_date`	No	Optional. YYYY-MM-DD start date applied independently to each source date. Defaults to 30 days ago.
`high_fee_pct`	No	Amazon fees above this percent of gross revenue are flagged as fee_pressure.
`review_focus`	No	Profitability issue to focus on. Defaults to all non-healthy issues.	all
`high_tacos_pct`	No	SP/SD ad spend above this percent of sales is flagged as ad_drag.
`include_healthy`	No	Set true to include healthy ASINs after profitability issues. Defaults to false.
`include_raw_rows`	No	False returns compact rows. Default true.
`target_margin_pct`	No	Contribution margin below this percent is flagged as low_margin.
`include_diagnostics`	No	True may add expanded freshness diagnostics. Basic empty-result data-window diagnostics are included by default when available.
`high_return_rate_pct`	No	Returned units above this percent of units ordered are flagged as high_return_rate.
`include_all_currencies`	No	By default, money (financial events, reimbursements, ad spend) is scoped to the marketplace currency so amounts are not summed across USD/CAD/MXN etc. Set true to include all currencies (amounts are then mixed and should not be summed).
`include_sponsored_brands`	No	Return exact Sponsored Brands campaign spend once as an unallocated account-level cost. It is not allocated to ASIN rows or included in their contribution, TACOS, ACOS, or ranking metrics. Defaults to false.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`evidence`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare a safe read-only profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description adds substantial non-obvious behavior: per-source date bases and posting lag, exclusion of Adjustment/ServiceFee events, MCF fee handling, the SB unallocated-cost treatment, currency scoping, and data-gap reporting. This is exactly the value-add beyond structured fields that a strong definition provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The content is dense and mostly front-loaded, but it is delivered as one long unstructured paragraph mixing purpose, date-basis caveats, exclusions, and parameter behavior. No bullets or grouping, making it harder to scan; several clauses could be tightened without losing meaning.

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

Completeness5/5

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

For a complex 15-parameter tool, the description is remarkably complete: it covers data provenance, date semantics, inclusion/exclusion boundaries, currency handling, and expected diagnostics. With an output schema present, it correctly does not need to explain return field shapes.

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

Parameters4/5

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, but the description adds genuine meaning beyond the schema for include_sponsored_brands (returned once as unallocated account-level cost, not repeated on ASIN rows) and include_all_currencies (mixed amounts must not be summed). Flags like review_focus and include_diagnostics are left to the schema, so it is not a full 5.

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?

States a specific verb and resource: returns ranked ASIN profitability issue signals, and enumerates the exact source domains (financial events, reimbursements, returns, Business Reports, SP/SD ad spend). This is clearly distinguishable from siblings like get_tacos or get_product_performance, which surface raw metrics rather than a ranked issue review.

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

Usage Guidelines3/5

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

The description thoroughly explains what the tool computes and how parameters affect output, but never states when to choose this tool over alternatives such as get_tacos, get_product_performance, or get_financial_events. Usage context is implied by the issue-focus framing rather than made explicit.

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

All Agent Central 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.