SmartFin

Profit margin

smartfin_calculate_profit_margin

Read-onlyIdempotent

The profit and the profit margin percentage from revenue and total costs (margin = (revenue - costs) / revenue x 100). A negative margin is a valid result. Use for questions about profit as a share of sales, from two figures for the same period. Do not use for return on money invested (use smartfin_calculate_roi), for taxes, or to say whether a margin is good: the tool reports the figure only. The cost figure is whatever the user supplies, so it says nothing about gross versus net unless they define it.

Input Schema

Name	Required	Description
`revenue`	Yes	Revenue for the period in the currency chosen, above 0
`currency`	No	Currency symbol for the amounts in the summary only; amounts are never converted. The link opens the page in US dollars, and how_to says to pick the currency there. Default USD
`total_costs`	Yes	Total costs for the same period in the currency chosen; it can be above revenue

Output Schema

Name	Required	Description
`cite`	Yes	How to credit this result
`data`	Yes
`next`	Yes	Suggested follow-up calls
`links`	Yes
`how_to`	Yes	Steps for the user to see or redo this on smartfin.fyi
`source`	Yes
`summary`	Yes	Plain-language result the assistant can quote

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 18, 2026

addedInput schema / properties / currency

Added value: +{
+  "description": "Currency symbol for the amounts in the summary only; amounts are never converted. The link opens the page in US dollars, and how_to says to pick the currency there. Default USD",
+  "enum": [
+    "USD",
+    "EUR",
+    "GBP",
+    "CHF",
+    "AUD",
+    "CAD",
+    "SGD",
+    "HKD",
+    "INR",
+    "JPY"
+  ],
+  "type": "string"
+}

changedInput schema / properties / revenue / description

Previous value: -"Revenue for the period in dollars, above 0"New value: +"Revenue for the period in the currency chosen, above 0"

changedInput schema / properties / total_costs / description

Previous value: -"Total costs for the same period in dollars; it can be above revenue"New value: +"Total costs for the same period in the currency chosen; it can be above revenue"

AddedOct 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the description wisely spends its budget on things annotations cannot convey: a negative margin is a valid result, the tool reports the figure without judging it, and the cost input is user-defined so gross vs net is undefined. It stops short of stating precision/rounding or failure behavior, so not a full 5.

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 output and formula lead, then usage, then caveats – properly front-loaded with no filler sentences. It is fairly dense at four sentences, and the closing gross/net sentence could arguably fold into the same-period sentence, keeping it just short of 5.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description covers the remaining gaps – scope ambiguity (gross vs net), negative results, currency not being converted per the schema note, and sibling routing – leaving nothing an agent needs to call it correctly.

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 coverage is 100%, so the baseline is 3 since the schema already documents revenue, total_costs and currency. The description still adds interpretation the schema lacks: both figures must cover the same period, and the cost figure's gross/net meaning depends entirely on the user, which changes how the result should be described.

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+resource (compute profit and margin %) and even spells out the formula, so the agent knows exactly what is produced. It explicitly contrasts itself with smartfin_calculate_roi, which is the closest sibling, and notes the required scope (two figures for the same period).

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?

Gives positive triggers (questions about profit as a share of sales), explicit exclusions (ROI, taxes, judging whether a margin is good), and the period-alignment precondition. This is a genuine when/when-not/alternative routing block rather than vague context.

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

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