Worklittle Jobs

Jobs · Get Market Overview

get_market_overview

Read-onlyIdempotent

Jobs — Returns aggregate job-market statistics from Worklittle. Call with no args for the full indexed market (counts, workplace mix, top hiring companies). When the user names a role and/or city (e.g. product managers in San Francisco), pass query and location. The filtered slice includes match count, top companies in the sample, and salary signals from listings that publish pay.

Input Schema

Name	Required	Description
`query`	No	Role or title filter for a market slice (e.g. product manager).
`location`	No	Location substring for a market slice (e.g. San Francisco).
`workplace_type`	No	Optional workplace filter for the slice.

Output Schema

Name	Required	Description	Default
`total_jobs`	No
`top_companies`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 6, 2026

addedInput schema / properties / location

Added value: +{
+  "description": "Location substring for a market slice (e.g. San Francisco).",
+  "type": "string"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "Role or title filter for a market slice (e.g. product manager).",
+  "type": "string"
+}

addedInput schema / properties / workplace_type

Added value: +{
+  "description": "Optional workplace filter for the slice.",
+  "enum": [
+    "remote",
+    "hybrid",
+    "on_site"
+  ],
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false. The description adds real value beyond that by describing what comes back for each mode and flagging that salary signals only cover "listings that publish pay" — a meaningful coverage caveat.

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?

Three sentences, front-loaded with purpose and followed by the unfiltered-then-filtered call pattern in a logical order. The leading "Jobs —" restates the title in the description field, a minor redundancy.

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

Completeness4/5

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

An output schema exists, so return values need not be exhaustively explained, and the rich annotations carry the safety profile. The only gap is the unmentioned workplace_type parameter, which the schema covers but the prose ignores.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents query, location and the workplace_type enum; baseline is 3. The description reinforces query/location with the same examples found in the schema but never mentions workplace_type, adding little beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: "Returns aggregate job-market statistics from Worklittle." The aggregate/slice framing implicitly separates it from listing-oriented siblings like search_jobs, but no sibling is named explicitly, so it falls short of a 5.

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

Usage Guidelines4/5

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

Gives clear conditional guidance: call with no args for the full indexed market, pass query and location when the user names a role and/or city, with a worked example. It does not name an alternative tool or state when not to use this one, so no exclusion guidance.

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

All Worklittle Jobs tools Inspect

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

Need Help?