Skip to main content
Glama

Estimate a company's revenue from its headcount

companies_estimate
Read-onlyIdempotent

An estimate for a company that files no revenue, always labeled as one: employees x Eurostat's net turnover per person employed for its size class (by NACE group) where Eurostat publishes it, else for its industry (by NACE class), in its EU or EEA country, with both figures, the year and the datasets. Never mixed into filed figures. companies_get gives the industry code and, where published, the employees. Free.

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": {
      "employees": "<employees>",
      "industry": "<industry>",
      "country": "<country>"
    },
    "name": "companies_estimate"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoThe statistics' year; the latest published when left out.
countryYesTwo letters, e.g. DE.
industryYesA NACE Rev. 2 code such as 46.69 (a French NAF code like 46.69C works too); for an industry on NACE Rev. 2.1, one of its rev2 codes.
employeesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive behavior. The description adds the actual derivation logic, Eurostat fallback by size class versus industry, EU/EEA geographic scope, output contents, and the requirement that the figure is always labeled as an estimate.

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?

The description is dense but front-loaded, covering formula, fallback, output, and sibling routing in a short block. The long formula sentence is slightly hard to parse, but no sentence is wasted.

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?

With no output schema, the description still explains that both figures, the year, and the datasets are returned, and it covers the key edge case that the company files no revenue. This is complete enough for an estimation tool.

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?

The schema documents year, country, and industry, while the description gives employees a clear semantic role as the multiplier and ties industry/country to NACE and EU/EEA scope. The one property without a schema description, employees, is at least explained functionally, though not with format details.

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 title and opening sentence name a specific operation (estimating revenue) and resource (a company with no filed revenue), and the formula is stated. It is clearly distinguishable from companies_get, which supplies the inputs.

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 the key condition (a company that files no revenue), explicitly says not to mix the output with filed figures, and names companies_get as the source of industry code and employees. This is clear routing, though not a full when-to-use/when-not-to-use table.

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