upwork__get_draftRetrieve a pending server-stored draft without consuming it.
Actions:
get: Get a pending draft for review. Params: type (required — the draft type), id (required — the draft_id returned by the creating action).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The operation to perform | |
| params | No | Action-specific parameters (see allOf branches per action when present) | |
| org_uid | Yes | Your Upwork org_uid from list_accounts |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond that: the draft is pending, server-stored, and retrieving it does not consume it. This clarifies the state impact of the call without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core behavior, and the Actions section provides the required parameter mapping without extraneous detail. Every sentence contributes to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with nested params and no output schema, the description covers the essential retrieval behavior, the non-consuming nature, and the required draft identifiers. It does not explain the relationship to confirm/update actions, but the schema and annotations cover the remaining operational details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents id as 'Draft ID returned as draft_id by the creating action' and type as 'Draft type returned by the action that created the draft.' The description repeats this information rather than adding significant new semantic value, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') with a precise resource ('pending server-stored draft') and adds a key scope qualifier ('without consuming it'). This clearly differentiates the tool from siblings like upwork__confirm_draft and upwork__update_draft, which consume or modify drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get a pending draft for review' establishes clear context: use this tool when you need to inspect a draft before finalizing it. It does not explicitly name alternatives or when-not-to-use conditions, but the review purpose and non-consuming behavior imply the appropriate usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tool names are distinct, but several surfaces overlap: find_jobs and get_job_posting both provide marketplace job search/get, and list_offers' list and list_mine are duplicates. The verbose descriptions help, but an agent could still select the wrong tool, especially when actions are nested inside tools.
All tools share the upwork__ prefix and a snake_case verb_noun pattern, which is easy to scan. There are minor inconsistencies in verb choice (get_account vs list_accounts, get_messages vs send_message) and a few vague names, but no chaotic mixing of conventions.
33 tools is over the 25+ threshold and includes redundancies like duplicate marketplace job search surfaces and list/list_mine in list_offers, plus several meta/config tools. The broad Upwork domain explains some of the count, but the surface is heavier and more duplicated than it needs to be.
Client-side workflows are well covered: job posting, proposals, offers, contracts, milestones, messaging, and financials. However, core freelancer flows are incomplete—there is no tool for submitting a proposal or accepting an offer—and descriptions reference missing tools such as list_freelancer_proposals and respond_to_offer, creating notable dead ends.