Bls

Bls Latest

bls_latest

Read-onlyIdempotent

Get the most recent data point for a BLS series. Returns latest value and date. Use when you need current figures without historical context.

Input Schema

Name	Required	Description	Default
`_apiKey`	No	BLS registration key (optional)
`series_id`	Yes	BLS series ID (e.g., "LNS14000000")

Output Schema

Name	Required	Description
`title`	No	Series title from catalog, or null if not found
`latest`	No	Most recent data point
`status`	No
`series_id`	No	BLS series identifier

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 2, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "_apiKey": "your-bls-api-key",
-    "series_id": "LNS14000000"
-  }
-]New value: +[
+  {
+    "series_id": "LNS14000000"
+  }
+]

addedOutput schema / properties / latest / properties / date
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / latest / required

Removed value: -[
-  "year",
-  "period",
-  "period_name",
-  "value"
-]

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / title / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

removedOutput schema / required

Removed value: -[
-  "series_id",
-  "title",
-  "latest"
-]

Changed1 schema field changedMay 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "latest": {
+      "description": "Most recent data point",
+      "properties": {
+        "period": {
+          "description": "Period code (e.g., M01 for January)",
+          "type": "string"
+        },
+        "period_name": {
+          "description": "Human-readable period name",
+          "type": "string"
+        },
+        "value": {
+          "description": "Latest value",
+          "type": "string"
+        },
+        "year": {
+          "description": "Year of the latest data point",
+          "type": "string"
+        }
+      },
+      "required": [
+        "year",
+        "period",
+        "period_name",
+        "value"
+      ],
+      "type": "object"
+    },
+    "series_id": {
+      "description": "BLS series identifier",
+      "type": "string"
+    },
+    "title": {
+      "description": "Series title from catalog, or null if not found",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "series_id",
+    "title",
+    "latest"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "_apiKey": "your-bls-api-key",
+    "series_id": "LNS14000000"
+  }
+]

First observedApr 22, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds only that it returns latest value and date, which is largely redundant given the output schema; no rate-limit, missing-series, or freshness caveats are disclosed. Adequate but not rich.

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 sentences, zero waste, with the core action and return value front-loaded before the usage hint. Nothing could be cut without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, full schema coverage, and rich annotations, the description is nearly complete; an agent can call it correctly. Minor gaps around empty/missing-series behavior keep it from a 5, but those are edge concerns for a simple read tool.

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 coverage is 100% with only two params, so the schema fully documents series_id and _apiKey. The description adds no meaning beyond the schema (e.g., series ID format or optional key behavior), so the baseline 3 applies.

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 ("Get the most recent data point for a BLS series") plus what is returned, which is clear and distinguishable in scope from historical tools. It does not explicitly name the sibling bls_get_series, leaving differentiation to inference, so it falls short of a 5.

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 when you need current figures without historical context" gives a clear selection condition that implicitly contrasts with history-returning siblings. No explicit when-not or named alternative, so it's a 4 rather than a 5.

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

All Bls tools Inspect

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.