stub

Update entity salestax

update_entity_salestax

Update an existing sales tax already on an entity. To add a new sales tax use add_entity_salestax (one entity), add_entity_salestaxes (several taxes on one entity), or add_salestax_to_entities (one tax across many entities).

Input Schema

Name	Required	Description
`id`	Yes	Id of the sales tax to update.
`kind`	No	"salestax" \| "levy" \| "withholding"; "$delete" clears it.
`name`	No	Display name of the sales tax (e.g. "VAT").
`rate`	No	Sales tax rate as a DECIMAL FRACTION, e.g. 0.15 = 15% (NOT 15). A rate of 1.0 (100%) or higher is rejected.
`order`	No	Stack position (default 0); components apply ascending.
`amount`	No	Explicit sales tax amount; used instead of the rate when useamount is true.
`compound`	No	When true, this tax stacks on lower-order taxes' totals (default false).
`parentid`	No	Id of one of this business's salestax definitions to move the tax to; the record then reports under that tax.
`exclusive`	No	Whether the entity amount excludes this sales tax (tax added on top).
`taxsource`	No	Stable locale rate-band identity, e.g. "locale:za/standard"; "$delete" clears it.
`treatment`	No	"standard" \| "zeroRated" \| "exempt"; blank/unknown means infer, "$delete" clears it.
`useamount`	No	When true, use amount as the tax figure instead of computing from the rate.
`recoverable`	No	Whether this sales tax is recoverable (claimable as input tax).
`referencenumber`	No	Sales tax registration/reference number.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / parentid

Added value: +{
+  "description": "Id of one of this business's salestax definitions to move the tax to; the record then reports under that tax.",
+  "type": "string"
+}

First observedSep 7, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates but is non-destructive. The description adds the key behavioral fact that this only operates on existing records. However, it doesn't mention idempotency, permissions, or partial-update semantics beyond the schema's $delete hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The core action is front-loaded, and the sibling routing follows immediately.

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 14-param mutation tool with full schema coverage and clear annotations, the description covers the essential routing and scope. It could add a note about partial updates (only supplied fields change) or required permissions, but the main gaps are minor given the rich schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters are already documented in the schema, including edge cases like $delete and rate limits. The description adds no parameter-level detail beyond routing guidance, which is appropriate given the exhaustive schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Update) and resource (existing sales tax on an entity), and explicitly distinguishes itself from the three add_* siblings by naming them. An agent can immediately tell this is a modification tool, not a creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool (updating an existing sales tax) versus the alternatives, naming add_entity_salestax, add_entity_salestaxes, and add_salestax_to_entities with their respective scopes. No inference required.

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

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