Skip to main content
Glama

Upwork MCP Server

by com.upwork.mcp

Send Message

upwork__send_message
Destructive

Create rooms and send messages. Freelancers (TALENT): cannot initiate a proposal room or send the first message on a proposal — the client must contact you first. To reply, use an existing room from list_freelancer_proposals action=get_room or get_messages action=find_room (context_type=proposal). If no room exists yet, tell the user the client needs to message first.

WRITE OPERATION — REQUIRES EXPLICIT USER CONFIRMATION. You MUST present full action details and receive explicit approval before executing. Each write requires separate confirmation even if the user said "approve all".

Actions:

  • create_room: Create a group room. Params: input (object, required — RoomCreateInputV2).

  • send: Send a message to a room. Params: room_id (string, required), message (string, required unless file_attachments is set; max 10240 characters — if the user's text is longer, ask them to shorten it rather than sending it truncated). file_attachments (array, optional — each item needs file_id and file_name from start_attachment_upload; include image_id when present).

  • send_to_user: Send a message to a user (auto-creates 1-on-1 room if needed). Starting a conversation with a freelancer you are not yet connected to uses one of a limited number of new connections per day; the response includes remaining_connections. Optionally attach a job via job_posting_id to share it — the recipient gets a link plus a job id their assistant can open with find_jobs get. Params: user_id (string, required), org_id (string, required — recipient's org ID), job_posting_id (string, optional), message (string, required unless file_attachments is set; max 10240 characters — if the user's text is longer, ask them to shorten it rather than sending it truncated). file_attachments (array, optional — each item needs file_id and file_name from start_attachment_upload; include image_id when present).

  • message_proposal: Send a message to a proposal applicant (auto-creates room if needed). Params: job_posting_id (string, required), proposal_id (string, required), message (string, required unless file_attachments is set; max 10240 characters — if the user's text is longer, ask them to shorten it rather than sending it truncated). file_attachments (array, optional — each item needs file_id and file_name from start_attachment_upload; include image_id when present).

  • edit: Edit a sent message. Params: room_id (string, required), story_id (string, required), message (string, required unless file_attachments is set; max 10240 characters — if the user's text is longer, ask them to shorten it rather than sending it truncated).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesThe operation to perform
paramsNoAction-specific parameters (see allOf branches per action when present)
org_uidYesYour Upwork org_uid from list_accounts

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (readOnly=false, destructive=true), it discloses that every write requires explicit confirmation, auto-creates rooms, consumes limited new connections, depends on attachment upload, and supports message editing. No contradiction with annotations.

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?

Well structured with front-loaded constraints and clear action bullets, but the message-limit and file-attachment caveat is repeated verbatim four times, adding unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action write tool with no output schema, it covers prerequisites (RoomCreateInputV2, attachment upload, org_uid), role restrictions, per-action params, side effects, and an important response detail (remaining_connections). Nothing essential to selecting or invoking the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only has generic action/params/org_uid fields; the description specifies all action-specific parameters, requiredness, the message length limit, attachment file_id/file_name/image_id requirements, and job_posting_id behavior. This greatly exceeds the schema's coverage.

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?

The first sentence states the operation verb and resource ('Create rooms and send messages') and the body enumerates five distinct actions, so an agent can identify what the tool does and how to pick an action. It also contrasts proposal-room initiation with replying in existing rooms, which further separates it from related message and proposal tools.

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

Usage Guidelines5/5

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

Provides explicit when and when-not guidance: freelancers cannot initiate proposal rooms or send the first proposal message; if no room exists, tell the user the client must message first; reply via list_freelancer_proposals/get_messages. It names the alternative tools and also mandates separate confirmation per write.

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

All Upwork MCP Server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness3/5

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.

Resources