Skip to main content
Glama

run_at_companies_search

Search Austria’s company registry (Firmenbuch) by company name or FN to retrieve company status, seat, registration details, and registry link.

Instructions

Search the Austria company registry (Firmenbuch) by company name or FN: name, registration number, status, seat and link. 1 point per returned record.

Input Schema

NameRequiredDescriptionDefault
statusNoStatus. Options: active = Active, inactive = Inactive / dissolved
keywordYesCompany name. e.g. red bull
max_itemsNoMax items (up to 250)
start_pageNoStarting page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the credit cost ('1 point per returned record'), which is not in the schema, but says nothing about pagination behavior (despite start_page/max_items params), auth requirements, or rate limits.

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?

One front-loaded sentence describing the search plus a short cost note; no filler. Slightly dense with the returned-field list, but every element earns its place.

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?

For a search tool with no output schema and no annotations, the description conveys the source, key inputs, credit cost, and the shape of the result (name, number, status, seat, link). Missing only guidance on paginating through large result sets and the distinction from run_at_companies.

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 description coverage is 100%, so all four parameters are documented, establishing the baseline of 3. The description adds only a small clarification that the keyword can be a company name or an 'FN' (registration number), which the schema's keyword field does not mention; this is marginal value over structured data.

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 (Search) and resource (Austria company registry / Firmenbuch) and lists the returned fields (name, registration number, status, seat, link). It identifies the country scope, which separates it from the dozens of other country registry tools, but does not differentiate it from its own sibling run_at_companies.

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?

The description never says when to use this search tool versus the plain run_at_companies lookup, nor does it state prerequisites or the conditions under which results are empty. Usage must be inferred entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools