Vendwiser

Margin report

margin_report

Read-onlyIdempotent

[Analysis] Margin of the products actually sold on a marketplace in a period, line by line and per product: sale price without VAT, the real commission from the statement, the real courier cost of the order from the shipping invoices (shared between its lines by value), the product cost from the company system (Odoo, by barcode or SKU) and what is left, in money and percent. Lists the products sold at a loss or under the margin floor, the lines without a known cost, and returns in the period. Statements and courier invoices where the marketplace has them (Trendyol); elsewhere the finalised orders with the commission of the rules.

Input Schema

Name	Required	Description
`account`	No	Account id, label, domain or "channel country" (e.g. "emag ro"). Optional when only one account is connected.
`date_to`	No	YYYY-MM-DD. Default: yesterday.
`date_from`	No	YYYY-MM-DD. Default: 30 days ago.
`cost_field`	No	Which Odoo cost: the main supplier price (default, what the factory charges) or the standard price.
`cost_source`	No	auto (default): the pricing app (materials + factory labour) where the seller connected it, else Odoo. odoo: the transfer price in Odoo.
`vat_percent`	No	Default 21.
`cost_account`	No	The company-system account with the product costs. Default: the Odoo account that knows the barcodes.
`min_margin_percent`	No	Floor under which a product is flagged, in % of the price without VAT. Default 10.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / cost_source

Added value: +{
+  "description": "auto (default): the pricing app (materials + factory labour) where the seller connected it, else Odoo. odoo: the transfer price in Odoo.",
+  "enum": [
+    "auto",
+    "pricing_app",
+    "odoo"
+  ],
+  "type": "string"
+}

AddedOct 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With readOnlyHint, idempotentHint and destructiveHint=false already covering the safety profile, the description adds real behavioural value: it discloses data provenance and a fallback path (statements and courier invoices where the marketplace has them, e.g. Trendyol; elsewhere finalised orders with rule-based commission), how courier cost is allocated across lines by value, and what is flagged (losses, below-floor margins, unknown-cost lines, returns). It does not discuss run cost or limits, but nothing it omits undermines correct invocation.

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?

Purpose is front-loaded and every clause contributes substance about sources and outputs. The second sentence is long and dense, packing the fallback logic and the exception list into one run-on, but it is not padded.

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 an 8-parameter, all-optional reporting tool with a full output schema and read-only annotations, the description supplies everything an agent needs to decide the call is appropriate: scope, cost sources, fallback data path, and what the report surfaces. Return-value detail is correctly left to the output schema.

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 description coverage is 100% with all 8 parameters documented and 2 enums explained, so the schema carries the semantics and a 3 is the baseline. The narrative does add conceptual colour (cost pulled from Odoo by barcode/SKU, a margin floor relative to the ex-VAT price), but it adds no parameter-specific detail beyond what the schema already states.

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?

It states a specific analysis verb and resource — margin of products actually sold on a marketplace in a period, line by line and per product — and enumerates the exact cost components (sale price ex-VAT, real commission, real courier cost, Odoo product cost). That is far more specific than a generic report tool, but it never names the closest sibling (margin_simulate), so an agent must infer the actuals-vs-simulation split.

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 framing ('products actually sold', 'the real commission from the statement') implies this is the retrospective actuals report rather than a forward-looking simulation, which weakly implies when to use it. However there is no explicit 'use this when…' statement, no exclusion, and no pointer to margin_simulate or attention_report for related questions.

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

All Vendwiser 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?