Skip to main content
Glama
Sign In
agenthouse-org

dealdesk-mcp

by agenthouse-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

dealdesk.list_cards

List DealDesk desk cards for one project, filter by search query, stage, or owner, page through results, and fetch full card details when needed.

Instructions

List DealDesk desk cards for one project. Default rows are summaries (cardId, title, stage, quoteId). Filter with q, stage, and/or ownerUserId. Pass fields=full for the complete card. Returns total, hasMore, nextCursor, projectId, and authorizedProjectIds.

Input Schema

NameRequiredDescriptionDefault
qNoSearch query
limitNoPage size (default 25, max 100)
stageNoDesk board column id (not a UI label). Resolve with dealdesk.list_desk_stages. Default board: request, request-in-progress, quote-preparation, quote-sent, quote-accepted, order-processing, order-completed, closed. Soft-close with closed. Never invent ids by slugifying labels (e.g. Anfrage in Bearbeitung → request-in-progress, not anfrage-in-bearbeitung).
cursorNoOpaque page cursor from the previous nextCursor
fieldsNosummary (default) returns list rows. full returns complete cards.
projectIdNoDealDesk project id. Omit when the OAuth token or API key authorizes exactly one project. Required when Connect authorized several projects.
ownerUserIdNoFilter to cards owned by this user id (from dealdesk.list_desk_users)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Opaque page cursor from the previous nextCursor",
+  "type": "string"
+}
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "summary (default) returns list rows. full returns complete cards.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"Max cards (default 25, max 100)"New value: +"Page size (default 25, max 100)"
    • addedInput schema / properties / ownerUserId
      Added value: +{
+  "description": "Filter to cards owned by this user id (from dealdesk.list_desk_users)",
+  "type": "string"
+}
    • 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."
    • addedInput schema / properties / stage / description
      Added value: +"Desk board column id (not a UI label). Resolve with dealdesk.list_desk_stages. Default board: request, request-in-progress, quote-preparation, quote-sent, quote-accepted, order-processing, order-completed, closed. Soft-close with closed. Never invent ids by slugifying labels (e.g. Anfrage in Bearbeitung → request-in-progress, not anfrage-in-bearbeitung)."
    • changedInput schema / required
      Previous value: -[
-  "projectId"
-]New value: +[]
  2. First observedv0.1.0

TDQS

A3.6/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 return shape and pagination (total, hasMore, nextCursor) and hints at authorization via projectId/authorizedProjectIds, but it never explicitly states this is a read-only, non-mutating operation, nor notes rate limits or permissions. Useful but incomplete for an unannotated tool.

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?

Four tight sentences with no filler, and the core purpose is front-loaded. The final return-values sentence is dense but earns its place given there is no output schema.

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 7-parameter read tool with 100% schema coverage and no output schema, the description supplies the missing return-value context (pagination fields, project scope) and the default row shape. An agent has enough to invoke it correctly; only explicit read-only and error/auth behavior are absent.

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?

Schema coverage is 100%, so the schema already documents every parameter and the baseline is 3. The description adds meaning beyond it by enumerating the default summary row fields (cardId, title, stage, quoteId) and clarifying the summary-vs-full switch — information not present in the schema.

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 and resource (list DealDesk desk cards) plus the scope (one project), which contrasts with the sibling get_card for a single card. It is clear but never explicitly names or distinguishes itself from the sibling listing tools (list_desk_stages, list_quotes, etc.), so it stops short of a 5.

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

Usage Guidelines3/5

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

It tells the agent how to narrow results ("Filter with q, stage, and/or ownerUserId") and how to expand them ("Pass fields=full"), which implies usage. However, it gives no explicit when-to-use/when-not guidance and does not name alternatives such as get_card or list_desk_stages as the path for other needs.

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