Skip to main content
Glama

finwire.pl - Polish financial data

Housing loan market

get_credit_market
Read-onlyIdempotent

Polish housing loan market: topic "index" (finwire 0-100 credit market index), "survey" (NBP bank lending survey: criteria and demand), "monetary" (NBP household loans and deposits, new housing loans).

Input Schema

NameRequiredDescriptionDefault
topicNoDefault index.

Output Schema

NameRequiredDescriptionDefault
urlYes
asOfNo
dataNo
titleYes
sourceYes
docsUrlYes
licenseYes
summaryYes
citationYes
datasetIdYes
sourceUrlNo
truncatedNo
serverDateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful domain context (0-100 scale for the finwire index, NBP as the survey source), but says nothing about update frequency, coverage period, or units beyond the index.

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?

A single front-loaded sentence identifies the market, then enumerates the topics with parenthetical explanations. Dense and waste-free; the nested quotes around topic values read slightly awkwardly but cost nothing.

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?

With one optional enum parameter at full coverage, read-only annotations, and an output schema, the description carries the needed burden for topic selection. The remaining gap is sibling disambiguation, which is the main risk for an agent choosing among 21 macro/housing tools.

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% and the enum's only schema gloss is 'Default index.', so the description is doing real work by explaining what each of the three topic values actually returns. That is meaningful value beyond the structured field, though it omits the default's implications and any output-shape hints.

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?

States a specific verb+resource (get the Polish housing loan market) and enumerates the three data topics it covers, so the agent knows exactly what data comes back. It does not differentiate itself from near-siblings such as get_bank_rates, get_housing_prices, or get_interest_rates, which overlap thematically.

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

Usage Guidelines3/5

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

Usage is only implied by the enum breakdown: an agent can infer 'index' for credit conditions, 'survey' for lending criteria/demand, 'monetary' for loan and deposit volumes. There is no explicit when-to-use or when-to-prefer-a-sibling guidance, which matters given 21 related financial-data tools.

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.