Skip to main content
Glama
Sign In
mcp-lightcast

mcp-lightcast

by lawwu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Query Core Lmi

query_core_lmi
Read-onlyIdempotent

Query employment, wage, education, and other Core LMI measures by dataset, metrics, and dimension codes. Returns column-oriented rows with sorting, aggregation, and bounded pagination for labor market analysis.

Instructions

Query employment, wages, education or other Core LMI measures using discovered metrics and dimension codes. Read-only POST; consumes quota. Supports named aggregations, mapLevel, LocationQuotient, ShiftShare, sorting and bounded pagination (100 rows default, 500 maximum per page, first 5000 rows accessible). data is column-oriented: combine values at matching row indices. Preserve returned version and upstream metadata; missing/suppressed values are not zero. Use sortBy for repeatable pages. Offset is applied locally to a bounded prefix because the service ignores native offset. Follow pagination.next_offset; narrow the query if has_more is true at window_limit. totalRows is upstream metadata, not a grand total.

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": {
      "dataset": "<dataset>",
      "query": "<query>"
    },
    "name": "query_core_lmi"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes
datasetYes
versionNolatest

Output Schema

NameRequiredDescriptionDefault
dataYes
errorsYes
datasetYes
timingsYes
versionYes
totalRowsYes
paginationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial non-obvious behavior: it is a read-only POST that consumes quota, pagination is bounded (100 default, 500 max, 5000 accessible), offset is applied locally because the service ignores native offset, data is column-oriented, and missing/suppressed values are not zero. This is exactly the kind of context annotations cannot convey.

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?

Dense and front-loaded, leading with purpose then operational constraints. Nearly every sentence carries distinct information, though the run of terse clauses (column orientation, version metadata, totalRows) is packed tightly and could be slightly better grouped for scanning.

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 complex nested-parameter query tool with an output schema, the description covers the critical gotchas an agent needs: quota cost, pagination window and next_offset, local offset application, column-oriented results, and that totalRows is not a grand total. Return-value detail is appropriately left to the output 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 description coverage is reported as 0%, so the description must compensate, and it does: it explains limit/offset bounds and the local-offset quirk, sortBy's role for repeatable paging, and names mapLevel, LocationQuotient, ShiftShare and named aggregations. It does not fully document every nested field (e.g. asIdentity, base, along), leaving some gaps, but adds meaningful semantics beyond the raw 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?

States a specific verb (Query) and resource (Core LMI measures: employment, wages, education) and scopes it to 'discovered metrics and dimension codes', which implicitly separates it from the discovery siblings like get_core_lmi_dimension and get_core_lmi_metadata. An agent can tell this is the execution/query tool versus the metadata tools.

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 phrase 'using discovered metrics and dimension codes' signals the prerequisite discovery step, and it gives concrete operational guidance (use sortBy for repeatable pages, follow pagination.next_offset, narrow the query when has_more is true). It stops short of explicitly naming the sibling discovery tools or stating when-not to use it, so it is clear context without full alternative routing.

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

Deploy Server

Other Tools