Skip to main content
Glama
Sign In
agenthouse-org

dealdesk-mcp

by agenthouse-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

dealdesk.render_quote_totals

Render quote totals as UI in MCP Apps hosts (ChatGPT) when users need to see quote totals instead of raw JSON.

Instructions

Show the DealDesk quote-totals widget in MCP Apps hosts (ChatGPT). Call this when the user should see quote totals UI. get_quote returns JSON only.

Input Schema

NameRequiredDescriptionDefault
quoteIdYes
projectIdNoDealDesk project id. Omit when the OAuth token or API key authorizes exactly one project. Required when Connect authorized several projects.

Output Schema

NameRequiredDescriptionDefault
quoteYesQuote status, totals, and optional analytics/shares. Extra fields live on this object, not beside it.
idempotentReplayNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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"
+]
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +true
    • changedOutput schema / properties / quote / description
      Previous value: -"Quote summary shown in the quote-totals widget"New value: +"Quote status, totals, and optional analytics/shares. Extra fields live on this object, not beside it."
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose key traits: it renders a UI widget, it requires an MCP Apps host (ChatGPT), and it is distinct from JSON-returning get_quote. It stops short of stating side effects, auth needs, or failure behavior, but the render-vs-data distinction is genuinely useful.

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 short, front-loaded sentences with zero filler; the host requirement and trigger condition lead, and the get_quote contrast closes efficiently.

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?

An output schema exists, so return values needn't be described, and the description covers host constraints and usage context. The only real gap is the undocumented required quoteId, which leaves the definition slightly short for a 2-parameter tool.

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 coverage is only 50%: projectId is documented in the schema while the required quoteId has no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the undocumented required parameter.

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+resource ('Show the DealDesk quote-totals widget') and explicitly distinguishes itself from get_quote by noting get_quote returns JSON only. It does not, however, differentiate from the nearby sibling get_quote_summary, which also concerns quote totals.

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?

'Call this when the user should see quote totals UI' gives a clear triggering condition, and the get_quote contrast implicitly routes data-only needs elsewhere. No explicit when-not guidance or named alternatives beyond that one contrast.

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