Skip to main content
Glama
Sign In
agenthouse-org

dealdesk-mcp

by agenthouse-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

dealdesk.patch_quote

Update draft quote metadata (title, language, currency, customer snapshots, experience template). Does not accept/decline and does not replace pricing lines.

Instructions

Update draft quote metadata (title, language, currency, customer snapshots, experience template). Does not accept/decline and does not replace pricing lines.

Input Schema

NameRequiredDescriptionDefault
titleNo
statusNoDraft-side status only; accepted/declined are refused
contextNoCPQ Variable values. When fieldSyncs exist, a context update copies one-way into servicePeriod and overwrites it. A servicePeriod edit does not write back.
quoteIdYes
currencyNo
languageNo
projectIdNoDealDesk project id. Omit when the OAuth token or API key authorizes exactly one project. Required when Connect authorized several projects.
opportunityIdNo
servicePeriodNoFirst-class commercial period on quotes and orders. start/end accept ISO dates or YYYY-MM (month expands to first/last day). single is derived and read-only.
accountSnapshotNo
contactSnapshotNo
customerSnapshotNo
experienceTemplateIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.2
    • addedInput schema / properties / context
      Added value: +{
+  "additionalProperties": true,
+  "description": "CPQ Variable values. When fieldSyncs exist, a context update copies one-way into servicePeriod and overwrites it. A servicePeriod edit does not write back.",
+  "type": "object"
+}
    • addedInput schema / properties / servicePeriod
      Added value: +{
+  "additionalProperties": false,
+  "description": "First-class commercial period on quotes and orders. start/end accept ISO dates or YYYY-MM (month expands to first/last day). single is derived and read-only.",
+  "nullable": true,
+  "properties": {
+    "end": {
+      "nullable": true,
+      "type": "string"
+    },
+    "start": {
+      "nullable": true,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed2 schema fields changedv0.1.1
    • 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",
-  "quoteId"
-]New value: +[
+  "quoteId"
+]
  3. First observedv0.1.0

TDQS

A4/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: it discloses the mutation scope and that status transitions beyond draft are refused, which is useful. However, it says nothing about required permissions/authorization, whether changes are reversible, PATCH semantics (untouched fields preserved), or the one-way context→servicePeriod overwrite — the latter only appears buried in the schema, not the description.

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 filler, with the positive scope front-loaded and the exclusion clause immediately after. Nothing repeats the schema or the tool name verbatim without adding information.

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 13-parameter nested-object mutation with no annotations and no output schema, the description covers the essential decision points (what it edits, what it won't do) and lets the schema's parameter descriptions handle projectId, servicePeriod, and context. It is slightly thin on the snapshot objects and on what a successful patch returns (echo of the quote? nothing?), but is broadly sufficient.

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 only 31% across 13 parameters, so the description should compensate more than it does. It names the handled field groups but adds no format or constraint detail (currency code format, language code format, what a customer/account/contact snapshot contains, or that opportunityId is nullable and how it relates to projectId).

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 (update draft quote metadata) and enumerates the editable field groups (title, language, currency, customer snapshots, experience template). It also carves out scope boundaries against siblings — no accept/decline, no pricing-line replacement (which is replace_quote_items' job) — so an agent can distinguish it from patch_quote_share, replace_quote_items, and other quote tools without opening the schema.

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?

Explicit negative guidance ('Does not accept/decline and does not replace pricing lines') tells the agent when this tool is the wrong choice, which is more than most definitions offer. It falls short of a 5 because it never names the alternative tools (e.g. replace_quote_items for pricing, the accept/decline path) or states the prerequisite that the quote must be a draft.

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

Deploy Server

Other Tools