Stackcut

Report an action outcome

report_action_outcome

Idempotent

Record a minimal structured report about an attempted cancel, price reduction, negotiation, pause, downgrade, or switch. First call get_exit_plan and send its packet_revision and route_id; stale packet revisions are rejected. Reports are user-reported evidence, never verified execution. The server stores no free text, receipts, messages, or direct identifiers. Reusing client_dedupe_key returns the existing report without inflating counts; blocked or changed-step reports create a review task and never edit a packet automatically. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Input Schema

Name	Required	Description
`action`	Yes
`locale`	Yes	Language tag such as en or en-US
`market`	Yes	Two-letter country code
`blocker`	No	Required for blocked or steps_changed
`channel`	Yes	The selected route's billed_by channel
`outcome`	Yes
`service`	Yes	The service name or id from get_exit_plan
`currency`	No	Required with numeric amounts
`route_id`	Yes	The selected route_id from get_exit_plan
`fees_amount`	No
`effective_on`	No
`offer_amount`	No	Optional reported amount, never treated as verified savings
`renewal_amount`	No
`savings_amount`	No	Optional reported savings amount (negative means costs rose), never treated as verified savings
`packet_revision`	Yes	The current packet_revision from get_exit_plan
`client_dedupe_key`	Yes	A fresh opaque idempotency key; never use an email, account id, or other personal value
`commitment_months`	No
`offer_billing_period`	No
`offer_duration_months`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 7, 2026

addedInput schema / properties / commitment_months

Added value: +{
+  "maximum": 1200,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / currency / description

Previous value: -"Required with either numeric amount"New value: +"Required with numeric amounts"

addedInput schema / properties / effective_on

Added value: +{
+  "maxLength": 2000,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / fees_amount

Added value: +{
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / offer_billing_period

Added value: +{
+  "enum": [
+    "month",
+    "year",
+    "week",
+    "one_time"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

addedInput schema / properties / offer_duration_months

Added value: +{
+  "maximum": 1200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / renewal_amount

Added value: +{
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

AddedOct 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the annotations: reports are unverified user-reported evidence, blocked/steps_changed outcomes spawn a review task, packets are never auto-edited, and it discloses exactly what argument data is retained, hashed, or excluded. The dedupe-reuse behavior is consistent with idempotentHint=true and the write semantics match readOnlyHint=false, so there is no contradiction.

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

Conciseness4/5

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

Purpose, prerequisite, behavior, and data policy are delivered in a front-loaded sequence with no filler sentences. It is long and the telemetry paragraph partly overlaps the earlier 'stores no free text, receipts, messages, or direct identifiers' claim, but the density of information justifies most of the length.

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 19-parameter, no-output-schema mutation tool this covers a lot: inputs provenance, rejection behavior, downstream effects, and data handling. The notable gap is disambiguation from report_outcome and report_exit_outcome, which an agent needs in order to pick this tool at all.

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

Parameters4/5

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

With 19 parameters at 58% schema coverage, the description meaningfully supplements the schema: packet_revision freshness rules, route_id provenance from get_exit_plan, and client_dedupe_key reuse semantics that map to a report-returning idempotent call. It doesn't cover the remaining undocumented amount/commitment fields, but the highest-risk parameters are addressed.

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

Purpose4/5

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

States a specific verb (record) and resource (a structured report) and enumerates the six action types it covers (cancel, pay_less, renegotiate, pause, downgrade, switch), so the domain is unambiguous. It does not, however, differentiate itself from close siblings like report_outcome or report_exit_outcome, leaving the agent to guess which report tool applies.

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

Usage Guidelines4/5

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

Gives an explicit ordering prerequisite: call get_exit_plan first and pass its packet_revision and route_id, with stale revisions rejected. It describes the triggering context (after an attempted action) but offers no when-not guidance or alternative-tool routing against the three sibling report tools.

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

All Stackcut tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Report an action outcome

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources