tvrtke

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

With no annotations, the description carries the full burden and does fairly well: it names the data source (Sudski Registar), the returned subject matter (legal status, liquidation, bankruptcy), and adds anti-fabrication rules that shape agent behavior. It is silent on failure modes for invalid identifiers, auth/rate-limit behavior, and whether results are cached or live.

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 core capability is front-loaded in the first clause, and the usage directive and rules follow in descending priority. The RULES block is somewhat verbose and partly restates the guidance for missing identifiers, but nothing is badly out of order.

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?

No output schema exists, so the description must convey what comes back; it does so at a summary level (360-degree profile, legal status, proceedings). Combined with 100% schema coverage on inputs, an agent has enough to call it correctly, though return shape granularity (fields, nesting, pagination) is unspecified.

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 100% for both parameters, so identifier and identifier_type are already documented, including the 'oib' or 'mbs' distinction that the description merely repeats. The description adds no format, validation, or casing detail beyond that, so the baseline 3 applies.

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?

States a specific verb (Retrieve) and resource (company profile from Sudski Registar) and scopes the content to legal status and ongoing proceedings, which separates it from get_company_financials, get_company_history, and get_company_true_owners. It also frames itself as the primary entry point, so an agent can place it in the sibling set without opening any schema.

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?

Explicitly states when to use it ('always use this as the primary starting point for entity due diligence when an identifier is available') and handles the when-not case ('if identifier is missing, interview the user first'). It stops short of naming the natural fallback tool (search_companies) for the no-identifier case, so the routing is clear but not fully closed.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: results are limited to annual RGFI/GFI filings, include_aop_lines=true returns full raw AOP JSON, and the agent must not fabricate figures or identifiers and must interview the user if the identifier is absent. It omits error behavior, permissions/auth requirements, and pagination or result-size limits.

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?

Three sentences, all front-loaded: purpose first, then the AOP opt-in, then the integrity rules. Nothing is redundant with the name or title, and every sentence has a distinct function.

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?

For a 5-parameter tool with no output schema and no annotations, the description covers what is returned (historical annual reports, optionally raw AOP JSON) and the identifier prerequisite. It is slightly thin on output shape and edge cases, but an agent has enough to call it correctly.

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 100%, so all five parameters are already documented in the schema, including the include_aop_lines/aop_filter dependency and the OIB/MBS meaning of identifier. The description restates that dependency without adding syntax, format, or range semantics beyond what the schema provides, so the baseline 3 applies.

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 a precise verb and resource — retrieve historical annual financial reports (RGFI/GFI) filed with FINA — and scopes it to a single Croatian company identified by OIB or MBS. That per-company, historical framing implicitly separates it from siblings like search_financial_screener or get_company_overview, so an agent can select it without opening the schema.

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?

It gives clear operational context: use include_aop_lines=true with aop_filter to drill into statutory AOP line items, and interview the user when the identifier is missing. It does not, however, state when to prefer this over search_financial_screener or other siblings, so it stops short of explicit alternatives.

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

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

With no annotations provided, the description carries the burden and discloses important behavior: it returns the most recent 100 historical filings ordered by date. It also warns never to invent MBS numbers or historical events, which is a meaningful data-integrity constraint. It does not mention permissions, rate limits, or behavior when the company is not found, so it falls short of full 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?

The description is three tight sentences with no filler. Purpose is front-loaded, and the operational rules are separated clearly at the end. Every sentence contributes either scope, return behavior, or a usage constraint.

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?

For a one-parameter read tool with no annotations or output schema, the description is complete enough: it defines the source registry, the resource, the ordering, and the 100-record limit. An agent has what it needs to call the tool correctly and knows not to fabricate the MBS. The only minor gap is lack of sibling routing, which is more a usage-guidelines concern.

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 100% and the single mbs parameter is documented in the schema. The description adds value by expanding MBS as Court Register Number and tying it to a specific Croatian company in the Sudski Registar. The rule to ask the user for the MBS rather than invent one further clarifies how the parameter must be sourced.

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 a specific verb and resource: retrieve the chronological timeline of official legal and corporate changes from the Sudski Registar for a company identified by MBS. It clearly scopes the tool to historical filings, which distinguishes it from financial or ownership siblings by domain. However, it does not explicitly name or differentiate itself from siblings such as get_company_overview or get_company_by_id.

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?

Usage is implied by the purpose: use this tool when historical legal/corporate changes are needed. The rule to ask the user for the MBS first gives a prerequisite but not a comparison to alternatives. There is no explicit guidance on when to choose this over get_company_overview or search_companies.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that it returns open questions and rules against inventing data, and gives a clear rule set, but it does not cover permissions, side effects, idempotency, or response format, leaving key behavioral aspects unspecified.

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?

Three sentences, front-loaded with the tool's purpose, followed by a clearly marked 'RULES:' section. No wasted words, though the second sentence could be tightened.

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?

For a simple tool with no output schema, the description explains the return values (open questions, rules) but does not clarify what the 'overview' actually contains or how the registers are used. It is adequate but leaves gaps for an agent to fully understand the tool's scope.

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 100% (one optional 'query' param fully documented in the schema). The description adds no additional meaning about the parameter, so the baseline score of 3 applies.

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 a specific verb ('Get an overview') and a resource ('Croatian company registry due diligence workflows and data availability'), but the resource is meta and the tool name 'get_company_overview' suggests company data rather than workflow guidance, creating ambiguity. It does distinguish itself from data-fetching siblings by focusing on workflows and rules, but not explicitly.

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?

It includes a process directive ('Interview the user first') but provides no explicit guidance on when to use this tool versus the many sibling tools (e.g., search_companies, get_company_by_id) or any exclusions. Usage is implied but not clearly stated.

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

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

