The Octura Solutions Site Tools server provides 24 deterministic ERP and business calculators, accessible via a remote MCP endpoint (no installation or API key required). It supports streamable HTTP, initialize, ping, tools/list, tools/call methods, and stdio bridge options. All tools are pure functions with documented defaults and corresponding interactive web pages, rate-limited per IP.
Odoo cost and planning: Estimate implementation, migration, upgrade, total cost of ownership, ROI, Odoo.sh hosting, stack savings, EDI integration, app selection, ERP shortlist scoring, and tune worker/memory settings.
Tax calculations: US state sales tax (add/extract), US economic nexus, Canadian GST/HST/PST/QST, EU VAT with VIES validation, and Canadian payroll source deductions (CPP, EI, income tax).
Inventory and operations: Compute inventory turnover, reorder point, safety stock, EOQ, carrying cost, landed cost, margin/markup/price conversions, and OEE.
Provides Odoo implementation, migration, upgrade cost calculators, ROI and total cost of ownership analysis, hosting cost estimation, and other Odoo-related ERP planning tools.
A hosted Model Context Protocol server exposing 30 read-only tools: 25 deterministic ERP calculators (Odoo implementation, migration and upgrade costs, ROI and total cost of ownership, sales tax for the US, Canada and the EU, Canadian payroll source deductions, and inventory maths like reorder point, safety stock and EOQ) plus five content lookups that return Octura pages, Odoo pricing and competitor comparisons to cite.
Endpoint: https://octurasolutions.com/mcp (streamable HTTP)
Registry: com.octurasolutions/site-tools
Nothing to install and no API key. It is a remote server, so you point your client at the URL.
Every calculator is a pure function: same inputs, same outputs, no model in the loop and no randomness. Asking a language model to compute a payback period or a Quebec QST total invites a plausible-looking wrong number. These return the arithmetic instead, along with the inputs they used, so the result can be checked.
The trade-off is that they are calculators, not advice. They do not know your business, and the cost models carry assumptions (regional rates, blended hourly costs) that a real quote would replace.
Related MCP server: macalc
Claude Code:
claude mcp add --transport http octura https://octurasolutions.com/mcpAny client that reads a JSON config:
{
"mcpServers": {
"octura": {
"type": "streamable-http",
"url": "https://octurasolutions.com/mcp"
}
}
}The server is stateless and tools-only. It implements initialize, ping, tools/list and
tools/call; it advertises no resources and no prompts.
Most clients handle remote HTTP directly and should use the config above. For older ones that only support stdio, this repo ships a bridge:
npx -y github:Octura-solutions/octura-mcp-server{
"mcpServers": {
"octura": {
"command": "npx",
"args": ["-y", "github:Octura-solutions/octura-mcp-server"]
}
}
}Or with Docker, docker build -t octura-mcp . && docker run -i --rm octura-mcp.
Python clients can install it from PyPI instead:
uvx octura-mcp-server{
"mcpServers": {
"octura": {
"command": "uvx",
"args": ["octura-mcp-server"]
}
}
}The Node bridge runs from this repo rather than an npm package name, because it is not published to npm; the Python one is on PyPI. Both are the same pipe with the same behaviour, verified by the same eight tests in each language. Pick whichever runtime your client already has.
The bridge is a pipe: it POSTs whatever arrives on stdin to the endpoint and writes the reply
back. It has no dependencies and it does not restate the tool list or any schema, so it cannot
drift out of sync with the server. Point it elsewhere with OCTURA_MCP_URL.
curl -s -X POST https://octurasolutions.com/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
"name":"odoo-roi-calculator",
"arguments":{"currentAnnualCost":60000,"odooAnnualCost":18000,
"implementationCost":45000,"annualEfficiencySavings":30000}}}'The text content is JSON, echoing the input alongside the result:
{
"tool": "odoo-roi-calculator",
"input": {
"currentAnnualCost": 60000,
"odooAnnualCost": 18000,
"implementationCost": 45000,
"annualEfficiencySavings": 30000
},
"result": {
"annualNetSavings": 72000,
"paybackMonths": 7.5,
"threeYearNet": 171000,
"threeYearRoiPercent": 380
}
}Every input has a documented default, so a tool called with {} still returns a sensible
baseline rather than an error.
Each one also exists as an interactive page, which is the easiest way to see what a tool expects before wiring it up.
Tool | What it returns |
Estimate your Odoo implementation budget | |
Estimate the cost to migrate to Odoo | |
Budget an Odoo version upgrade | |
Model the multi-year total cost of Odoo | |
Estimate payback and multi-year ROI of Odoo | |
Estimate your Odoo.sh hosting cost | |
See what consolidating tools into Odoo saves | |
Estimate EDI integration cost in Odoo | |
Find the Odoo apps your business needs | |
Score your best-fit ERP shortlist across 10 systems | |
Tune odoo.conf workers and memory limits | |
Grade how badly an in-flight Odoo implementation is going |
Tool | What it returns |
State sales tax for all 50 states and DC | |
See where you must collect US sales tax | |
GST, HST, PST and QST for all provinces | |
VAT rates by country plus VIES validation | |
CPP, EI and income tax source deductions |
Tool | What it returns |
Turnover ratio and days of inventory | |
When to reorder, with safety stock | |
Buffer stock for demand and lead-time swings | |
Optimal order quantity to minimize cost | |
Annual cost of holding inventory | |
True per-unit cost including freight and duty | |
Convert between margin, markup and price | |
Overall Equipment Effectiveness for production |
These are lookups rather than calculators. They return pages and facts from octurasolutions.com so a model can answer with a source to cite instead of from memory.
Tool | What it returns |
| The most relevant site pages for an Odoo or ERP question, with URLs |
| Head-to-head comparison of Odoo against one of 60 competitors |
| Odoo apps and modules that fit a business need in plain language |
| Current Odoo license list pricing and Odoo.sh hosting rates |
| Who Octura Solutions is: partner status, regions, services, contact |
For catalogs, plugin loaders and anything else that wants the API described without speaking MCP first, the repo carries three files:
File | What it is |
The | |
OpenAPI 3.1 for the endpoint, with a typed request schema per tool | |
Plugin manifest pointing at the OpenAPI document |
The first two are generated from the live endpoint by npm run discovery, so they are a
snapshot rather than a second source of truth: if they disagree with the server, the server is
right and the fix is to rerun the script. npm test checks that the three files agree with each
other.
Rate limited per IP. Read X-RateLimit-Limit and X-RateLimit-Remaining on the response rather
than hard-coding a number, since the ceiling can change. Over the limit returns HTTP 429 with a
Retry-After header.
Tax rates and payroll figures are maintained on a best-effort basis and are not a substitute for filing advice from an accountant.
This repo is the public home of the server: this README, a copy of the published server.json
registry manifest, the machine-readable descriptions above, and the stdio bridge. The calculators themselves run inside
the Octura Solutions website, whose source is private, so what you can build and run here is
the bridge rather than the tools.
Run the bridge's tests with npm test. They use a local stand-in for the endpoint, so they
pass with no network access.
Details on the server, including the full tool list with input schemas, are at octurasolutions.com/tools/mcp-server.
Found a wrong number or a tool that errors? Open an issue.
MIT, see LICENSE. This covers the contents of this repository. The hosted service is offered as-is under the terms on the website.
CPP, EI, and income tax source deductions.
| Name | Required | Description | Default |
|---|---|---|---|
| eiExempt | No | ||
| province | No | ON | |
| cppExempt | No | ||
| payFrequency | No | ||
| grossPerPeriod | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the subject matter (CPP, EI, income tax) and gives no insight into how calculations work, what inputs affect what, or any side effects or output format.
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 extremely brief, almost a fragment. While it avoids fluff, it under-specifies and does not provide enough structured information to aid an agent in understanding the tool.
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 5 parameters, no parameter descriptions, and no output schema, the description is inadequate. It provides no context about how to use the tool, what results to expect, or how the inputs map to the outputs.
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 has zero descriptions for its 5 parameters, and the description does not mention any parameter names or meanings. An agent cannot infer the purpose of eiExempt, cppExempt, payFrequency, or grossPerPeriod from the description alone.
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 identifies the tool as computing Canadian payroll source deductions for CPP, EI, and income tax. It distinguishes itself from sibling calculators like sales tax or inventory tools, though it lacks an explicit verb like 'calculates'.
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 gives no guidance on when to use this tool versus alternatives such as canadian-sales-tax-calculator or us-sales-tax-calculator. There are no exclusions, prerequisites, or contextual hints beyond the tool's name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GST, HST, PST, and QST for all provinces.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Pre-tax in add mode, tax-included total in extract mode (CAD). | |
| province | No | ON | |
| direction | No | add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only lists tax types and provinces, but does not explain how the calculation works, what the output represents, whether direction affects results, or any rounding/tax-inclusion behavior. It implies a simple calculation with no side effects, but does not confirm or clarify key behavioral aspects.
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 extremely concise, consisting of a single noun phrase with no filler words. However, it is structurally incomplete: it is not a full sentence and lacks any breakdown of functionality. While every word earns its place, the description is under-specified, so it earns a middle score for conciseness rather than higher for thoroughness.
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?
The tool has 3 parameters, no output schema, and no annotations, so the description must be relatively comprehensive. The one-line description is insufficient to allow correct invocation: it does not explain how the 'direction' parameter alters the calculation, how tax rates differ by province, or what the return format looks like. This is a significant gap for an agent attempting to use the tool properly.
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 only 33% (only 'amount' has a description). The tool description adds no parameter meaning—it does not explain the province codes, the 'direction' enum (add vs extract), or how the amount is interpreted. This is a critical gap because the schema leaves most parameters underspecified, and the description fails to compensate.
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 'GST, HST, PST, and QST for all provinces' clearly identifies the tool as a Canadian sales tax calculator, covering key tax types and all provinces. It distinguishes itself from sibling calculators like us-sales-tax-calculator and eu-vat-calculator by explicitly naming Canadian tax components. However, it lacks an explicit verb like 'calculates', making it slightly less direct than ideal.
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 no guidance on when to use this tool versus alternatives, such as US or EU sales tax calculators. It does not state that this tool is for Canadian transactions only, nor does it mention any exclusions or prerequisites. The sibling tool list is provided, but the description itself offers no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimal order quantity to minimize cost.
| Name | Required | Description | Default |
|---|---|---|---|
| orderCost | No | ||
| annualDemand | No | ||
| holdingCostPerUnit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It lacks details about output format, calculation assumptions (e.g., constant demand), or side effects, leaving the agent without critical behavioral context.
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 extremely short, but it is under-specified rather than concise. It fails to provide necessary context while being easy to read.
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 absence of annotations and output schema, the description is highly insufficient. It covers only the basic purpose and omits input requirements, assumptions, and return behavior, making it inadequate for correct tool invocation.
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 has 0% description coverage for the three parameters, and the description does not mention any of them. The agent gets no help understanding how to set orderCost, annualDemand, or holdingCostPerUnit.
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 computes the optimal order quantity to minimize cost, which identifies the EOQ calculation. However, it does not directly distinguish itself from related inventory calculators such as reorder-point-calculator or safety-stock-calculator, but the purpose is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives like reorder-point-calculator or inventory-carrying-cost-calculator. The description does not provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score your best-fit ERP shortlist across 10 systems.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | mid | |
| needs | No | ||
| budget | No | moderate | |
| region | No | us | |
| industry | No | manufacturing | |
| incumbent | No | quickbooks | |
| deployment | No | either | |
| customization | No | some |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states only the high-level scoring action but does not disclose how scoring works, what the output looks like, what assumptions are made, or any side effects. This is a substantial gap for a tool with no annotation support.
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 single-sentence description is concise and front-loaded, but it is under-specified. While not verbose, it sacrifices necessary detail, making it minimally adequate rather than well-structured.
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?
With 8 parameters, no annotations, and no output schema, the description is severely incomplete. It neither explains the scoring logic, the meaning of parameters in context, nor what return value the agent can expect. This is inadequate for effective tool selection and invocation.
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 0%, and the description provides no parameter information whatsoever. All 8 parameters (with enums and defaults) are left entirely to the schema, so the description adds zero semantic value beyond the structured fields.
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 uses the specific verb 'Score' and names the resource ('your best-fit ERP shortlist across 10 systems'), clearly indicating this tool evaluates and ranks ERP options. It is distinct from sibling tools, which are calculators, so the purpose is unambiguous.
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 context of selecting an ERP is implied by the title and description, but there is no explicit statement about when to use this tool versus other calculators or the odoo-specific tools. No exclusions or alternative tools are mentioned, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
VAT rates by country plus VIES validation.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Net amount in add mode, gross (VAT-included) total in extract mode. | |
| country | No | ISO alpha-2 country code (EU-27 + GB; GR for Greece). | FR |
| direction | No | add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention network calls for VIES validation, return formats, side effects, or limitations. The phrase 'VIES validation' is unexplained, leaving the agent unaware of what the tool actually does beyond a vague summary.
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 extremely short but is a fragment without a main verb, not a well-structured sentence. It under-specifies rather than being efficiently concise, omitting essential information about functionality and usage.
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 3 parameters and no output schema, the description is wholly insufficient. It does not indicate what the tool returns, how VIES validation is performed, or how errors are handled. The agent cannot determine whether to use this tool or how to interpret results from this description alone.
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 description adds no information about the parameters 'amount', 'country', or 'direction'. Schema coverage is 67% (amount and country have descriptions, direction does not), but the description does not compensate for the missing direction semantics or clarify how the add/extract modes work. It repeats no schema detail and adds negligible 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 'VAT rates by country plus VIES validation' is a noun phrase without an explicit verb. It does not clearly state that the tool calculates VAT (e.g., adds or extracts) on amounts; it could be interpreted as a lookup. It vaguely distinguishes from siblings but fails to convey the core calculator behavior.
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?
No guidance is provided on when to use this tool versus the many sibling calculators (e.g., canadian-sales-tax-calculator, us-sales-tax-calculator). It does not mention use cases, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annual cost of holding inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| avgInventoryValue | No | ||
| carryingRatePercent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It does not mention that this is a pure calculation, what the output represents, any limitations, or assumptions. It merely defines the concept of carrying cost.
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 extremely short, but it is an incomplete sentence fragment rather than a concise, well-structured statement. Brevity here is under-specification, not effective conciseness, as it omits critical action and context.
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?
For a tool with no annotations, no output schema, and only two parameters, the description must provide full context to be useful. It fails to explain the formula, the return value, or when to apply it, leaving the agent with almost no actionable information.
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 0%, and the description does not explain the two parameters (avgInventoryValue, carryingRatePercent) or how they combine to produce the result. It adds no semantic value beyond the parameter names and defaults already visible in 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 'Annual cost of holding inventory' is a noun phrase that restates the tool's name without an explicit verb like 'calculate' or 'compute'. It does not clearly state what action the tool performs, making it close to a tautology.
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?
There is no guidance on when to use this tool versus the many sibling inventory calculators (e.g., inventory-turnover-calculator, reorder-point-calculator, economic-order-quantity-calculator). No context, prerequisites, or alternative distinctions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turnover ratio and days of inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| annualCOGS | No | ||
| avgInventoryValue | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose behavior such as being a read-only calculation, how inputs are used, or return format. It merely names outputs, which is insufficient for behavioral transparency.
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 extremely brief (six words) and front-loaded with key output terms. However, it is under-specified—there is no sentence structure or practical detail, making it more terse than useful.
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?
For a tool with no annotations, no output schema, and no parameter descriptions, the description is incomplete. It fails to mention the formula, parameter relationships, assumptions, or why a user would choose this calculator over related inventory tools.
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 0%, and the description does not explain annualCOGS or avgInventoryValue. The parameter names are self-explanatory to finance-savvy users, but the description adds no meaning beyond the schema, failing to compensate for the coverage gap.
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 identifies the tool's output (turnover ratio and days of inventory) and the name/title clarifies it's a calculator. However, it lacks an explicit verb like 'calculates,' making it slightly less direct, though it still distinguishes from sibling inventory calculators.
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?
No guidance is provided on when to use this tool instead of sibling calculators (e.g., reorder-point-calculator, safety-stock-calculator). The description only states the output subject matter, with no context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
True per-unit cost including freight and duty.
| Name | Required | Description | Default |
|---|---|---|---|
| freight | No | ||
| quantity | No | ||
| insurance | No | ||
| otherFees | No | ||
| customsDuty | No | ||
| productCost | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the output type ('true per-unit cost') and does not disclose the calculation formula, assumptions, or that it is a side-effect-free deterministic calculation.
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 a single front-loaded sentence with no wasted words. It is efficient, though the word 'True' adds little substance and the brevity contributes to under-specification in other dimensions.
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 six parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain the formula, what output the agent should expect (e.g., a number), or whether all costs are divided by quantity.
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?
While 'per-unit' and 'including freight and duty' hint that costs are aggregated and divided by quantity, the description does not mention insurance, otherFees, productCost, or the role of quantity, leaving most of the six parameters undocumented despite 0% schema description coverage.
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 identifies the tool's purpose as computing true per-unit cost including freight and duty, which distinguishes it from sibling calculators such as reorder-point-calculator. However, it lacks a direct verb and does not explicitly state that it calculates, relying on the title and noun phrase.
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 no explicit guidance on when to use this tool versus alternatives. It neither names sibling calculators nor states when not to use it, leaving the usage context implied solely by the name and phrase 'freight and duty.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between margin, markup, and price.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | ||
| mode | No | fromPrice | |
| price | No | ||
| targetMarginPercent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the conversion function, but does not explain the two modes, how inputs relate, or any expectations about inputs and outputs. This leaves the user uncertain about operational details.
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 a single, direct sentence that uses an active verb and communicates the core function efficiently. It is front-loaded and contains no filler.
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?
With four parameters, an enum mode, no output schema, and no annotations, the description is far too minimal. It does not explain calculation logic, mode semantics, or expected output format, making it incomplete for practical use.
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 0%, so the description must compensate. It mentions margin, markup, and price, which loosely map to cost, price, and targetMarginPercent, but it does not explain the role of each parameter or the meaning of the mode enum. Thus it adds minimal semantic 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 converts between margin, markup, and price. This is a specific verb and resource, and it distinguishes from sibling calculators which handle different financial metrics.
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 no guidance on when to use this tool versus the other calculators, nor any exclusions or alternatives. There is no mention of prerequisite conditions or target scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the Odoo apps your business needs.
| Name | Required | Description | Default |
|---|---|---|---|
| needs | No | ||
| users | No | ||
| businessType | No | services |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only restates the general purpose and gives no hints about side effects, output format, or limitations. An agent cannot anticipate whether this is a read-only recommendation tool or something more.
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 a single, compact sentence with no wasted words. It is front-loaded with the core purpose. However, the brevity sacrifices essential detail, so it is concise but under-specified.
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?
With three parameters, no annotations, and no output schema, the description is far too thin. It fails to explain inputs, expected outputs, or behavioral context. An agent invoking this tool would have minimal understanding of what is required or returned.
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 0%, and the description does not compensate. It never mentions the parameters (needs, users, businessType) or how they influence results. The phrase 'your business needs' vaguely hints at the 'needs' array but provides no detail on usage or constraints.
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 uses a clear verb ('Find') and identifies the resource ('Odoo apps') and the user's need ('your business needs'). This is distinct from the calculator siblings, which focus on numeric computations. However, it doesn't specify the output form (e.g., recommendations) or differentiate beyond the basic purpose.
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 no guidance on when to use this tool versus alternatives. It doesn't mention alternatives or exclusion criteria. The name implies its role as an app selector, but the description itself offers no context for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tune odoo.conf workers and memory limits.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | production | |
| version | No | ||
| cpuCores | No | ||
| proxyMode | No | ||
| totalRamMb | No | ||
| concurrentUsers | No | ||
| sharedWithPostgres | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action ('tune') without explaining whether it modifies the file in place, outputs values, or requires permissions. The mention of 'workers and memory limits' gives a slight hint but is insufficient.
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 one short sentence, which is concise in length but severely under-specified for a tool with 7 parameters. It lacks necessary details, making it more of an under-specification than an appropriately sized description.
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?
With 7 parameters, no annotations, no output schema, and 0% schema description coverage, this tool demands rich context. The description provides no information about the expected output, how inputs are used, or what 'tuning' entails, making it incomplete for an agent to use 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 description coverage is 0%, so the description had to compensate by explaining parameters. It does not mention any of the 7 parameters (profile, version, cpuCores, etc.) or their meanings. The only hint, 'workers and memory limits', is too vague to understand the role of parameters like concurrentUsers or sharedWithPostgres.
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 function with a specific verb 'Tune' and a specific resource 'odoo.conf workers and memory limits'. This distinguishes it from the sibling tools, which are primarily calculators and selectors, making the purpose unambiguous.
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 no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It does not mention any context or scenarios, leaving the agent without direction on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate EDI integration cost in Odoo.
| Name | Required | Description | Default |
|---|---|---|---|
| system | No | odooLive | |
| volume | No | 500to2k | |
| retailers | No | ||
| translator | No | undecided | |
| catalogue832 | No | ||
| ssccLabelling | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the purpose without revealing how the estimation works, whether it is a read-only calculation, what input assumptions are made, or what the output format is. For a cost estimator, this lack of transparency leaves the agent uncertain about side effects and return values.
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 a single concise sentence with no fluff, but it is under-specified. It achieves brevity at the cost of omitting essential usage and parameter information. While every word earns its place, the lack of structured elaboration makes it minimally acceptable rather than well-structured.
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?
This is a calculator tool with 6 parameters, no annotations, and no output schema. The description provides no information about what influences the cost estimate, what the output represents, or how parameters interact. It is completely inadequate for an agent to understand the tool's full behavior, leaving major gaps in contextual understanding.
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 has 0% description coverage across 6 parameters, and the description does not mention any of them. Since the description must compensate for low schema coverage, this is a critical gap. The agent gets no semantic context for parameters like 'system', 'volume', 'retailers', or 'translator', making it difficult to fill them correctly.
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 function: 'Estimate EDI integration cost in Odoo.' It uses a specific verb (estimate) and resource (EDI integration cost) within the Odoo context, which distinguishes it from generic cost calculators. However, it does not explicitly differentiate from sibling calculators like implementation or migration cost estimators beyond the EDI specificity, which is reasonably clear but could be more explicit.
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?
There is no guidance on when to use this tool versus alternatives. The description lacks any context about scenarios that would call for EDI cost estimation, prerequisites, or exclusions. Given the list of sibling calculators, the description provides no help in selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate your Odoo implementation budget.
| Name | Required | Description | Default |
|---|---|---|---|
| userCount | No | ||
| complexity | No | moderate | |
| moduleCount | No | ||
| customization | No | light |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only states that the tool estimates a budget, without disclosing what factors influence the estimate, whether it returns a range, or any limitations.
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 single sentence is concise and front-loaded, but it is under-specified and lacks any structural elements like steps or parameter mentions. It is not wasteful, yet it fails to earn its place by providing necessary context.
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?
For a tool with four parameters and no output schema, the description is incomplete. It does not clarify the output format, how to interpret the estimate, or what the calculation is based on, making it insufficient for correct invocation.
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 0%, and the description does not compensate. It mentions none of the four parameters (userCount, complexity, moduleCount, customization) or how they affect the budget, leaving all semantics to the schema alone.
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 uses a specific verb 'Estimate' and resource 'Odoo implementation budget', clearly stating what the tool does. It is specific enough to distinguish from many sibling calculators, although it does not explicitly differentiate from the total-cost-of-ownership calculator.
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?
No guidance is provided on when to use this tool versus alternative Odoo cost calculators. It does not mention scenarios, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the cost to migrate to Odoo.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | 3-7 | |
| source | No | netsuite | |
| volume | No | m | |
| quality | No | typical | |
| userCount | No | ||
| complexity | No | moderate | |
| moduleCount | No | ||
| integrations | No | 1-2 | |
| customization | No | light | |
| customsToPort | No | 1-3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it discloses no behavioral traits. It doesn't mention assumptions, pricing model, output format, or any side effects. The tool is a complete black box.
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 extremely short (one sentence), which is concise in word count, but it is under-specified rather than optimally concise. Given the complexity of the tool (10 parameters, no output schema), this is not 'appropriately sized' – it lacks essential structure and detail.
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?
This is a 10-parameter tool with no annotations, no output schema, and 0% schema coverage. The description provides only a one-line purpose, severely under-selling the tool's complexity. It is completely inadequate for an agent to invoke the tool correctly with suitable inputs.
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 0% and the description adds no meaning to any of the 10 parameters. All parameters (like years, source, volume) are left entirely to the schema enum names, which are insufficient for correct usage. The description fails to compensate for the lack of schema documentation.
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 'Estimate the cost to migrate to Odoo' clearly states the action (estimate) and the resource (cost to migrate to Odoo). It distinguishes this tool from similar siblings like implementation cost or upgrade cost calculators through the word 'migrate'. However, it lacks specificity about what aspects of migration are included.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. Sibling tool names imply alternatives but the description provides no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate payback and multi-year ROI of Odoo.
| Name | Required | Description | Default |
|---|---|---|---|
| odooAnnualCost | No | ||
| currentAnnualCost | No | ||
| implementationCost | No | ||
| annualEfficiencySavings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Estimate,' which is vague and does not clarify that this is a non-destructive calculation, what assumptions it makes, or what the output format is. There is no mention of side effects, data handling, or limitations.
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 a single, front-loaded sentence with no extraneous words. It states the core purpose clearly and is appropriately concise for the amount of information it contains.
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?
The tool has no output schema, no annotations, and four parameters, yet the description only provides a one-line summary. It does not explain what the tool returns, how to interpret the output, or any contextual details needed to use it effectively. For a calculator with multiple inputs, this is insufficient.
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 0% and the description does not compensate. It fails to explain any of the four parameters (e.g., odooAnnualCost, currentAnnualCost, implementationCost, annualEfficiencySavings) or how they contribute to the ROI calculation. The parameter names are self-explanatory, but the description adds no semantic meaning 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 'Estimate payback and multi-year ROI of Odoo' clearly states the tool's purpose with a specific verb ('estimate') and resource ('payback and multi-year ROI of Odoo'). This distinguishes it from sibling tools like the TCO or implementation cost calculators, which focus on different financial metrics.
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 no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or context such as 'Use when you need ROI projections.' The single sentence offers only the basic function without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate your Odoo.sh hosting cost.
| Name | Required | Description | Default |
|---|---|---|---|
| billing | No | monthly | |
| version | No | ||
| appsBand | No | medium | |
| namedUsers | No | ||
| workerChoice | No | auto | |
| peakConcurrency | No | ||
| stagingBranches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'estimate' but does not describe return format, assumptions, or side effects. As a calculator, it likely performs a read-only computation, but this is not stated.
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 a single concise sentence that earns its place, but it is under-specified. While not verbose, it lacks structure and additional context expected for a tool with 7 parameters.
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?
The description is completely inadequate for a tool with 7 parameters, no annotations, and no output schema. It provides only a high-level purpose and does not explain its operation, inputs, or outputs.
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 0% and the description does not mention any of the 7 parameters. It fails to compensate for the lack of parameter descriptions, leaving the agent without guidance on what inputs mean.
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 estimates Odoo.sh hosting cost with a specific verb and resource. However, it does not explicitly differentiate from sibling calculators like implementation or migration cost, though the resource itself is distinct.
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?
No guidance is provided on when to use this tool versus alternatives. The description only gives a basic purpose statement and does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See what consolidating tools into Odoo saves.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | ||
| selected | No | Competitor tool slugs being consolidated; unknown slugs are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It does not mention that the tool is a read-only calculation, the meaning of the inputs, or the output format. The phrase 'See what... saves' implies a result but not how it's produced.
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 a single 8-word sentence, making it concise and free of fluff. However, it is under-specified to the point of being a tagline rather than a functional description.
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?
For a tool with two parameters, no output schema, and no annotations, the description is incomplete. It does not define the input semantics, the nature of the result, or how this calculator differs from its many siblings. The schema partially covers 'selected' but the overall tool usage remains unclear.
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 covers 50% of parameters (selected has a description; users does not). The description adds nothing about parameters. It does not explain what 'users' represents (likely seat count for pricing) or how 'selected' interacts with the calculation. The default values and constraints are in the schema, but the semantic meaning is missing.
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 uses the vague verb 'see' rather than 'calculate' or 'estimate', and frames the tool as a value proposition rather than a clear function. It does mention the resource (consolidating tools into Odoo) and differentiates from sibling cost calculators by focusing on savings, but the phrasing is imprecise.
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 no explicit guidance on when to use this tool versus other Odoo calculators in the sibling set (e.g., odoo-roi-calculator, odoo-total-cost-of-ownership-calculator). There are no exclusions, prerequisites, or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Model the multi-year total cost of Odoo.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | custom | |
| users | No | ||
| hosting | No | odoosh-standard | |
| support | No | essential | |
| training | No | essentials | |
| implScale | No | growth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only says 'model' without disclosing what the tool returns, how it computes costs, whether it is read-only, or any assumptions. This is a significant gap for a calculator with multiple configurable inputs.
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 a single short sentence, which is concise but not appropriately sized for a tool with six parameters and no annotations. It under-specifies rather than efficiently conveying necessary information, similar to a placeholder.
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?
The tool has six parameters, no output schema, and no annotations. The description provides only a vague purpose and no information on inputs, outputs, or usage context, making it incomplete for an agent to invoke the tool 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 description coverage is 0%, and the description does not compensate by explaining any parameters. It does not mention plan, users, hosting, support, training, or implementation scale, leaving the agent with only parameter names and enum values to infer meaning.
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 states a clear purpose: 'Model the multi-year total cost of Odoo.' It identifies the resource (Odoo) and the scope (multi-year total cost), which is enough to distinguish the tool's general function from single-cost calculators. However, it does not explicitly name any cost components or differentiate it from sibling tools like the implementation cost calculator.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, exclusions, or sibling tools, leaving the agent without criteria for selecting this calculator over other Odoo cost-related calculators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Budget an Odoo version upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
| dbSize | No | m | |
| downtime | No | weekend | |
| ocaModules | No | few | |
| customModules | No | 1-3 | |
| sourceVersion | No | ||
| targetVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the purpose and gives no indication of how the budget is calculated, what factors affect the estimate, what output to expect, or any assumptions. This lack of transparency is a significant gap for a calculator with multiple input parameters.
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 a single short sentence, which is concise in word count, but it is severely under-specified. It lacks the additional structure and detail needed to be appropriately sized for the tool's complexity. The brevity is closer to the 'Process' example than to a well-structured description, earning a low score.
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 complexity (six parameters, no output schema, no annotations), the description is woefully incomplete. It does not state the return format (e.g., a cost estimate), explain how the parameters influence the budget, or provide any usage examples. The description provides almost no practical context for an agent to invoke the tool 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?
The schema has six parameters with 0% description coverage, and the description does not mention any of them. It fails to explain the meaning of dbSize, downtime, ocaModules, customModules, sourceVersion, or targetVersion, leaving the agent without any semantic context for selecting correct values. This is a complete failure to compensate for the schema gap.
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 uses a clear verb-noun structure: 'Budget' (meaning estimate cost) and 'Odoo version upgrade' as the resource. It states the tool's primary function clearly. However, it does not explicitly differentiate this calculator from sibling tools like odoo-migration-cost-calculator or odoo-implementation-cost-calculator, which could overlap in scope, so it stops short of a 5.
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 no guidance on when to use this tool versus alternatives such as odoo-migration-cost-calculator or odoo-total-cost-of-ownership-calculator. It does not mention any use cases, prerequisites, or exclusions. The agent is left without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overall Equipment Effectiveness for production.
| Name | Required | Description | Default |
|---|---|---|---|
| goodUnits | No | ||
| totalUnits | No | ||
| downtimeMin | No | ||
| idealCycleTimeSec | No | ||
| plannedProductionTimeMin | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. The single phrase 'Overall Equipment Effectiveness for production' gives no information about inputs, calculation method, return values, or side effects. It fails to disclose any 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 extremely concise, with no wasted words, but it is under-specified. A single noun phrase does not provide enough structure to be effective, making it closer to a label than a helpful description.
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?
For a calculator tool with five parameters, no output schema, and no annotations, the description is drastically incomplete. It does not explain the OEE formula, the meaning/units of parameters, or the returned result, leaving the agent without sufficient context to invoke the tool 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 description coverage is 0% and the tool description does not mention any of the five parameters. The parameter names like 'goodUnits' and 'downtimeMin' are somewhat self-explanatory, but the description adds no meaning beyond the input schema and fails to compensate for the total lack of parameter descriptions.
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 'Overall Equipment Effectiveness for production' identifies the domain metric but lacks an explicit verb like 'calculate' or 'compute'. It is clearer than a tautology but does not clearly state the action or distinguish from sibling calculators beyond context.
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 no guidance on when to use this tool versus alternatives. It does not mention specific scenarios, prerequisites, or contrast with any sibling tools, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When to reorder, with safety stock.
| Name | Required | Description | Default |
|---|---|---|---|
| safetyStock | No | ||
| leadTimeDays | No | ||
| avgDailyUsage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'When to reorder, with safety stock.' without explaining what the tool computes, returns, or any side effects. It's not misleading but severely under-discloses.
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 extremely short, but this is under-specification rather than effective conciseness. The phrase 'When to reorder, with safety stock.' doesn't earn its place because it omits critical information and is not well-structured for agent consumption.
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 3 parameters, no output schema, and no annotations, the description is completely inadequate. It doesn't explain what the reorder point is, how it's calculated, what the output represents, or how it differs from closely related calculators, leaving the agent without essential context.
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 three numeric parameters with 0% description coverage, and the tool description only mentions 'safety stock'. It fails to explain leadTimeDays or avgDailyUsage, how they relate, or the calculation formula, adding no meaningful parameter-level detail.
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 'When to reorder, with safety stock.' is a vague fragment that doesn't explicitly state the tool calculates a reorder point. It lacks a clear verb like 'calculates' or 'computes' and doesn't distinguish itself from sibling tools such as safety-stock-calculator.
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?
No guidance is provided on when to use this tool versus the many sibling calculators (e.g., safety-stock-calculator, economic-order-quantity-calculator). The description offers no context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buffer stock for demand and lead-time swings.
| Name | Required | Description | Default |
|---|---|---|---|
| avgDailyUsage | No | ||
| maxDailyUsage | No | ||
| avgLeadTimeDays | No | ||
| maxLeadTimeDays | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only calculation, what formula is used, what the output represents, or any assumptions like normal distribution of demand. The description merely restates the concept without clarifying tool behavior.
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 only six words, which is concise, but it is under-specified rather than efficiently structured. It does not earn its place because it adds little beyond the tool's name and title, providing no actionable guidance for the agent.
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?
This is a calculator tool with four parameters and no output schema, yet the description provides no formula, example, or explanation of the result. It is significantly incomplete for an agent to select and invoke the tool correctly, especially given the existence of several closely related inventory calculators.
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 0%, and the description adds no meaning to the four parameters (avgDailyUsage, maxDailyUsage, avgLeadTimeDays, maxLeadTimeDays). The description does not explain how these inputs relate to safety stock, leaving the agent to infer the formula and units entirely from parameter names.
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 'Buffer stock for demand and lead-time swings' identifies the domain (safety stock) and key inputs (demand, lead time), but lacks an explicit verb like 'calculates' and does not clearly differentiate it from sibling tools like reorder-point-calculator. It is more of a concept definition than a tool purpose statement.
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?
No guidance is provided on when to use this tool versus alternatives such as reorder-point-calculator or economic-order-quantity-calculator. The description implies use for buffer stock planning but offers no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
State sales tax for all 50 states and DC.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state code (e.g. CA, TX, NY). | CA |
| amount | No | Pre-tax amount in add mode, tax-included total in extract mode (USD). | |
| direction | No | add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain that the tool supports add/extract modes, how the amount parameter behaves differently in each mode, or what the return value looks like. The description is too shallow to inform the agent about side effects, rounding, or other behavioral nuances.
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 extremely short, which is concise, but it is a fragment rather than a complete sentence. It has no wasted words, but it sacrifices clarity for brevity. It is not structured to front-load key information because it is barely structured at all.
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 lack of output schema and annotations, the description should explain what the tool returns (e.g., tax amount, total, or both) and possibly mention the direction modes. The current description only states scope, leaving the agent without enough context to anticipate the tool's full behavior. The presence of sibling calculators makes this gap more significant.
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 description adds no parameter-level information. Schema coverage is 67%, with 'state' and 'amount' having descriptions and 'direction' only having an enum without explanation. The description does not compensate for the missing direction semantics, such as explaining how 'add' vs 'extract' affects the calculation, leaving the agent to infer from parameter names.
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 identifies the resource (state sales tax) and the geographic scope (all 50 states and DC), distinguishing it from sibling tools like canadian-sales-tax-calculator and us-sales-tax-nexus-checker. However, it lacks an explicit verb like 'Calculate', making it a noun phrase rather than a full statement of the tool's action.
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 no guidance on when to use this tool versus alternatives. It does not mention US-only applicability explicitly (though implied by the name and 'all 50 states'), nor does it suggest when to use e.g. canadian-sales-tax-calculator instead. No exclusions or alternative scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See where you must collect US sales tax.
| Name | Required | Description | Default |
|---|---|---|---|
| sales | No | Annual sales into the state, USD. | |
| state | No | Two-letter US state code (e.g. CA, TX, NY). | CA |
| transactions | No | Annual transaction count into the state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states a high-level outcome and gives no details on what inputs are used, what thresholds apply, or what the tool returns (e.g., a list of states, a boolean, or a threshold comparison).
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 extremely short, but that brevity comes at the cost of usefulness. It doesn't provide actionable guidance, making it under-specification rather than efficient 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 complexity of US economic nexus rules and the lack of an output schema or annotations, the description is inadequate. It doesn't mention the threshold logic, the role of transactions count, or how results are presented.
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 describes all three parameters (sales, state, transactions) with clear semantics and ranges. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 states the resource ('US sales tax') and implies an outcome ('where you must collect'), but uses the vague verb 'see' instead of a specific action like 'determine' or 'check'. It doesn't distinguish from siblings like us-sales-tax-calculator, which also relates to US sales tax.
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?
No guidance on when to use this tool versus alternatives. It doesn't mention that this checks economic nexus thresholds vs calculating tax amounts, nor does it clarify prerequisites like annual sales/transactions data.
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.
v1.0.0canadian-payroll-source-deductions-calculatorcanadian-sales-tax-calculatoreconomic-order-quantity-calculatorerp-selection-tooleu-vat-calculatorinventory-carrying-cost-calculatorinventory-turnover-calculatorlanded-cost-calculatormargin-and-markup-calculatorodoo-app-selectorodoo-conf-tunerodoo-edi-readiness-cost-estimatorodoo-implementation-cost-calculatorodoo-migration-cost-calculatorodoo-roi-calculatorodoo-sh-pricing-calculatorodoo-stack-savings-calculatorodoo-total-cost-of-ownership-calculatorodoo-upgrade-cost-calculatoroee-calculatorreorder-point-calculatorsafety-stock-calculatorus-sales-tax-calculatorus-sales-tax-nexus-checkerScored across 24 tools
Each calculator targets a distinct formula or decision, but the large cluster of Odoo cost estimators (TCO, implementation, ROI, etc.) could cause some selection hesitation. Descriptions are clear enough to differentiate them, so ambiguity is low but not entirely absent.
Most tools follow a consistent lowercase-hyphenated descriptive pattern ending in '-calculator'. However, a few use '-checker', '-tuner', '-selector', or '-tool', which is a minor inconsistency, though the overall naming remains predictable and readable.
With 24 tools, the count sits at the high end of a coherent set, but the diversity of domains (inventory, tax, Odoo, payroll, ERP) justifies each tool's existence. The scope is broad but each tool earns its place as a distinct calculator.
The toolset covers a wide range of business operations, with especially strong coverage of inventory management and Odoo cost analysis. Minor gaps exist (e.g., no general-purpose tax calculator, US payroll missing), but the core surface for the apparent purpose is largely complete.
Deterministic Odoo ERP calculators: implementation cost, ROI, TCO, tax, payroll, inventory.
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
# TrueCalci Precision Compute Engine Deterministic statutory, financial, and engineering computational tools for AI agents, developers, and autonomous workflows over the Model Context Protocol (MCP). ### Capabilities (25 Verified Engines): - **Specialist FinOps:** Remote Contractor vs. W-2 Parity, S-Corp Reasonable Compensation (IRS Rev. Rul. 74-44), Solo 401(k) Shelter, Cross-Border FX Drag, Billable Capacity Floor. - **Global & Cross-Border Tax:** US Form 2555 FEIE Nomad Stacking, B2B Foreign
5,400+ manufacturing calculators plus live U.S. tariff, PMI, cost-index, wage, and forecast data.
