Moxlade — Upwork buyer intelligence

How much a skill is being hired for

skill_demand

Read-onlyIdempotent

How many jobs mentioning a skill were posted recently, and whether that is rising or falling week by week.

Use it to decide whether a skill is worth positioning around, or to check a hunch that a market is drying up. skill matches the title, the skills list and the inferred technical skills of a posting; it is a loose match, so "react" also counts "React Native". window is one of "week", "month" or "quarter" and sets both the total and how many weekly buckets come back — any other value is refused rather than silently defaulted.

Returns jobs_posted for the whole window and weekly, a list of buckets oldest first, so a trend is visible without a second call.

DO NOT COMPARE THE BUCKET COUNTS DIRECTLY. Weeks are cut on Mondays and the window is not, so the newest bucket holds only the days elapsed so far and the oldest holds only the tail of the week the window opened in. Both are low for a calendar reason and no other, which reads as a rise and a fall that did not happen. Every bucket therefore carries days_covered, partial, and per_day — the per-day rate is the comparable number. trend is computed from complete weeks only; prefer it, and if you quote a bucket marked partial, say that it is. trend.direction is 'rising', 'falling', 'flat', or 'unknown' when there are fewer than two complete weeks — 'unknown' means the window is too short to judge, not that demand is flat.

A COUNT over public postings — no rows, no buyers, no ids, nothing that identifies a client. It answers how much, not who. And it counts POSTINGS, not hiring: a skill can be posted about constantly by clients who never hire. For whether a specific client hires and pays, ask get_buyer_quality.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`skill`	Yes	a skill name; matched loosely against title, skills and inferred skills. Must not be empty — there is no 'all skills' query.
`window`	No	How far back to count, and how many weekly buckets come back. Anything else is refused rather than silently defaulted.	month

Output Schema

TableJSON Schema

Name	Required	Description
`basis`	No	That this counts postings, not hiring.
`skill`	No	The skill asked about.
`trend`	No	Direction computed from COMPLETE weeks only — see Trend.
`weekly`	No	Oldest first. Read per_day across them, never the raw counts.
`window`	No	week \| month \| quarter.
`jobs_posted`	No	Total across the whole window.

TDQS

A5/5.0

Behavior5/5

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

The description goes far beyond the annotations: it explains loose matching ('react' also counts 'React Native'), warns against comparing bucket counts directly due to partial weeks, describes the `days_covered`, `partial`, `per_day` fields, and clarifies that 'unknown' trend means the window is too short, not flat. This gives the agent a thorough understanding of the tool's behavior and pitfalls.

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?

Although lengthy, the description is well-structured: it opens with the main purpose, then usage, parameter details, output explanation, and caveats. Every sentence carries relevant information, and the most critical points (purpose, loose matching, bucket comparison warning) are front-loaded. It avoids fluff and tautology.

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?

The description is fully self-sufficient: it explains the output shape (`jobs_posted`, `weekly` buckets, `trend.direction`), the meaning of each field, the interpretation of partial weeks, and the limitation of counting postings not hiring. Combined with the input schema and annotations, an agent can use this tool correctly without needing additional documentation.

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 description adds crucial semantics not fully captured in the schema: the `skill` parameter uses loose matching with an example, and `window` sets both the total and the number of buckets, with invalid values refused. This enriches the bare parameter descriptions and prevents misuse.

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: 'How many jobs mentioning a skill were posted recently, and whether that is rising or falling week by week.' It also provides concrete use cases ('decide whether a skill is worth positioning around, or to check a hunch that a market is drying up').

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 guides when to use the tool versus alternatives: 'For whether a specific client hires and pays, ask get_buyer_quality.' It also clarifies that it counts postings, not hiring, which tells the agent when not to rely on it for hiring intent.

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

All Moxlade — Upwork buyer intelligence tools Inspect

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

A4.8/5.0

Disambiguation5/5

Each tool serves a distinct, well-scoped function with no overlap. Even related tools like get_buyer and get_buyer_quality are clearly separated by their purposes and descriptions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using clear, descriptive verbs (check, delete, describe, get, list, save, search, rate). No mixed cases or conventions.

Tool Count5/5

15 tools is appropriate for the server's purpose, covering search, filtering, saved searches, buyer intelligence, job details, rate benchmarks, skill demand, and plan management without being excessive.

Completeness5/5

The set covers all core operations for Upwork buyer intelligence: searching, validating filters, saving searches, buyer analysis, job scoring, rate benchmarks, skill demand, and plan management. No significant gaps are apparent.

Resources

Need Help?