Processor fees, charge-to-net, invoice totals and proration. 3 of 6 tools free.
Compute the gross price to charge so you net a target after fees. FREE.
'Charge X to receive Y' after percentage + fixed processor fees. Typical input {"net_target": 100, "pct_fee": 2.9, "fixed_fee": 0.30} returns {"charge": 103.4, "fee": 3.4, "net": 100.0}.
The inverse of processor_fees - solves for gross from a target net. Use when the payout is the fixed requirement. Not when the price is already set. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "net_target > 0 and pct_fee < 100 required"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| pct_fee | No | Processor percentage fee, below 100, e.g. 2.9 for 2.9%. Default 2.9. | |
| fixed_fee | No | Processor fixed fee per charge. Default 0.30. | |
| net_target | Yes | The amount you want to receive after fees; must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial error handling behavior: 'never raises a protocol error — it returns {"error": ...}' and states that every call is read-only and idempotent, making retry behavior safe. This fully discloses 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?
The description is concise (9 lines) and well-structured: purpose statement, usage guidance, example, error handling, and safety notes. Every sentence adds value; there is no filler or 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's low complexity (3 parameters, 1 required, output schema present), the description covers all essential aspects: purpose, usage, error behavior, idempotency, and read-only nature. No gaps remain.
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 100%, so the schema already documents parameters. The description adds value by providing a concrete example of typical input and output, showing how parameters combine to produce a result. This helps the agent understand parameter interplay 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 starts with 'Compute the gross price to charge so you net a target after fees.' This is a specific verb-resource combination. It also contrasts with the sibling 'processor_fees' by stating it is the inverse, clearly distinguishing the 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 explicitly states when to use ('Use when the payout is the fixed requirement') and when not to use ('Not when the price is already set'). It also references the sibling tool 'processor_fees' as the inverse, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stack discounts correctly: sequential vs additive comparison. PREMIUM (license).
The two methods differ — this shows both, the final price, and the true total discount. Typical input {"price": 200, "discounts_pct": [20, 10]} returns {"original": 200, "sequential_price": 144.0, "sequential_total_discount_pct": 28.0, "additive_price": 140.0, "difference": 4.0, "note": "..."}.
Use when more than one discount applies and the order changes the answer. Not for a single discount inside an invoice (invoice_total). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "price > 0 and at least one discount required"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Original price before discounts; must be greater than 0. | |
| discounts_pct | Yes | Discount percentages in the order applied, at least one, e.g. [20, 10] for 20% then 10%. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds extra context: 'Every call is read-only and idempotent' (consistent) and 'on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ...}' which is valuable behavioral detail not present in annotations. No 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?
The description is front-loaded with purpose, then gives an example, then usage guidelines, then error behavior. It is fairly concise but contains minor extras like 'PREMIUM (license)' which adds little. Overall well-structured and each sentence adds value, though slight trimming could improve conciseness.
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 (as indicated by context signals), the description does not need to fully describe return values. It provides an example output, error behavior, usage boundaries, and input requirements. For a simple two-parameter tool, this is highly complete and leaves no significant gaps.
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 100% and both parameters are well-described in the schema (price must be >0, discounts_pct is an array with examples). The description's example input/output reinforces but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate as description adds context via example but no new constraints or clarifications.
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 explicitly states the tool compares sequential vs additive discount stacking, which is a specific verb+resource. It distinguishes itself from sibling tools like invoice_total by noting 'Not for a single discount inside an invoice (invoice_total)' and mentions other siblings implicitly through usage guidance.
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?
Clearly says 'Use when more than one discount applies and the order changes the answer' and 'Not for a single discount inside an invoice (invoice_total)'. This gives explicit when-to-use and when-not-to-use, with a named alternative. Also provides error handling guidance: safe to retry after correcting input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a total into an installment schedule with optional deposit. PREMIUM (license).
Rounding remainders land on the final payment so the schedule always sums exactly. Typical input {"total": 1000, "installments": 3, "deposit_pct": 10} returns {"deposit": 100.0, "payments": [300.0, 300.0, 300.0], "check_sum": 1000.0}.
Use when one total is paid across scheduled dates. Not for partial-period adjustments (proration). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "total > 0 and 1-36 installments"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| total | Yes | Full amount to split; must be greater than 0. | |
| deposit_pct | No | Optional upfront deposit as a percentage of total, e.g. 10 for 10%. Default 0. | |
| installments | Yes | Number of payments after the deposit; 1 to 36. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only and idempotent nature (consistent with annotations) and adds critical behavioral traits: 'Rounding remainders land on the final payment so the schedule always sums exactly' and 'never raises a protocol error — it returns {"error": ...}'. These go beyond annotations.
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: first sentence defines purpose, then rounding guarantee, then example, then usage guidance, then error handling. Every sentence is informative; no filler. Front-loaded with most important info.
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's moderate complexity (3 parameters, output schema exists), the description covers purpose, behavior, usage, error handling, and provides a typical example. The output schema is not shown but the example compensates. Complete for an agent to select and invoke correctly.
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 100% with descriptions, but the description adds value with a concrete example showing exact input-output mapping and rounding behavior. This clarifies parameter semantics 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?
Clearly states the tool splits a total into an installment schedule with optional deposit. Distinguishes from sibling proration by explicitly saying 'Not for partial-period adjustments (proration)'. The verb 'split' and resource 'total into installment schedule' are specific.
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: 'Use when one total is paid across scheduled dates'. Provides a clear exclusion: 'Not for partial-period adjustments (proration)'. Does not differentiate from other siblings like discount_stack or invoice_total, but the use case is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total an invoice: per-line totals, subtotal, discount, tax, grand total. FREE.
Typical input {"line_items": [{"desc": "Design", "qty": 2, "unit_price": 50}], "tax_pct": 8.5, "discount_pct": 10} returns {"lines": [{"desc": "Design", "qty": 2, "unit_price": 50, "line_total": 100.0}], "subtotal": 100.0, "discount": 10.0, "tax": 7.65, "total": 97.65}.
Use when several line items roll up with discount and tax. Not for one transaction's fees (processor_fees) and not for spreading a total over time (installment_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "line_items must contain at least one item,"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_pct | No | Tax percentage applied after the discount, e.g. 8.5. Default 0. | |
| line_items | Yes | At least one line item object {"desc": str, "qty": number, "unit_price": number}; the first 100 items are used. | |
| discount_pct | No | Discount percentage applied to the subtotal. Default 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by affirming read-only and idempotent behavior: 'Every call is read-only and idempotent, so after correcting the input it is always safe to retry.' It also discloses error handling: never raises a protocol error but returns an error object with fix instructions.
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: purpose first, then example, usage guidance, error info, and safety note. While it includes an example and error details which are helpful, it is slightly longer than necessary. Still, every sentence serves a clear purpose.
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's moderate complexity (3 parameters, output schema exists), the description covers purpose, usage context, error behavior, idempotency, and provides a full example. It leaves no obvious gaps for an AI agent to operate correctly.
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 100%, so baseline is 3. The description adds a concrete input example with line_items, tax_pct, discount_pct and shows the output format, which enhances understanding of parameter relationships. However, the schema already describes all parameters well, so the description provides moderate added value.
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: 'Total an invoice: per-line totals, subtotal, discount, tax, grand total.' It provides a specific verb and resource, and distinguishes itself from sibling tools by explicitly naming what it is not for (processor_fees, installment_plan).
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 explicitly states when to use: 'Use when several line items roll up with discount and tax.' It also lists alternatives: 'Not for one transaction's fees (processor_fees) and not for spreading a total over time (installment_plan).' Additionally, it explains error behavior and retry safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break down payment-processor fees: fee, net, and effective rate. FREE.
Uses editable presets for stripe/paypal/square/shopify (verify current rates) or your own custom_pct + custom_fixed. Typical input {"amount": 1000, "processor": "stripe", "transactions": 10} returns {"gross": 1000, "fee": 32.0, "net": 968.0, "effective_rate_pct": 3.2, "note": "..."}.
Use when the charge amount is known and the net payout is the question. Not for the reverse: the gross needed to net a target is charge_to_net. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "amount must be > 0, transactions >= 1"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Total gross amount processed; must be greater than 0. | |
| processor | No | One of "stripe", "paypal", "square", "shopify", or "custom". Default "stripe". | stripe |
| custom_pct | No | Percentage fee used when processor is "custom", e.g. 2.5 for 2.5%. | |
| custom_fixed | No | Fixed per-transaction fee used when processor is "custom", e.g. 0.25. | |
| transactions | No | How many transactions the amount is spread across; at least 1. Default 1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by detailing the error mode: 'never raises a protocol error — it returns {"error": "..."}'. It also explicitly states 'Every call is read-only and idempotent', reinforcing safety and retry suitability. No contradictions with annotations.
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 concise with no fluff. It is front-loaded with the core purpose, then provides examples, usage guidance, and error handling in a logical order. Every sentence earns its place, and the length is appropriate for the tool's complexity.
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?
Despite having an output schema, the description includes a sample output, which aids understanding. It covers inputs (including custom presets), typical values, error return format, and safety guarantees. The tool is fully described for correct invocation and interpretation.
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?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing a typical usage example (amount, processor, transactions) and clarifying that custom_pct is a percentage (e.g., 2.5 for 2.5%). It also explains the relationship between parameters (custom fields only used with 'custom' processor). This enriches understanding 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's purpose: 'Break down payment-processor fees: fee, net, and effective rate.' It uses specific verbs and resources, and explicitly distinguishes from the sibling tool 'charge_to_net' by noting the reverse use case. This makes the purpose unambiguous and differentiated from alternatives.
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 explicit guidance: 'Use when the charge amount is known and the net payout is the question. Not for the reverse: the gross needed to net a target is charge_to_net.' It also explains error handling and safe retry behavior, giving clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a prorated charge or refund for a partial billing period. PREMIUM (license).
Typical input {"amount_per_period": 90, "days_used": 10, "days_in_period": 30} returns {"days_used": 10, "days_in_period": 30, "prorated_charge": 30.0, "prorated_refund": 60.0, "answer": 30.0}.
Use when a plan starts, ends, or changes mid-period. Not for splitting a full amount into scheduled payments (installment_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "need amount > 0 and 0 <= days_used <= days_in_period"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| days_used | Yes | Days of the period consumed; 0 to days_in_period. | |
| refund_mode | No | If true, "answer" is the refund amount instead of the charge. Default false. | |
| days_in_period | No | Length of the billing period in days; at least 1. Default 30. | |
| amount_per_period | Yes | Full-period price; must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool never raises protocol errors on invalid input, instead returning an descriptive error object. It confirms idempotency and safety for retries after corrections. These behaviors go beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by explaining the exact error-handling mechanism and providing actionable advice for the agent.
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 purpose statement, example, usage guidance, error behavior, and safety note. It is comprehensive yet relatively concise. Minor improvement: the example JSON formatting uses newlines which helps readability, but the error example could be shorter without losing 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 tool's moderate complexity (4 parameters, 2 required), full schema coverage, output schema availability, and annotations covering read-only and idempotent nature, the description is complete. It covers purpose, usage boundaries, error model, retry safety, and provides a concrete example. No notable gaps remain.
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?
The schema already provides 100% coverage with clear descriptions and defaults. The description adds value by showing a concrete example (`90, 10, 30 → 30.0`), which illustrates the relationship between parameters. It also clarifies that `amount_per_period` must be greater than 0, which is already in schema but reinforced. However, the description does not explain `refund_mode` in detail beyond the example context.
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: 'Compute a prorated charge or refund for a partial billing period.' It provides a concrete example and explicitly distinguishes itself from the sibling tool `installment_plan`, which is used for splitting full amounts into scheduled payments.
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 includes explicit guidance on when to use ('when a plan starts, ends, or changes mid-period') and when not to use ('Not for splitting a full amount into scheduled payments (installment_plan)'). It also names the sibling tool `installment_plan` as the alternative, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
charge_to_netdiscount_stackinstallment_planinvoice_totalprocessor_feesprorationClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Dimensional weight, parcel fit, landed cost and freight class. 4 of 6 tools free.
Margin, lead time, SKU mapping and price-ladder maths for dropshipping. 4 of 6 free.
Calculate sales tax & VAT, record transactions and refunds, manage products and customers.
Business days, meeting overlap and recurrence expansion, deterministic. 3 of 5 tools free.
Add one secure layer between your agents and this server.
Each tool serves a distinct pricing/financial calculation: gross-up from net (charge_to_net), stacking discounts (discount_stack), installment schedules (installment_plan), invoice totals (invoice_total), processor fee breakdown (processor_fees), and proration (proration). Even closely related tools like charge_to_net and processor_fees are clearly inverses, with descriptions explicitly noting when to use one versus the other.
All six tool names use a clear noun or noun phrase with underscores, following a consistent pattern (e.g., charge_to_net, discount_stack, installment_plan). The only minor deviation is that some names are verb-first (charge_to_net) while others are noun-first (processor_fees), but the pattern is predictable and readable.
With six tools, the set is well-scoped for a merchant/pricing MCP server. Each tool covers a common financial calculation need (fees, discounts, installments, invoicing, proration) without bloat. The count is lean yet sufficient for its domain.
The tool set covers core merchant calculations: gross-up, fee breakdown, discount stacking, installment plans, invoice totaling, and proration. Minor gaps include missing currency conversion or tax jurisdiction handling, but for a focused pricing/fee calculator the coverage is solid.
