Moxlade — Upwork buyer intelligence

What a result field means

describe_fields

Read-onlyIdempotent

What every field of a result MEANS — the glossary the schema cannot deliver.

Call it the moment a field puzzles you, instead of guessing from its name. Every result field this server returns is documented: what it is, its type, the closed set of values where it has one, and — for anything nullable — what a null MEANS, which is never the same as zero.

Pass tool for one tool's fields. Omit it to get the list of tools with a field count each, which is small; asking for everything at once is not offered because the whole glossary is large and you rarely want all of it.

Free: read-only, unmetered, and it answers on every plan state. It documents the RESPONSE CONTRACT — what a field means — never how a number is computed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tool`	No	The tool whose fields you want, spelled exactly as tools/list names it ("get_buyer_quality"). Omit it to get the list of documented tools with a field count each, which is how you find the name to pass. An unknown name is refused, not silently emptied.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	How to ask for one tool, on the listing form.
`tool`	No	The tool these fields belong to. Absent when you asked for the listing.
`tools`	No	The tools and their field counts, returned when you call with no argument.
`fields`	No	Every documented field of that tool's result, sub-shapes flattened and named by `shape`.

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations readOnlyHint and idempotentHint, the description discloses meaningful behavior: it is 'unmetered', 'answers on every plan state', and documents the response contract but 'never how a number is computed.' These traits add context the annotations do not provide.

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 front-loaded with the core purpose, then flows naturally into when to use it, how to use the parameter, and cost/contract expectations. Every sentence adds useful information; the only slight redundancy is 'read-only' echoing the annotation, but it is part of a sentence that adds unique details.

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 tool with a single optional parameter, an output schema, and strong annotations, the description covers purpose, invocation modes, limits, behavioral boundaries, and what it does not do. An agent can correctly select and invoke this tool without ambiguity.

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?

Though schema coverage is 100%, the description enriches the single parameter's semantics by explaining the omitted-tool behavior and the rationale for not allowing 'everything at once.' This goes well beyond the schema's own default-null description.

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 defines the tool as a glossary for result fields: 'What every field of a result MEANS — the glossary the schema cannot deliver.' It specifies the resource being described and differentiates it from data-retrieval siblings like get_buyer or search_jobs by being a meta/documentation tool.

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?

Explicitly tells when to use it: 'Call it the moment a field puzzles you, instead of guessing from its name.' It also explains the two modes — pass `tool` for one tool's fields, omit it to get the list of tools — and what is not offered ('asking for everything at once is not offered').

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?