Skip to main content
Glama

Profil firmy

get_company

Tryb darmowy czyta tylko to, co serwis już zna (sekcja spoza pamięci wraca jako "missing" z AUTH_REQUIRED); "id" to KRS, NIP, REGON, adres firmy.ai albo "p-…" osoby; zacznij od search_companies, gdy nie masz identyfikatora. Zwraca profil firmy i sekcje z "include" (bez "include": profile, people, ownership, ai_scores, description) w jednym wywołaniu oraz mapę "available", która mówi, co jeszcze można dopytać (finanse, dokumenty, VAT, sankcje, przetargi i inne). Sekcje do wyboru: profile, people, ownership, subsidiaries, group_structure, sole_proprietor, financials, documents, beneficial_owners, vat, bankruptcy, sanctions, knf_warnings, tenders, public_aid, domain, ai_scores, description, job_offers, foundation_spending, reviews, similar. Użyj, gdy masz KRS, NIP, REGON albo adres strony firmy; gdy masz tylko nazwę, najpierw search_companies. Koszt w trybie Pro (operacje za sekcję, która chybiła w pamięci serwisu): profile 3, subsidiaries 1, sole_proprietor 1, financials 20, documents 1, beneficial_owners 5, vat 1, bankruptcy 4, public_aid 1, domain 1, description 1, job_offers 1, foundation_spending 20; w trybie darmowym 0, a sekcja spoza pamięci wraca jako "missing" z AUTH_REQUIRED. Przykład: {"id": "0000006865", "include": ["financials", "vat", "sanctions"]}.

Input Schema

NameRequiredDescriptionDefault
idYesKRS (10 cyfr), NIP (także z myślnikami), REGON (9 albo 14 cyfr) albo adres strony firmy na firmy.ai (/KRS/…, /NIP/…). Serwer sam rozpoznaje typ.
freshNoPobierz ponownie mimo pamięci serwisu. W trybie darmowym zawsze AUTH_REQUIRED.
id_typeNoWymusza typ identyfikatora, gdy wiesz lepiej: krs, nip, regon albo person. Zwykle zbędne: serwer rozpoznaje typ sam.
includeNoKtóre sekcje zwrócić: profile, people, ownership, subsidiaries, group_structure, sole_proprietor, financials, documents, beneficial_owners, vat, bankruptcy, sanctions, knf_warnings, tenders, public_aid, domain, ai_scores, description, job_offers, foundation_spending, reviews, similar. Sekcja profile jest zawsze. Bez tego pola: profile, people, ownership, ai_scores, description.
estimateNoNic nie pobieraj, pokaż tylko, które sekcje są w pamięci i ile by kosztowały w trybie Pro.

Output Schema

NameRequiredDescriptionDefault
urlYes
vatNo
modeYes
as_ofYes
domainNo
peopleNo
sourceYes
profileNo
reviewsNo
similarNo
tendersNo
estimateNo
includedYes
ai_scoresNo
availableYes
documentsNo
ownershipNo
sanctionsNo
bankruptcyNo
financialsNo
job_offersNo
public_aidNo
descriptionNo
id_resolvedYes
knf_warningsNo
subsidiariesNo
group_structureNo
sole_proprietorNo
beneficial_ownersNo
foundation_spendingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing free-mode limitations (sections outside cache return 'missing' with AUTH_REQUIRED), per-section Pro-mode costs, default included sections, and the 'available' map listing additional queryable data. These are critical operational details not covered by annotations.

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

Conciseness3/5

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

The description is dense and lengthy, repeating the full section list twice and embedding cost details in a long paragraph. It is not front-loaded: the primary purpose is stated only after free-mode edge cases. Bullet points or tighter grouping would improve scanability.

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?

Given the tool's complexity, the description is thorough: it covers usage prerequisites, mode differences, section defaults, cost model, identifier types, and a sample call. An output schema exists, so return values need not be detailed further; nothing crucial is missing.

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 description coverage is 100%, so the baseline is 3; however, the description adds meaningful context by noting that 'id' can also be a person ID ('p-…') and provides a concrete example. It also repeats default include behavior already in the schema, but the extra person-ID and example justify a 4.

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 and resource: returns a company profile plus selected sections via 'include'. Distinguishes from siblings by naming search_companies when no identifier exists and acknowledging person IDs ('p-…') that route to get_person.

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

Usage Guidelines5/5

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

Explicitly says to use this tool when you have KRS, NIP, REGON, or a firm website address, and to call search_companies first when you only have a name. Also clarifies free vs Pro mode behavior and the purpose of 'estimate' and 'fresh'.

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