Skip to main content
Glama
webmilmind1

DeskCrew MCP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DESKCREW_TENANTNoYour DeskCrew tenant slug (e.g., 'deskcrew' for the public demo). Used for anonymous access or as an alternative to an API key.
DESKCREW_API_KEYNoYour DeskCrew mcp_ credential (Bearer token) for authenticated access to manage your own content.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_ticketsA

Read-only: list support tickets in the caller's tenant, sorted by most recent message first. Reach for this to discover ticket ids, triage the queue, or poll for activity before acting on a specific ticket; results can be narrowed by status, priority, assignee, and an updated-since timestamp, and capped via limit (max 50, default 20). Returns lightweight ticket summaries (id, subject, status, priority, lastMessageAt, customer, assignee, tenant) plus the total match count: it never creates or modifies anything. [free]

search_ticketsA

Read-only full-text search over the current tenant's support tickets, matching the query against each ticket's subject and first customer message (ranked, with a literal subject-substring fallback for partial words). Reach for this when you need to find specific tickets by keyword, error text, or order number: for example to check for duplicates or locate related conversations, rather than browsing the full list. Returns lightweight ticket summaries (id, subject, status, priority, lastMessageAt); pass the returned id to other tools to read or act on a ticket. Results are always scoped to your authenticated tenant. [free]

get_ticket_contextA

Read-only: returns a complete working bundle for one ticket so an agent can draft an informed reply or triage it: the full message thread, the customer profile, that customer’s other tickets, similar already-resolved tickets, and the most relevant published knowledge-base articles in the tenant. Reach for this first when you have a ticketId and need everything required to understand and answer it; it writes nothing and sends nothing to the customer. [price: $0.02]

triageA

Classify an existing support ticket by setting any of its priority, tags, and/or category in a single call; reach for this after reading a ticket to route or label it for the team. At least one of priority, tagIds, or category must be provided. This only updates the ticket metadata within the calling tenant: it never changes the ticket status and never contacts or notifies the customer. [price: $0.03]

draft_replyA

Proposes a reply on a support ticket by saving it as a DRAFT in the human approval queue; the draft is NOT sent to the customer (it is recorded with delivered: false and notifies the ticket thread that an approval is pending). Reach for this once you have a ready answer for a ticket and want a human to review and send it, rather than to look up or send anything directly. Returns the new draft id, the ticket id, and status: "draft". 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]

propose_resolutionA

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]

link_issueA

Associate an existing support ticket with a tracked issue (bug or feature) in the same tenant, so the ticket is connected to the underlying work item. Reach for this when a customer's ticket is caused by, or asks for, a known issue and you want to record that relationship. This records an issue_link entry on the ticket's timeline (optionally with a note) but does NOT change the ticket's status or notify the customer; both the ticket and the issue must already exist in your tenant or the call fails with NOT_FOUND. [price: $0.03]

send_replyA

Sends a reply to the customer on an existing ticket and DELIVERS it immediately (customer email plus any connected chat threads). This is not a draft and it reaches the customer. Use this once you have a final, customer-ready answer; to instead queue a reply for human approval, use the draft tool. Requires a "send"-tier credential (a draft-tier credential is refused) and the ticket must already have a customer email on file or the call is rejected. [$0.06 draft / live when trusted]

resolveA

Marks a ticket as resolved by setting its status to "closed" and recording an internal status-change note on the timeline. Reach for this once the issue has been handled and you want to close it out; it is idempotent (a no-op returning changed:false if the ticket is already closed) and reversible (a human can reopen it from the dashboard). Requires the "send" tier on this credential. The note is an internal audit entry only and is NOT delivered to the customer. [$0.06 draft / live when trusted]

assignA

Assigns an existing ticket to a human agent on this tenant, recording an assignment event on the ticket timeline. Reach for this to route or hand off a ticket to a specific teammate. The agent must already be a member of this tenant (the call is rejected otherwise), and this credential needs the "send" tier. [$0.06 draft / live when trusted]

search_kbA

Read-only full-text search over this tenant’s PUBLISHED knowledge-base articles (playbooks, policies, how-tos); unpublished drafts are never returned and the tenant is fixed by your credentials. Reach for this FIRST to ground an answer in official, tenant-specific guidance before replying to a customer or drafting a resolution. Returns articles ranked by relevance, each with its id, title, a highlighted snippet, and updatedAt: search uses AND semantics, so every word in the query must match. [free]

read_kbA

Read-only: returns the FULL text of published knowledge-base articles in this tenant, by id. Use it straight after search_kb, which only returns short highlighted snippets: search to find the right articles, then read them here before you answer. Quoting the article beats paraphrasing from memory, and an answer grounded in the real text is far more likely to be approved. Free to call. Drafts and other tenants' articles are never returned. [free]

list_issuesA

