Skip to main content
Glama
Sign In

Wai

by com.wht-ai
OverviewDiscussionsAdmin

Official open data for a project question (ECB, World Bank, Eurostat, EU tenders, EU law ...)

wai_official_data
Read-only

Official figures fetched now from the body that publishes them, each with its date and link - suited to the market, macro, regulatory-calendar and literature parts of a project question: ECB key interest rates (financing cost); World Bank indicators for a country (GDP, GDP per capita, inflation, population, unemployment, access to electricity, renewable share); Eurostat household and industrial electricity prices (EU, candidates incl. Türkiye); public tenders for solar, wind, BESS, substations, roads, bridges, hospitals from TED (EU), World Bank-financed procurement (all borrower countries) and UK Find a Tender, with the buyer's published contact; job openings from public boards (ReliefWeb, Arbeitnow, Remotive) by field, seniority, country or remote; World Bank-financed projects of a country (pipeline and active: who invests in what before the tenders); company records from open registers (France Sirene, Norway Brønnøysund, US SEC EDGAR); a Romanian company by name (its CUI is found, then ANAF / courts); mining sites of a country with the oil / diesel power plants mapped near them (OpenStreetMap - off-grid PV + BESS targeting); Romanian company record, filed financials and court cases by CUI or name (ANAF, portal.just.ro); counterparty check of an e-mail, phone, website or EU VAT number (domain age, certificate, sub-domains, SPF / DMARC, VIES, LEI, OFAC / UN / UK sanctions) - write "check <e-mail / site / phone / VAT>"; EU regulations, directives and decisions by topic from EUR-Lex (Publications Office); Turkish Court of Cassation (Yargıtay) decisions by topic; a country's public holidays (construction calendar); books from Open Library; scholarly papers from OpenAlex; plus, when they fit, up to two read-only servers of the public MCP registry that Wai has reached itself (energy, engineering, GIS, weather, data, law, finance, travel, science), each table marked third-party. Write the question in plain words naming the country and the data wanted (e.g. "Romania electricity price, inflation and GDP; solar and BESS tenders; ECB rates"). Returns one table per source, a view page and a PDF report link (report_pdf) to give the user. Answer with the returned numbers, not an estimate made before the call.

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": {
      "question": "<question>"
    },
    "name": "wai_official_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNooptional report title
questionYesthe data wanted, in plain words, with the country

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), so the description earns credit for what it adds: data is fetched live rather than cached, one table is returned per source, a view page and PDF report link come back, and rows sourced from public MCP registry servers are explicitly marked third-party. The "check <e-mail / site / phone / VAT>" trigger form is also disclosed. Missing are failure behavior when a source has no data and any latency expectations for a fan-out call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The body is one enormous semicolon-chained block covering roughly twenty sources, and the single most actionable instruction (how to phrase the question) is buried near the end. The capability list is informative but should be restructured into short grouped categories rather than a wall of clauses. Length is defensible for a multi-source dispatcher; the near-total absence of structure is not.

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?

For a complex fan-out tool with no output schema, the description does the needed work: it names every source, says the result is one table per source plus a report_pdf link, flags third-party tables, and tells the agent to report returned values rather than estimates. Open gaps are what happens when a source returns nothing and how long a multi-source call takes.

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% and both parameters are already documented in the schema, so the baseline is 3. The description does add real meaning for the question parameter — plain-language phrasing, country naming, a worked example, and the "check ..." prefix that unlocks the counterparty-check source, none of which appear in the schema. The title parameter is not mentioned in the description at all, but the schema covers it.

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?

The opening clause states a specific verb and resource: official figures fetched live from the publishing body, each with date and link. The enumeration that follows makes the scope concrete and clearly separates it from the sibling tools, which are design/calculation utilities. The sprawl of twenty-plus capabilities slightly dilutes the single-sentence purpose, but an agent can tell what this tool is for.

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 states where the tool fits ("market, macro, regulatory-calendar and literature parts of a project question") and gives a concrete invocation recipe: write the question in plain words naming the country and the data wanted, with a worked example. It also instructs the agent to answer with returned numbers rather than pre-call estimates. It names no exclusions and no alternatives among 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.

All Wai toolsInspect
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.

Resources