Skip to main content
Glama

list_common_soc_codes

Read-only

List common SOC code mappings for federal IT and professional services.

Use these codes with get_wage_data() and other tools. SOC codes are
6 digits without a dash (e.g., '151252' not '15-1252').

For the full SOC list: https://www.bls.gov/oes/current/oes_stru.htm

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_common_soc_codes"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral detail not in the structured fields: the required code format ('151252' not '15-1252'), which prevents a downstream invocation error in get_wage_data. It doesn't say how many codes are returned, but the output schema covers the shape.

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 blocks with zero filler: purpose first, usage and format constraint second, external reference last. Every sentence carries actionable information for an agent.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. What remains — purpose, downstream use, and the critical no-dash six-digit format — is all present, which is complete for a parameterless reference-list tool.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description does not waste space restating an empty schema.

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 ('List common SOC code mappings') and narrows scope to 'federal IT and professional services'. The pointer to the full BLS SOC list implicitly distinguishes this curated subset from a complete enumeration, though it never names the parallel sibling list_common_metros or explains the curation boundary explicitly.

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?

'Use these codes with get_wage_data() and other tools' gives clear downstream usage context, which is exactly what an agent needs for a lookup table. It does not state when *not* to call it (e.g., if you already have a code) or contrast it with siblings, so it stops short of a 5.

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.