With no annotations, the description carries the full burden. It discloses the data source and the shape of the result (direct/indirect ownership structures, control nature) and adds anti-hallucination rules, but says nothing about auth requirements, rate limits, or behavior when no owners are registered.

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?

Front-loads the purpose and what is returned before the rules, with no filler sentences. The RULES block is slightly boilerplate (generic anti-hallucination guard) but does earn its place by warning against fabricating ownership chains.

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?

For a one-parameter read lookup with no output schema or annotations, the description adequately covers source, return content, and input prerequisites. Missing only edge-case behavior (company not found, no registered owners), which is minor here.

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 100% and the single identifier parameter already documents OIB or MBS, so the description adds no format or syntax detail beyond the schema. The 'interview the user first' note is the only extra parameter-related guidance, which lands at the baseline 3.

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?

States a specific verb (retrieve) and resource (registered true owners and authorized representatives) for a Croatian company, and names the source registry (FINA RSV). This clearly separates it from generic siblings like get_company_overview, but it never names or contrasts with the closest sibling search_true_owners, leaving the boundary implicit.

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?

Gives one conditional rule ('If identifier is missing, interview the user first'), which is useful but narrow. It never says when to prefer this over search_true_owners or get_company_overview, so the choice between siblings is left to inference.

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

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

With no annotations, the description carries the full behavior burden and does useful work: it discloses the 50-record result cap and that results are only basic profile summaries, plus operational rules about not fabricating filters. It stays silent on pagination beyond the cap, ordering, and any auth/permission requirements, which are real gaps for an 11-parameter query tool.

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?

Front-loaded with purpose, then filters, then return shape, then rules — a sensible ordering with no filler sentences. The long filter enumeration largely restates schema parameters, which is mildly redundant but justifiable as a routing aid.

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?

For an 11-optional-parameter search tool with no annotations and no output schema, the description covers purpose, filter semantics, result cardinality, and an important interaction rule. Remaining omissions (what to do when the 50-record cap is hit, result ordering) are minor but real.

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 100%, so the baseline is 3, but the description adds semantics the schema does not: name matching is 'partial/fuzzy', NKD/NACE matching is by industry code prefix, and the date range is an inception/foundation window. It also groups the filters into recognizable facets (address components, proceedings), which helps an agent pick the right parameter.

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?

States a specific verb (search and discover) and a precisely scoped resource (Croatian companies in the Sudski Registar), then enumerates the filterable facets, which tells an agent immediately that this is the broad discovery tool rather than one of the get_company_* detail siblings. The stated return of 'basic entity profile summaries' further separates it from the richer per-entity tools.

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?

Gives an explicit precondition and when-not: if search criteria are empty, interview the user with clarifying questions before calling, and never invent filters. It stops short of naming alternatives (e.g., search_financial_screener for financial queries), so routing between the three search siblings is left to inference.

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

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

With no annotations, the description carries the full burden. It discloses the data source (FINA statutory filings), a default reporting year (2024), that filtering is range-based, and that results can be sorted and paginated. It does not describe the return shape, what a result row contains, result ordering guarantees, or performance characteristics of a 28-filter query.

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?

Front-loaded with what the tool is and what it filters, followed by a compact RULES block. Every sentence is functional; the only minor inefficiency is that the metric list partially duplicates the schema. No filler or redundancy otherwise.

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?

For a 28-parameter search tool with no output schema, the description covers filtering, sorting, pagination, and the data source, but never describes what the returned records look like or what fields come back. Given the absence of an output schema, a brief note on the result shape would materially complete the definition.

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 100%, so the schema already documents every parameter, and the description's enumeration of filterable metrics (revenue, operating income, net profit, assets, liabilities, equity, PBT, EBITDA, solvency ratios) largely mirrors the schema. It adds no units, currency, or range-format detail beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb+resource: a 'financial screener and discovery engine for Croatian companies based on FINA statutory filings.' It is clearly differentiated from single-company getters like get_company_financials by being a multi-company discovery tool, but it never names a sibling (e.g. search_companies) to draw the boundary explicitly.

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 RULES line gives a precondition ('If screening criteria are not provided, interview the user first') and a constraint ('Never invent financial thresholds'), which is real usage guidance. However, it gives no alternatives or when-to-use-vs-siblings guidance, so the reader must infer that this is the tool for multi-criteria financial filtering rather than keyword search.

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

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

With no annotations, the description carries the full disclosure burden. It adds a meaningful behavioral constraint ('Never invent personal identities, birth details, or corporate connections'), which is genuine value beyond the schema, but says nothing about result shape, pagination behavior, or data-freshness limits that an agent would want before invoking a registry lookup.

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, front-loaded with purpose and followed by operating rules; nothing is padded. The rules sentence is somewhat generic but does earn its place given the absence of annotations.

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?

For a 9-parameter, zero-required search tool with no output schema, the description adequately frames the domain and flags the need to gather criteria, but does not convey what a result contains or how limit/offset pagination behaves. It is minimally sufficient rather than 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 100%, so every parameter is already documented in the schema, giving a baseline of 3. The description refers only vaguely to 'criteria' and adds no format or matching details beyond what the schema fields already state.

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?

States a specific verb (search) and resource (Croatian Registry of True Owners / RSV) and clarifies the direction of the lookup: discovering companies tied to an individual owner or representative, which separates it from company-centric siblings like search_companies or get_company_true_owners. It stops short of naming those siblings explicitly.

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 rule 'If criteria are missing, interview the user first' gives one clear usage condition, but there is no guidance on when to prefer this over search_companies, nor when NOT to use it. Usage is implied rather than fully specified.

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