Skip to main content
Glama

Skill Geographic Concentration

jobs_concentration
Read-onlyIdempotent

HHI-based geographic concentration for a skill. Returns hhi_score (0-100), band (diffuse → dominant), and top N metros with their job-count share. Answers 'where does the candidate pool live?'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skillYes
top_nNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark it read-only, idempotent, open-world, and non-destructive, so the description does not need to cover safety. It adds useful behavioral detail beyond annotations: the HHI methodology, numeric score range 0-100, band scale from diffuse to dominant, and inclusion of top-N metros with job-count share. No contradictions found.

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 purposeful sentences: definition, return payload, and use case. The key analytic content is front-loaded and every sentence adds information without 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?

For a two-parameter read-only tool with no output schema, the description sufficiently documents the input purpose, the output fields, and the interpretation ('diffuse → dominant'). No critical missing context is apparent.

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 description coverage is 0%, so the description carries the burden. It links 'for a skill' to the required skill parameter and 'top N metros' to the top_n parameter, adding meaning that the bare schema properties lack. It does not restate default/min/max, but those are already in 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 names a specific analysis ('HHI-based geographic concentration'), identifies the resource (a skill), and enumerates concrete outputs (hhi_score, band, top N metros with job-count share). It also frames the purpose with a direct question ('where does the candidate pool live?'), which clearly distinguishes it from sibling jobs_* tools like jobs_scarcity or jobs_momentum.

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?

The description gives a clear use case via the question 'where does the candidate pool live?' and indicates the tool is for geographic concentration of a skill. It does not explicitly state when not to use it or name alternative tools, 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.

TDQS

B3.2/5.0
Disambiguation2/5

Multiple tools have genuinely blurry boundaries: company_change vs company_changes differ only by singular/plural yet serve different purposes, company_domain vs company_classify vs company_lookup_auto all accept a domain, geo_zip_lookup vs geo_enrich vs geo_zip_batch all return ZIP profiles, and email_validate subsumes much of email_disposable and email_free_provider. The domain prefixes help narrow search space, but within many domains an agent cannot reliably predict which tool is the right one.

Naming Consistency4/5

All 129 tools uniformly follow a snake_case [domain]_[topic] convention (company_, fx_, geo_, dns_, weather_, tax_), which is highly predictable and consistent. Minor deviations include the confusing company_change/company_changes pair, and inconsistent suffix usage (_batch appears on address_validate_batch, company_domains_batch, geo_zip_batch but not on equivalent lookup tools elsewhere).

Tool Count1/5

129 tools far exceeds the 50+ extreem-mismatch threshold, bundling roughly 28 unrelated data domains (weather, fx, tax, ccompany, dns, jobs, flight, email, phone, tax...) into a single MCP surface. Even focusing on one domain forces the agent to load an enormous unrelated tool list; this should be split into many smaller domain-specific servers.

Completeness4/5

Per-domain coverage is impressively thorough: weather spans current/forecast/hourly/historical/normals/marine/route/air-quality, fx covers rates/convert/historical/volatility/correlation/strenth, and company includes lookup/enrichment/networks/timeline/peer-comparison plus six buyer-tuned signals with profile-introspection tools. Minor gaps like flight being historical-only and smtp probes skipping major email providers are documented scope decisions rather than dead ends.

Resources