Austrian Firmenbuch
Server Details
Austria's official company register (Firmenbuch) – master data, financials & ratios for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 11 of 11 tools scored. Lowest: 2.2/5.
Each tool has a distinct, non-overlapping purpose: field discovery, search, details, full records, history, documents, peer comparison, cohort summary, taxonomy, coverage, and usage. Descriptions clearly differentiate them.
Most names follow 'verb_noun' pattern, but verbs vary (describe_*, find_*, get_*, list_*, search_*). While readable and descriptive, full consistency would require a single prefix style.
With 11 tools covering search, details, history, documents, comparisons, aggregates, taxonomy, and more, the count is well-scoped for the domain. No superfluous or missing essential operations.
The tool set covers the full lifecycle of querying the Austrian Firmenbuch: discovery, search, detailed retrieval, historical trends, document access, and analytics (peers, cohorts). No obvious gaps for a read-only data source.
Available Tools
11 toolsdescribe_fieldsAInspect
Catalog of every field the server can return, by tool tier (search card → full profile → full record), with code tables and availability/null rules. Call this to discover the full data shape before deciding which tool to use. Human-readable version: https://www.agentic-firmenbuch.at/felder.html
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adequately describes the output (catalog of fields, code tables, availability/null rules) but does not explicitly state that the tool is read-only or has no side effects. While the nature implies idempotency, explicit disclosure would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences plus a URL. The first sentence defines the tool's purpose and output structure; the second provides usage guidance and a reference. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description covers all necessary aspects: purpose, output content (by tool tier, code tables, null rules), and usage guidance. It also offers a human-readable alternative, making it fully complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so by guideline the baseline score is 4. The description adds no parameter information because none exists, which is appropriate. No further compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a catalog of every field the server can return, organized by tool tier, with code tables and null rules. This is a specific verb-resource pair that distinguishes it from sibling tools, which focus on searching, listing, or retrieving company data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool 'before deciding which tool to use' for data shape discovery. It provides clear context for when to use it, though it does not explicitly mention when not to use or name alternatives. The human-readable URL adds value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_peersCInspect
Nearest companies by Bilanzsumme within the same size class.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| fnr | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry transparency burden. It only states the selection criteria but omits behavioral aspects like sorting order, limits, or idempotency. Missing details on what 'nearest' means or whether it's a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with no wasted words. However, it sacrifices informativeness for brevity; could benefit from a second sentence for key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and limited description, the tool's context is insufficient. Does not explain the output schema (even though one exists), how results are ordered, or edge cases. Agent would struggle to infer correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%: description does not explain the 'fnr' (required) or 'n' (optional) parameters. It only provides context about the overall output, failing to add meaning beyond the schema. No examples or detailed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds 'nearest companies by Bilanzsumme within the same size class', specifying the resource (peers) and criteria. However, it does not explicitly differentiate from similar sibling tools like search_companies or get_cohort_summary, missing a chance to clarify unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For a tool with many siblings (search_companies, get_cohort_summary), it fails to indicate typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cohort_summaryCInspect
Aggregate summary for a cohort (gkl / bundesland / legal_form).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| dimension | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions aggregate summary but does not disclose behavioral traits such as idempotency, rate limits, or what operations are performed. Lacks detail on return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (one sentence) but lacks necessary details. It is concise but under-specified, wasting the opportunity to add value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are not needed. However, the description fails to explain parameter meaning and usage context, which is critical for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only gives examples of cohort types (gkl, bundesland, legal_form) without explaining that 'dimension' selects the type and 'value' specifies the identifier. Parameters remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates summary for a cohort, with examples (gkl, bundesland, legal_form), making the purpose understandable. It differentiates from siblings implicitly by focusing on cohort aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like describe_fields or find_peers. The description does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_detailsCInspect
Full served profile for one company by FNR (identity, location, financials with per-year Bilanz + GuV, all ratios, growth, employees, filings, management). Field reference: https://www.agentic-firmenbuch.at/felder.html
| Name | Required | Description | Default |
|---|---|---|---|
| fnr | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It lists included data categories and provides a field reference URL, but does not disclose data freshness, rate limits, authentication needs, or whether the operation is read-only. For a heavy data retrieval tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a link, efficiently conveying the tool's purpose and scope. It is front-loaded with the key function. However, it could be structured to list components more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (reducing the need to explain return values), the description covers the main data categories and links to a field reference. However, it lacks usage context, prerequisites, and differentiation from siblings, which would be expected for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only mentions 'by FNR' without explaining what FNR is or its expected format. The field reference URL does not cover the input parameter. The description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a full profile for one company by FNR, listing specific components. It is specific about the resource and verb, but does not explicitly differentiate from sibling tools like 'get_full_record', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The description is purely declarative without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_historyCInspect
Per-metric time series for one company.
| Name | Required | Description | Default |
|---|---|---|---|
| fnr | Yes | ||
| metrics | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'time series' but does not mention read-only nature, required authentication, output format, or pagination. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise. However, it lacks structure (e.g., sections) and could benefit from more details without being verbose. It is under-specified for a 2-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given parameter count (2), no annotations, and presence of an output schema, the description should explain fnr and metrics. It does not, leaving significant gaps. The output schema may compensate partially, but description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds no meaning to parameters. 'fnr' is unexplained (likely a company ID) and 'metrics' is only hinted at by 'Per-metric.' No details on valid metric values or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'time series for one company,' hinting at historical data per metric. However, 'Per-metric' is ambiguous as the schema allows multiple metrics. It distinguishes from siblings like get_company_details but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_company_details or get_cohort_summary. The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverageAInspect
Internal coverage dashboard: XML vs PDF-only vs none, by format/status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only hints at the dashboard nature but omits details like data freshness, authorization, or side effects. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to purpose clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is an output schema and no parameters, the description is vague about what 'coverage' means. It assumes domain knowledge (e.g., XML vs PDF-only vs none) without elaboration, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain parameter semantics. Baseline for no parameters is 4, and the description adds no parameter-related value, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an 'Internal coverage dashboard' that categorizes coverage as 'XML vs PDF-only vs none, by format/status.' This specific verb-resource combination distinguishes it from sibling tools like get_document or get_full_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentAInspect
Get a time-limited download link to a company's official Jahresabschluss document.
Pass a filing's document_ref ("{fnr}:{stichtag}") from get_company_details, a bare FNR
(→ latest filing), or a legacy doc_key. Returns download.url (a short-lived signed link
— open it, don't expect bytes inline) plus the FI flag + caveat for banks/insurers, whose
figures live only in the PDF. download is null if nothing is ingested for that filing.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_key | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that the download link is time-limited, explains the return structure (download.url as a short-lived signed link, not inline bytes), mentions the FI flag and caveat for banks/insurers, and clarifies that download is null if nothing is ingested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose and then providing necessary details in a single paragraph. Every sentence adds value, though the density could be slightly improved with line breaks for readability. However, it is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema (partially described), the description covers all essential aspects: input formats, core behavior, key output fields (download.url, FI flag, caveat), and edge cases (null download). It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'doc_key' with no description (0% schema coverage). The description compensates completely by explaining that doc_key can be a document_ref from get_company_details, a bare FNR, or a legacy doc_key, providing essential semantics missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a time-limited download link to a company's official Jahresabschluss document.' It specifies the action (get a download link) and the resource (Jahresabschluss document), and distinguishes from siblings by detailing input formats like document_ref, FNR, and legacy doc_key, linking to get_company_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains what inputs are valid (document_ref, FNR, legacy doc_key) and when download may be null. It also notes a caveat for banks/insurers. However, it does not explicitly state when not to use this tool or compare alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_full_recordAInspect
Complete per-company record (superset of the served profile): every position's full history, unknown-code passthrough, completeness, guv_years (§5.1).
| Name | Required | Description | Default |
|---|---|---|---|
| fnr | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavioral traits: it returns a superset record, includes unknown-code passthrough and completeness, and references guv_years. No side effects or auth needs are mentioned, but for a read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the main purpose and using every phrase to add value. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one required parameter) and presence of output schema, the description covers the essential behavior. The parameter is not explained, but the overall functionality is clear. Could be more complete by describing the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has one required parameter (fnr) with 0% schema description coverage. The description does not explain what fnr is or its format, relying on context from the tool name. With no schema descriptions, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a complete per-company record, specifying it's a superset of the served profile and listing key content (full history, unknown-code passthrough, completeness, guv_years). This distinguishes it from sibling tools like get_company_details or get_company_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining a comprehensive record but does not explicitly state when to use it versus alternatives or mention any contextual prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_usageAInspect
Your own API-key usage: call count and weighted compute-units, broken down per tool. window ∈ {today, yesterday, month_to_date, last_30_days, all}. Returns only your own key's usage — no other user's data, no e-mail.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | today |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns only personal usage data and lists the valid window values. It does not discuss rate limits or auth, but these are implicit for an API-key tool. The output schema exists, so return structure details are covered there.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The key information (purpose, window options, scope limitation) is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, output schema present), the description fully covers how to invoke it and what to expect. No gaps remain for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists all allowed window values ('today, yesterday, month_to_date, last_30_days, all'), which is essential for correct usage. The default value is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'your own API-key usage: call count and weighted compute-units, broken down per tool'. It distinguishes itself from sibling tools which are about companies, documents, etc., making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it returns only the caller's own usage and clarifies what it does NOT include (other users' data, e-mail). While it doesn't list alternatives, sibling tools are clearly different, so the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sectorsBInspect
Legal-form + size-class taxonomy with counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but doesn't state it explicitly or mention any side effects. Minimal transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not a complete sentence. It is front-loaded, but the noun-phrase structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description adequately indicates what is returned. For a simple call, it is mostly complete, though sorting or format details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline score of 4 applies. No additional meaning needed beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: a taxonomy of legal forms and size classes with counts. It is specific and distinct from sibling tools, though it could be more explicit about the action 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_coverage or describe_fields. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesAInspect
Filtered company search over the Austrian Firmenbuch.
Returns a COMPACT summary card per company (name, legal_form, bundesland, size,
Bilanzsumme, equity ratio, revenue, growth, has_guv) — NOT the full record. For one
company's full profile call get_company_details; for everything we hold (full
position taxonomy, per-year history, lineage) call get_full_record.
Field reference: https://www.agentic-firmenbuch.at/felder.html
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| filters | No | ||
| page_size | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly states that the tool returns a compact summary card per company with specific fields, and emphasizes it is NOT the full record. This adds behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 6 lines with a clear front-loaded purpose. The field reference is a minor addition that doesn't clutter. Could be slightly more structured, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers return format and sibling guidance. Missing some detail on pagination and filtering behavior, but mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the tool description does not explain any of the 4 parameters (page, sort, filters, page_size). The field reference URL pertains to company fields, not search parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'search' and resource 'companies over Austrian Firmenbuch'. Immediately distinguishes from siblings by specifying it returns compact summary cards, not full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: for full profile use get_company_details, for full record use get_full_record. Also includes a field reference URL for further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!