Skip to main content
Glama

Quera job salaries

qr_salaries
Read-onlyIdempotent

Summarize salaries published in open Quera job postings by seniority level, with city, level, and technology filters, to estimate monthly pay in Toman.

Instructions

Summarize the salaries employers published in open Quera jobs, grouped by seniority level (Toman per month).

Use for 'how much does a junior Python developer earn'. Only postings that show a salary count (a minority: see jobs_with_salary against jobs_total), so treat it as a rough sample, not a market survey. Call qr_jobs with order='high_salary' for the postings behind it.

Input Schema

NameRequiredDescriptionDefault
cityNoCity name or id, as for qr_jobs.
levelNoSeniority filter.
technologiesNoTech codes, e.g. 'python'; several mean any of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new context: the coverage bias (only salary-showing postings), the unit and period, and the aggregation grouping. It does not disclose the aggregation statistic itself — median vs. mean vs. range — which materially affects how the numbers should be reported.

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?

Three short sentences, each doing distinct work: what it returns, when to use it with a caveat, and where to drill down. The core output definition is front-loaded with no redundant restatement of the title.

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?

With no output schema, the description carries the burden of describing returns and it does specify grouping and unit, which is the essential shape. It stops short of describing the statistic or output fields, so an agent still cannot predict exactly what numbers it will receive.

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 parameters are already documented, including the any-of semantics for technologies and the enum values for level. The description adds only the output unit and the cross-reference that city behaves 'as for qr_jobs,' which is marginal on top of the schema.

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 ('Summarize the salaries employers published in open Quera jobs'), adds the grouping key (seniority level) and the unit (Toman per month). It also distinguishes itself from the qr_jobs sibling by pointing to it as the raw-postings source.

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 gives a concrete trigger phrase ('how much does a junior Python developer earn') plus an explicit caveat that only a minority of postings list salaries, framing the output as a rough sample. The final sentence routes the agent to qr_jobs with order='high_salary' when it needs the underlying postings instead of the aggregate.

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