dealdesk-mcp

dealdesk.create_case

Create a DealDesk sales/request case and add its desk card. Open new cases here; update existing desk card value, chance, or period with patch_card instead.

Instructions

Create a DealDesk case (sales/request case, not a Salesforce Opportunity search). Creating a case also adds a desk card. To set value/chance/period on an existing desk card, use dealdesk.patch_card instead — do not create_case as a substitute.

Input Schema

Name	Required	Description
`stage`	No
`title`	No
`quoteId`	No
`companyId`	No
`contactId`	No
`projectId`	No	DealDesk project id. Omit when the OAuth token or API key authorizes exactly one project. Required when Connect authorized several projects.
`description`	No
`ownerUserId`	No
`estimatedValue`	No	Working forecast amount. Does not rewrite linked quote totals.
`probabilityPercent`	No	Win chance percent (0–100).
`estimatedValuePeriod`	No	Labels estimatedValue as one-time, monthly, or yearly. Does not convert the amount. Use year for ARR / per-year (e.g. 4000 EUR per year). Defaults to one_time when omitted on create.
`estimatedValueCurrency`	No	ISO 4217 alpha-3 currency code (e.g. EUR).

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.1.1Oct 7, 2026

addedInput schema / properties / estimatedValue / description

Added value: +"Working forecast amount. Does not rewrite linked quote totals."

addedInput schema / properties / estimatedValue / minimum
```
Added value: +0
```
addedInput schema / properties / estimatedValue / nullable
```
Added value: +true
```
addedInput schema / properties / estimatedValueCurrency / description
```
Added value: +"ISO 4217 alpha-3 currency code (e.g. EUR)."
```

addedInput schema / properties / estimatedValuePeriod

Added value: +{
+  "description": "Labels estimatedValue as one-time, monthly, or yearly. Does not convert the amount. Use year for ARR / per-year (e.g. 4000 EUR per year). Defaults to one_time when omitted on create.",
+  "enum": [
+    "one_time",
+    "month",
+    "year"
+  ],
+  "type": "string"
+}

addedInput schema / properties / probabilityPercent / description
```
Added value: +"Win chance percent (0–100)."
```
addedInput schema / properties / probabilityPercent / maximum
```
Added value: +100
```
addedInput schema / properties / probabilityPercent / minimum
```
Added value: +0
```
addedInput schema / properties / probabilityPercent / nullable
```
Added value: +true
```

changedInput schema / properties / projectId / description

Previous value: -"DealDesk project id (must match API key / OAuth project)"New value: +"DealDesk project id. Omit when the OAuth token or API key authorizes exactly one project. Required when Connect authorized several projects."

changedInput schema / required

Previous value: -[
-  "projectId"
-]New value: +[]

First observedv0.1.0Sep 30, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does add one valuable behavioral fact: creating a case also adds a desk card. However it says nothing about required permissions, idempotency, or how the created case/card is identified, leaving significant behavioral gaps for a mutation tool.

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?

Three compact sentences with the core action front-loaded and the sibling routing placed after. No filler or redundancy; every clause carries information.

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

Completeness3/5

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

For a 12-parameter mutation tool with no annotations, no output schema, and only 42% schema coverage, the description is only partially complete. It handles purpose and the key sibling exclusion well but omits parameter meaning and any return/identification behavior.

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

Parameters2/5

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

Schema description coverage is only 42% across 12 parameters, so the description is expected to compensate, but it explains none of them (no guidance on stage, ownerUserId, companyId, etc.). The few documented fields (projectId, estimatedValue, probabilityPercent, estimatedValuePeriod) are covered only by the schema, not the description.

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 and resource ('Create a DealDesk case') and immediately disambiguates it from a Salesforce Opportunity search. It also discloses the side effect that a case creation adds a desk card, so the agent knows exactly what this tool does.

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?

Explicitly names the alternative dealdesk.patch_card for setting value/chance/period on an existing desk card and warns 'do not create_case as a substitute.' That is a clear when-not, but it does not cover the broader create landscape (e.g., create_case vs create_card) among the many siblings.

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

Deploy Server

dealdesk.create_case

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools