Skip to main content
Glama

worldgdp.org GDP nowcasts

get_companies

Listed companies in a GICS-aligned sector, industry group, industry or sub-industry (worldgdp.org classification from filed activity codes: SEC SIC codes for US listings, TSE 33 sectors for Japan, industry profiles for primary listings above $500m in ~35 other markets): name, ticker, exchange, company country, market cap (USD m), latest weekly price and currency, 3-month weekly closes. Pair with get_sectors to set survey readings next to the stocks they affect.

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": {
      "node": "<node>"
    },
    "name": "get_companies"
  }
}

Input Schema

NameRequiredDescriptionDefault
nodeYesGICS-aligned code ('45', '4530', '45301020') or name fragment ('semiconductors')
limitNo
marketNoall, or a company country code (US, JP, DE, UK, FR, CN, KR, IN, ...; EL = Greece)all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / market / description
      Added value: +"all, or a company country code (US, JP, DE, UK, FR, CN, KR, IN, ...; EL = Greece)"
    • removedInput schema / properties / market / enum
      Removed value: -[
      -  "all",
      -  "us",
      -  "jp"
      -]
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the load and does disclose meaningful behavior: how classification is derived per market (SEC SIC for US, TSE 33 for Japan, industry profiles for primary listings above $500m in ~35 other markets) and what units the numeric fields use (USD m, currency). It omits ordering, truncation/pagination behavior at the 500 limit, and error/no-match handling.

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?

Front-loaded with the core action and scope, and the second short sentence carries the routing advice. The long parenthetical about classification provenance is dense but earns its place by explaining why codes may differ across markets.

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?

There is no output schema, and the description compensates by listing returned fields and units, which is the main thing an agent would otherwise guess at. For a 3-parameter read tool it is nearly complete, lacking only limit/pagination semantics.

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 67%, so the schema already documents 'node' and 'market', and the description largely restates that codes are GICS-aligned while adding that 'market' spans ~35 non-US/JP markets with local classification sources. It adds no detail for 'limit' (no description in schema either) such as truncation or default behavior, so value beyond the schema is marginal.

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 (list) and resource (companies) scoped to a GICS-aligned node level, and enumerates the returned fields (name, ticker, exchange, country, market cap, weekly price, 3-month closes). It also names the sibling get_sectors as a companion, so an agent can place it in the toolkit without opening the schema.

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 closing sentence gives a concrete usage pattern: pair with get_sectors to put survey readings beside the affected stocks. There is no explicit when-not guidance or statement about what to do when a node matches nothing, so it falls 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.

Resources