Skip to main content
Glama

Upwork MCP Server

by com.upwork.mcp

Update Contract

upwork__update_contract

Update contract conditions. pause and restart run through MCP (draft -> confirm_draft). Changing the weekly hours limit is completed by you on Upwork and returns a link, not a direct change.

WRITE OPERATION — REQUIRES EXPLICIT USER CONFIRMATION. Returns a draft for review — call confirm_draft to execute after explicit user approval.

Actions:

  • pause: Prepare a contract pause draft. Params: contract_id (string, required), message (string).

  • restart: Prepare a draft to restart a paused contract. Params: contract_id (string, required), message (string).

  • update_hourly_limit: Get the Upwork link to change a contract's weekly hours limit. Changing the limit notifies the freelancer and must be done by you on Upwork — this returns a finalize_url, it does NOT change the limit. Params: contract_id (string, required).

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

A5/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that this is a write operation requiring explicit user confirmation, that it returns a draft rather than executing immediately, and that update_hourly_limit returns a finalize_url without changing the limit. It also notes the freelancer notification.

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?

The description is well-structured and front-loaded: a one-line summary, a critical write-operation warning, and a bulleted action list with per-action parameters. Every sentence contributes decision-relevant information without unnecessary padding.

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?

Given there is no output schema, the description adequately covers return behavior (draft or finalize_url), the external Upwork step, required parameters per action, and the confirm_draft execution path. An agent has enough context to invoke the tool correctly.

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 provides generic params object descriptions, but the description adds essential action-specific parameter semantics: pause and restart need contract_id and message, while update_hourly_limit needs only contract_id. This directly helps the agent construct correct invocations.

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 description clearly states the tool's purpose with a specific verb and resource ('Update contract conditions') and then enumerates three concrete actions: pause, restart, and update_hourly_limit. This makes it easy to distinguish from related tools like confirm_draft or update_draft.

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?

It explicitly explains when to use the tool: pause and restart produce drafts requiring confirm_draft, while update_hourly_limit is not a direct change and requires the user to complete it on Upwork. This gives actionable routing and execution guidance.

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