Skip to main content
Glama

Levels.fyi

get-available-filters

Read-only

List which inputs and filter values the free tier can use. The free inputs are jobFamilySlug, one locationSlug or countrySlug, and companySlug; every result is total compensation from the last 12 months. Dimensions marked free: false (levels, years of experience, focus areas, titles, company size, funding stage, revenue, valuation, work arrangement, offer vs employee) are not accepted by any tool here. Call this before building a query if unsure what a tool accepts.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover read-only safety, so the description adds valuable behavioral context: it enumerates free inputs, specifies a 12-month data scope, and clarifies that certain dimensions are not accepted by any tool here. It stops short of describing return format or pagination, but those are less critical for a parameter-free discovery tool.

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 two sentences, front-loaded with the core purpose, then efficiently packs essential details about free inputs, exclusions, and when to call it. Every sentence earns its place with no redundancy.

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?

Given there is no output schema and no parameters, the description effectively communicates what the tool returns (free input list and non-free dimensions) and the data scope (total compensation from last 12 months). An agent has enough information to call it correctly and interpret the result.

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?

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and it actually provides useful meta-information about accepted inputs across the toolset, which enhances understanding without being redundant.

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 specifically states the tool lists available inputs and filter values for the free tier, with clear examples of free and non-free dimensions. This distinguishes it from all sibling tools, which either query data or manage entities, by making it an explicit discovery mechanism for accepted parameters.

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 says to call this before building a query if unsure what a tool accepts, which is a clear when-to-use directive. The implication is that it need not be called when the agent already knows accepted inputs, providing adequate when-not guidance.

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.