Open Economics

Search Brazilian official economic data

search_official_data

Read-onlyIdempotent

Start here for a natural-language Brazilian economic-information need in Portuguese or English. Resolves the economic concept independently of current coverage, returns ranked official datasets, stable-series shortcuts, confidence, missing source integrations, and an explicit unresolved/partial state. Use this before any data query when the exact official dataset ID is unknown.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum official dataset candidates to return.
`query`	Yes	The user's complete economic-data need, including measure, geography, period, and breakdown when known.

Output Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	The original natural-language economic need.
`concepts`	Yes	Ranked economic concepts matched to the request.
`datasets`	Yes	Ranked official datasets and their source identity.
`resolution`	Yes	Concept-resolution result.
`availability`	Yes	Coverage assessment.
`normalizedQuery`	Yes	Normalized form used for semantic resolution.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "description": "Semantic discovery result with ranked concepts, official datasets, and coverage state.",
+  "properties": {
+    "availability": {
+      "additionalProperties": {},
+      "description": "Coverage assessment.",
+      "properties": {
+        "complete": {
+          "description": "Whether the requested need is completely covered.",
+          "type": "boolean"
+        },
+        "explanation": {
+          "description": "Coverage explanation.",
+          "type": "string"
+        },
+        "missingSources": {
+          "description": "Required source integrations that are not present.",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "status": {
+          "description": "Availability state in the current Open Economics coverage.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "status",
+        "complete",
+        "explanation",
+        "missingSources"
+      ],
+      "type": "object"
+    },
+    "concepts": {
+      "description": "Ranked economic concepts matched to the request.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "id": {
+            "description": "Stable Open Economics concept ID.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "datasets": {
+      "description": "Ranked official datasets and their source identity.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "id": {
+            "description": "Stable official dataset ID.",
+            "type": "string"
+          },
+          "metadataUrl": {
+            "description": "Official metadata URL.",
+            "type": "string"
+          },
+          "provider": {
+            "description": "Open Economics provider identifier.",
+            "type": "string"
+          },
+          "sourceAgency": {
+            "description": "Official publishing agency.",
+            "type": "string"
+          },
+          "sourceUrl": {
+            "description": "Official source URL.",
+            "type": "string"
+          },
+          "title": {
+            "description": "Official dataset title.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "provider",
+          "sourceAgency",
+          "title",
+          "sourceUrl",
+          "metadataUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "normalizedQuery": {
+      "description": "Normalized form used for semantic resolution.",
+      "type": "string"
+    },
+    "query": {
+      "description": "The original natural-language economic need.",
+      "type": "string"
+    },
+    "resolution": {
+      "additionalProperties": {},
+      "description": "Concept-resolution result.",
+      "properties": {
+        "confidence": {
+          "description": "Resolution confidence from 0 to 1.",
+          "type": "number"
+        },
+        "explanation": {
+          "description": "Why the concept was or was not resolved.",
+          "type": "string"
+        },
+        "status": {
+          "description": "Resolution state for the requested concept.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "status",
+        "explanation"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "query",
+    "normalizedQuery",
+    "resolution",
+    "concepts",
+    "datasets",
+    "availability"
+  ],
+  "type": "object"
+}

First observedSep 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: ranking of candidates, confidence signal, reporting of missing source integrations, and an explicit unresolved/partial state that tells the agent results may be incomplete.

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?

Two dense sentences with zero filler, front-loaded with the 'start here' routing instruction and the query-language constraint. Every clause carries usable information.

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 the enumerated return contents (ranked datasets, confidence, unresolved state) are a bonus rather than a necessity, and annotations cover the safety profile. Nothing an agent needs to invoke this correctly is missing.

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 coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds meaningful semantics beyond the schema by specifying that the natural-language query is accepted in Portuguese or English, which is not stated 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 states a specific verb+resource ('search' Brazilian official economic data) and scopes it precisely as a natural-language concept resolver rather than a data fetch. 'Start here' plus the explicit unresolved/partial return state clearly separates it from the get_*_data siblings that require a known dataset ID.

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?

It gives a clear when-to-use rule: before any data query when the exact official dataset ID is unknown, and it accepts both Portuguese and English input. It does not explicitly name the follow-up sibling (e.g., describe_official_dataset) or state when NOT to use it, so it stops just short of full when/when-not/alternative coverage.

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

All Open Economics 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.