Skip to main content
Glama

Gov Finland Prh

gov_finland_prh
Read-only

Finnish company register (PRH / YTJ) record by Business ID: registration date, status code, company form, main business line, names with dates and addresses. Registry data as published by PRH; codes are passed through raw. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Input Schema

NameRequiredDescriptionDefault
businessIdYesFinnish Business ID, 7 digits, hyphen, check digit, e.g. 0194099-3

Output Schema

NameRequiredDescriptionDefault
namesNo
sourceNo
addressesNo
checkedAtNo
businessIdNo
statusCodeNo
companyFormNo
mainBusinessLineNo
registrationDateNo

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?

With readOnlyHint and openWorldHint already declared, the description still adds genuinely useful operational context: a pay-per-call model ($0.002 USDC via x402, multiple chains) and, crucially, that failed calls are not charged. It also discloses that registry codes are passed through raw rather than normalized, which affects how results must be interpreted.

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 sentences, the resource and lookup key are front-loaded, and the second sentence carries only high-value information: provenance, raw-code behavior, and pricing/charging terms. No filler.

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?

An output schema exists, so return values needn't be explained, and pricing/auth semantics are covered. The remaining gap is sibling differentiation against the other Finnish company tool, which matters given how many overlapping registry tools exist in this set.

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 the sole parameter already documents the 7-digit, hyphenated, check-digit format with an example. The description adds nothing beyond the businessId concept already named in the schema, so 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?

The description states a specific verb and resource: a Finnish company register (PRH/YTJ) record looked up by Business ID, plus the exact fields returned. It is clear what the tool does, but it never distinguishes itself from the near-identical sibling b2b_finland_ytj_companies, which an agent would naturally compare against.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to use this tool versus alternatives, and in particular no hint about why one would pick it over b2b_finland_ytj_companies or b2b_brreg_norway_companies. Usage is only implied by 'record by Business ID'.

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