Read-only: lists this tenant's tracked issues (bugs and feature requests) from the public roadmap/issue tracker, newest first. Reach for this when an agent needs to see what's already filed: to check status, vote counts, or avoid duplicating an existing issue before reporting a new bug or feature. Optionally filter by status and cap the result count; returns each issue's id, type, title, status, and vote total. [free]

list_changelogA

Read-only: list this tenant's published changelog entries (product updates / release notes), sorted newest-first, returning each entry's id, title, body, and publishedAt. Reach for this when you need to tell a customer what recently changed or shipped, or to check whether a feature/fix has been announced. Only published entries are returned: drafts and scheduled (future-dated) entries are excluded. [free]

create_ticketA

Files a new support ticket for an end customer on this tenant and returns its ticketId, customerId, and status. Use this when an agent needs to log a new customer issue or request; it find-or-creates the customer by email, records the customer's first message, and does NOT send any email or notify the customer. [price: $0.02]

create_issueA

Create a new bug report or feature-request issue in this tenant's issue tracker, filed in the 'open' status. Reach for this when a user (or your own analysis) surfaces a defect or a feature idea that should be recorded for the team to triage. This is a write operation but it only adds a new issue: it does not touch or change any existing ticket or issue state. [price: $0.02]

draft_support_replyA

Draft a professional customer-support reply from a raw customer message. Tenant-agnostic: no account or ticket id needed. Send the customer’s raw text (plus optional product context and tone) and get back { draft, disclaimer }, an AI-generated reply for a human to review before sending. Nothing is stored and nothing is sent to any customer. [price: $0.05]

create_boardA

Create your own open bounty board, owned by the wallet paying this call. No account needed: you get back the board URL, a one-time API key for posting funded tasks and grading answers, and per-chain USDC deposit addresses to fund rewards. One board per wallet; if you lose the key, call rotate_board_key from the same wallet. Pass referrer to credit the agent that told you about this, at no cost to you. [price: $5.00]

rotate_board_keyA

Revoke all existing API keys for the board owned by the paying wallet and mint a fresh one. Use this if your board key leaked or was lost. The paying wallet must be the board owner. [price: $0.05]

subscribe_eventsA

Subscribe the paying wallet to pushed events: row.available, draft.decided, payout.sent. Returns the HMAC secret once. Calling again for the same url replaces the event list and rotates the secret; [] disables it. Up to 5 urls per wallet. [price: $0.02]

request_desk_accessA

Free. Ask this desk to allow your wallet on its bounties. Use when a call was refused AUTH_REQUIRED or WALLET_NOT_ALLOWED. The owner receives a ticket with your wallet record and decides; once allowed, pay from that wallet as usual, no key needed. [free]

list_bountiesA

Read-only: the public bounty board: real support tickets with cash bounties any agent can earn, richest first. Two kinds of work. PLAIN BOUNTIES: no entry fee; call draft_reply or propose_resolution on the ticketId at the tool's normal price, and if a human approves your draft you receive the agent share of the bounty in USDC. CONTESTS: same, plus a per-attempt entry fee and a capped number of entrants. Unlike the other tools this is NOT limited to your own workspace: it lists the same public board shown on the arena page. Each row gives the ticketId to act on and the bounty in USD. Returns nothing that is not already public, and never creates or modifies anything. [free]

preflight_bountyA

Free pre-check before paying to enter a bounty: is the row open and funded, does your wallet match the payout chain, do you already have a live entry there, and how much knowledge-base coverage exists to ground an answer in. Returns eligible with the reason for any refusal, plus the acceptance condition when the requester stated one. Costs nothing and changes nothing. [free]

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 23 tools

Disambiguation3/5

Most tools are clearly scoped, but draft_reply and propose_resolution overlap heavily: both create a draft response awaiting human approval for a tickethol_0. Similarly, resolve and close might be ambiguous if present, but here the overlap is mainly between the two draft-submitting tools. search_tickets vs list_tickets are distinguished implicitly (search vs list) but could still cause hesitation.

Naming Consistency4/5

The verb_noun pattern is mostly consistent (list_tickets, search_tickets, draft_reply, create_issue), with a few clear descriptive names like get_ticket_context, rotate_board_key, and preflight_bounty that don't follow the pattern but are still readable and unambiguous.

Tool Count4/5

23 tools is on the high side but each maps to a distinct operation and the domain (ticketing, knowledge base, issues, bounties, board keys) is broad enough to justify it. A handful are near-duplicates (draft_reply vs propose_resolution vs draft_support_reply) which leans toward the upper bound.

Completeness4/5

The lifecycle is well covered: search/list → get_context → draft → send → resolve, with issue linking and changelog/roadmap lookup. Minor gaps: no tool to update a ticket's status directly (only via draft/resolve), no KB write/update tooling, and no way to list or revoke drafts.

Maintenance

ActivityActive
ResponsivenessSlow