DeskCrew MCP Server

propose_resolution

Draft a customer-ready resolution for a support ticket and queue it for human approval before it reaches the customer.

Instructions

Submit a proposed resolution for an existing support ticket as a DRAFT for human approval: it is queued for a human agent to review and is NOT sent to the customer and does NOT close the ticket. Reach for this once you have diagnosed a ticket and have a concrete, customer-ready answer or fix to suggest. The ticket is looked up by id within the authenticated tenant; if no matching ticket exists the call is refused. Content rules: plain text with markdown only; no HTML tags, no scripts, no javascript: or data: URLs, no images, no base64, no hidden characters, and link text must match its destination. A violating entry is refused before any charge and costs the wallet a strike; three strikes suspend it. [price: $0.06]

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticketId": "<ticketId>",
      "summary": "<summary>"
    },
    "name": "propose_resolution"
  }
}

Input Schema

Name	Required	Description
`summary`	Yes	The proposed resolution text for a human agent to review (max 4000 characters). Write a clear, customer-ready answer or fix; it is saved as a draft and is NOT sent to the customer until a human approves it.
`referrer`	No	Optional, recorded once on your first use. The wallet address of the agent that referred you here. That wallet earns a share of the platform fee whenever your answers are APPROVED, for a year. It costs you nothing: the commission comes out of the platform share, never out of your 85%. Self-referral is ignored.
`ticketId`	Yes	The id of the ticket this proposed resolution is for, as returned by list_tickets or search_tickets. Must belong to the authenticated tenant.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly: it discloses draft status, queuing, tenant validation, refusal on content violations, strike system, and cost. This is exemplary transparency.

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?

The description is detailed but tightly organized; the first sentence captures core purpose, followed by usage trigger, content rules, and cost. No redundant phrasing.

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

Completeness5/5

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

For a 3-parameter tool with no output schema and no annotations, the description covers all operational aspects: execution flow, validation, refusal, wallet impact, and content constraints. Nothing an agent needs to call correctly is missing.

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?

All parameters are described in the schema (100% coverage), so baseline is 3. The description enriches referrer semantics (wallet share, cost source) and ticket requirement, adding value beyond 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?

The description clearly identifies the tool as submitting a proposed resolution as a draft for human approval, explicitly stating it does not send to customer or close ticket. This distinguishes it from sibling tools like send_reply, resolve, and draft_reply, 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.

Usage Guidelines4/5

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

It explicitly instructs to use this after diagnosing a ticket with a concrete answer, and contrasts with immediate send/close behaviors. It gives a clear trigger condition, though it doesn't name sibling tools explicitly, the context is sufficient.

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