Skip to main content
Glama

Levels.fyi

get-salaries-by-company-level

Read-only

Get median (p50) yearly total compensation in USD for each internal level (e.g. Google L3/L4/L5, Meta E3/E4/E5) of up to 5 companies, for a job family in one location, from submissions in the last 12 months. Pass every company you are comparing in one call. Call get-company-levels first to learn each company's level names. A company must have a known level structure. Free limit: Total compensation per level for up to 5 companies per call, in one job family and location. No percentiles or counts. Pass canonical slugs (jobFamilySlug, locationSlug(s), countrySlug, companySlug(s)): resolve names first with search-job-families, search-locations and search-companies; never guess a slug. REQUIRED arguments: jobFamilySlug, locationSlug, companySlugs. Array-typed arguments (companySlugs) must be passed as arrays, even for a single value.

Input Schema

NameRequiredDescriptionDefault
companySlugsYesUp to 5 company slugs, compared in one call, e.g. ["google", "meta"]. Resolve each with search-companies first.
locationSlugYesOne location slug (metro, country or region; not a state or city), e.g. "san-francisco-bay-area". Resolve it with search-locations first; for a city, use its parent metro, and for a state, its metro or country.
jobFamilySlugYesA Levels.fyi job family slug, e.g. "software-engineer", "product-manager", "data-scientist".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / companySlug
      Removed value: -{
      -  "description": "A company slug, e.g. \"google\". Resolve it with search-companies first.",
      -  "example": "google",
      -  "type": "string"
      -}
    • addedInput schema / properties / companySlugs
      Added value: +{
      +  "description": "Up to 5 company slugs, compared in one call, e.g. [\"google\", \"meta\"]. Resolve each with search-companies first.",
      +  "example": [
      +    "google",
      +    "meta"
      +  ],
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • changedInput schema / properties / locationSlug / description
      Previous value: -"One location slug (metro, state, country or region; not a city), e.g. \"san-francisco-bay-area\". Resolve it with search-locations first; for a city, use its parent metro."New value: +"One location slug (metro, country or region; not a state or city), e.g. \"san-francisco-bay-area\". Resolve it with search-locations first; for a city, use its parent metro, and for a state, its metro or country."
    • changedInput schema / required
      Previous value: -[
      -  "jobFamilySlug",
      -  "locationSlug",
      -  "companySlug"
      -]New value: +[
      +  "jobFamilySlug",
      +  "locationSlug",
      +  "companySlugs"
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the read-only, non-destructive, closed-world profile, and the description adds substantive behavior on top: a 12-month lookback window on submissions, a 5-company cap, the free-tier limit, and an explicit statement that percentiles and counts are NOT returned. That tells the agent both what it gets and what it must not expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and prerequisite are well front-loaded, but the text repeats itself: the 5-company/one-job-family/one-location limit is stated three times, and the 'REQUIRED arguments' sentence simply restates the schema's required list. Trimming that redundancy would make the routing rules stand out more sharply.

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?

With no output schema, the description carries the burden of describing return content and does so (median yearly total comp in USD per level, no percentiles or counts). Prerequisites, snapshot window, limits and slug-resolution dependency are all present; an agent could call this correctly without opening the schema.

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 100%, so the baseline is 3; the description adds a bit by insisting on canonical slugs, warning never to guess one, and reminding that companySlugs must be passed as an array even for a single value. Most other parameter guidance (metro-not-city, resolve with search-companies) duplicates the schema descriptions, so the increment over structured fields is modest.

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 opening sentence names a specific verb and resource (median p50 yearly total compensation per internal level) and pins down scope: up to 5 companies, one job family, one location, last 12 months. It is clearly distinguishable from siblings like get-salary-percentiles (which adds percentiles/counts) and get-company-levels (which only returns level names).

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?

Explicit routing instructions are given: call get-company-levels first to learn level names, batch all compared companies into one call, and resolve slugs via search-job-families, search-locations and search-companies before calling. It also states a hard precondition (a company must have a known level structure) and the free-tier envelope, so when-to-use and when-not-to-use are both covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.