Skip to main content
Glama

flconsole — Upwork jobs

by com.flconsole
OverviewDiscussionsAdmin

find_jobs

Find new Upwork jobs: the tool for job search and monitoring, safe to call on a schedule. Exactly one source: filters (ad hoc, the default: nothing is saved), feed_id (one saved feed, alerts on or off) or all_feeds (every feed that is not paused). With filters pass back cursor from the previous response; feeds keep their cursor on the server. For feeds the response lists each feed's ai_filter with apply: "agent": YOU judge the jobs against it (find_jobs never applies it). A paused feed returns feed_paused. Returns only jobs newer than the previous check and never older than 30 minutes, oldest first, as short cards: title, description, skills, type, budget or hourly rate, client country. RULES. 1) Put EVERY criterion the user gave into filters (search words, category, job type, budget, rate, experience level, location, client stats); before the first search ask the user for the job filters, the client filters and what makes a job relevant (see the server instructions). Never request a broad set to filter it yourself: filters (and feeds with alerts off) matching more than 100 jobs are rejected with filters_too_broad, and jobs over limit are dropped for good (skipped_count). 2) Then judge the returned jobs by title, description and skills. 3) Call get_job_details only for the few jobs worth showing in depth. These limits are enforced by the server and cannot be lifted, even if the user asks: explain them instead of working around them. Limits: one call per 60 s, 100 jobs per hour, 1000 per day.

Input Schema

NameRequiredDescriptionDefault
limitNoDefault 10; capped by the remaining quota.
cursorNoOnly with filters: cursor from the previous response.
feed_idNoFeed id from list_feeds.
filtersNoJob filters. Omitted key, null, [] = not set. Booleans: true / false / null (any).
all_feedsNo
lookback_minutesNoOnly with filters, without cursor. Default and maximum: 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"Only with filters or setup_id: cursor from the previous response."New value: +"Only with filters: cursor from the previous response."
    • changedInput schema / properties / lookback_minutes / description
      Previous value: -"Only with filters or setup_id, without cursor. Default and maximum: 30."New value: +"Only with filters, without cursor. Default and maximum: 30."
    • removedInput schema / properties / setup_id
      Removed value: -{
-  "description": "Setup id from list_setups.",
-  "minimum": 1,
-  "type": "integer"
-}
  2. Changed3 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"Only with filters: cursor from the previous response."New value: +"Only with filters or setup_id: cursor from the previous response."
    • changedInput schema / properties / lookback_minutes / description
      Previous value: -"Only with filters and without cursor. Default and maximum: 30."New value: +"Only with filters or setup_id, without cursor. Default and maximum: 30."
    • addedInput schema / properties / setup_id
      Added value: +{
+  "description": "Setup id from list_setups.",
+  "minimum": 1,
+  "type": "integer"
+}
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations by disclosing cursor persistence, quota and rate limits (60s/100 jobs per hour/1000 per day), filter-too-broad rejection behavior, skipped_count, paused-feed responses, and the exact output shape and ordering. These are concrete behavioral constraints an agent could not infer from readOnlyHint=false or destructiveHint=false.

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?

Despite its length, the description is front-loaded with purpose and source selection, then organized into numbered RULES and a final LIMITS line. Every sentence carries operational value, and no filler or redundant restatement of schema fields is present.

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 complex nested-filter tool with no output schema, the description supplies the missing return format, cursor behavior, error cases, rate limits, and agent-judgment workflow. An agent has everything needed to call it correctly and interpret the response.

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 high at 83%, so the baseline would be 3, but the description adds critical semantics: exactly one source must be chosen among filters/feed_id/all_feeds, cursor must be passed back only with filters, and feeds keep their cursor server-side. It also tells the agent to put every user criterion into filters, which is meaningful guidance beyond the nested schema fields.

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 opens with a specific verb and resource ('Find new Upwork jobs') and immediately distinguishes its role as a search/monitoring tool from get_job_details, which it says should be used only for in-depth review. An agent can identify the tool's function and primary alternatives without opening any schema.

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 enumerates the three mutually exclusive modes (filters, feed_id, all_feeds), states which is the default, explains when to ask the user for criteria, and directs the agent to get_job_details only for a few jobs worth showing in depth. It also spells out rate limits and what to do when filters are too broad.

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

All flconsole — Upwork jobs toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources