Skip to main content
Glama
Sign In

Worth Leaving

by com.worthleaving
OverviewDiscussionsAdmin

Market base pay check

check_market_base_pay
Read-onlyIdempotent

What a role and level earns in a US metro: median base salary from public US government data (H-1B filings and the BLS wage survey), with the middle half, the source and its date, and how a given base compares. Base pay only, equity and bonus excluded; an estimate, not a verdict, and it does not change compute_walk_away_verdict. Use it when the person asks whether their pay is at market, before or after the verdict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "role": "<role>",
      "level": "<level>",
      "metro": "<metro>"
    },
    "name": "check_market_base_pay"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoCurrent annual base salary in dollars; with it the result says how it compares to the median
roleYesRole id: swe (Software engineer), ml (ML or AI engineer), research (Research scientist), postdoc (Postdoc / academic to industry), data_sci (Data scientist), data_eng (Data engineer), sre (SRE or infrastructure), em (Engineering manager), pm (Product manager), designer (Product designer), other (Other)
levelYesLevel id: junior (Junior), mid (Mid), senior (Senior), staff (Staff), principal (Principal or above)
metroYesMetro id such as "us-sfo", "us-sea", "us-nyc"; "remote-us" has no data

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds behavior beyond that: the data sources and their vintage ('the source and its date'), the reported range ('the middle half'), the exclusion of equity and bonus, and the epistemic caveat that this is 'an estimate, not a verdict'. It does not discuss resolution or coverage gaps in metro data beyond briefly noting a parameter constraint.

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?

The functional payload — what is returned, from where, with what caveats, and when to call it — is front-loaded in the first clause. It is dense but nearly every clause earns its place; the one mild redundancy is restating the base-pay-only scope that the schema also constrains.

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?

There is no output schema, so the description must describe return content, and it does: median, middle half, source and its date, and a comparison against a supplied base. Combined with the estimate caveat, the exclusion of equity/bonus, and the relationship to the sibling verdict tool, an agent has everything needed to call and interpret it.

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% and two enumerated parameters are fully documented in the schema, so the baseline is 3. The description only lightly echoes the optional base parameter ('how a given base compares') without adding format or boundary guidance beyond what the schema already states.

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?

States a specific verb and resource — median base salary for a role and level in a US metro — plus the exact data provenance (H-1B filings and BLS wage survey). It also delimits scope against the only sibling by saying it does not change compute_walk_away_verdict, so an agent can separate the two without opening either schema.

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 an explicit trigger: 'Use it when the person asks whether their pay is at market, before or after the verdict.' It also bounds the tool ('Base pay only, equity and bonus excluded') and states it is not a verdict. It stops short of naming a case where a different tool should be used instead, so it is clear context rather than full when/when-not routing.

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

All Worth Leaving toolsInspect
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