REGULARUS

Calculate fixed price

get_fixed_price

Calculate the price for a cosmetic product safety report (CPSR) by product type, number of recipes and varieties, markets, company seat, package and add-ons. Same calculation as the questionnaire on the website. Returns prices per package, what is included, what costs extra, assumptions and a confirmUrl for the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_type": "<product_type>"
    },
    "name": "get_fixed_price"
  }
}

Input Schema

Name	Required	Description
`lang`	No	Language of the texts in the response and on the confirmation page (default en).
`seat`	No	Seat of the company (default de; determines VAT and the EU representative).
`maker`	No	Who manufactures the products (does not change the price).
`claims`	No	Whether special claims are made (e.g. "vegan", "anti-wrinkle").
`express`	No	Report in 5 instead of 10 working days, with a surcharge.
`markets`	No	Where the products are sold (default EU).
`package`	No	Package; without it all three are returned with a recommendation.
`recipes`	No	Own recipes (base formulas) per product type (default 1).
`urgency`	No	How urgent it is (does not change the price; faster with express=true).
`varieties`	No	Total varieties per product type, base products included (e.g. one recipe with three fragrances: recipes=1, varieties=3). Default: same as recipes.
`product_type`	Yes	Product type; several separated by commas, with recipes and varieties in the same order.
`uk_documents`	No	Documents for Great Britain per variety (only with markets=UK).
`claims_review`	No	Review of advertising claims per variety (not with claims=no).
`recipe_status`	No	How far the recipe is (does not change the price).
`stability_test`	No	Stability test in our laboratory (products containing water only).
`eu_representative`	No	We act as your responsible person in the EU (only with seat=de or eu, yearly price).
`responsible_person`	No	Only with seat=non_eu: us = we act as your responsible person in the EU (yearly price), self = you already have one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and largely does so: it discloses the returned payload (prices per package, what is included, what costs extra, assumptions, and a confirmUrl), which implies a non-mutating calculation followed by an explicit user confirmation. It does not state whether the calculation is free/idempotent or whether any data is persisted, so it stops short of full disclosure.

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?

Three sentences, front-loaded with the verb and resource, followed by the input dimensions and the return shape. The middle sentence is a dense comma list that could be trimmed, but nothing is redundant with the schema and the length suits a 17-parameter calculator.

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

Completeness4/5

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

For a 17-parameter pricing tool with no annotations and no output schema, the description compensates well by sketching the return payload and pointing to a confirmUrl for the user. Combined with a fully documented schema, an agent has enough to invoke it correctly, though edge-case behavior (e.g. how unknown/ambiguous inputs affect the quote) is still unaddressed.

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% across all 17 parameters, including defaults, the recipe/variety mapping, and cross-parameter conditions (UK documents only with markets=UK, eu_representative only with seat=de/eu), so the schema does the heavy lifting. The description only restates the input categories at a high level and adds no syntax or semantics beyond the schema. Baseline 3.

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?

States a specific verb+resource: "Calculate the price for a cosmetic product safety report (CPSR)", and enumerates the driver inputs (product type, recipes, varieties, markets, seat, package, add-ons). An agent immediately knows this is a pricing/quoting tool, distinct from list_documents and verify_report. No sibling differentiation is offered, but the purpose is unambiguous without it.

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?

"Same calculation as the questionnaire on the website" tells the agent this mirrors the site's quoting flow, which implies intended usage. There is no explicit when-not-to-use or alternative-tool guidance, and it does not say what to do if required inputs are unknown. Usage is implied rather than specified.

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

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