Compabase

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

Annotations already declare this is a write (readOnlyHint=false), non-destructive, and idempotent, so the safety profile is covered. The description adds useful scope context (KRS + CEIDG sole proprietorships) but says nothing about auth requirements, duplicate handling, or what happens if neither key matches.

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 short sentences, front-loaded with the core action, with no filler. Efficient, though the KRS/NIP detail slightly restates the schema.

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, idempotent add with fully covered parameters and no output schema, the description is nearly complete. It omits only success/response behavior and error handling, which are minor given the annotations and schema already carry the operational profile.

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 both krs and nip are already documented in the schema, including the 'used for CEIDG if no KRS match' note. The description paraphrases the same digit-length and entity-type details, adding marginal value, so the baseline of 3 is appropriate.

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 and resource ('Add a company to the user's watchlist') and the identification keys, so it is clearly distinguishable from list_watchlist and remove_from_watchlist. It does not explicitly differentiate itself from the sibling add_watchlist_batch, leaving the singular-vs-bulk distinction to inference.

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 (this is the single-company add) but never stated explicitly, and the bulk alternative add_watchlist_batch is not named. No when-not or prerequisite guidance is given, though the KRS/NIP identification context is a small help.

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?

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds genuinely useful behavior beyond that: identifier resolution to companies, duplicate skipping, and plan-limit enforcement. It stops short of describing what happens on partial failure. Note 'skips duplicates' sits alongside idempotentHint=false but is not a hard contradiction.

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 short sentences, all load-bearing, with the core action front-loaded. No filler or repetition of the title.

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?

There is no output schema, and the description covers input constraints, dedup semantics, and plan limits without saying what is returned or how partial failures are reported. For a single-parameter batch mutation this is nearly complete but leaves that response gap.

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 schema documents the KRS/NIP formats, so the baseline is 3. The description adds a constraint the schema lacks — the max 500 array size — plus the resolution behavior, which is real added value.

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+scope: 'Add multiple companies to watchlist in one call.' The batch framing clearly distinguishes it from the sibling add_to_watchlist (singular). An agent can route correctly without opening either 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?

'in one call' plus 'max 500' implies the batch use case and routes away from the singular sibling, and 'respects plan limits' signals a precondition. No explicit exclusion or named alternative, so it stops short of a 5.

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?

Adds real context beyond the annotations: 'no auth required', the return of mcp_key exactly once (which explains the non-idempotent profile declared by idempotentHint=false), and the cursor_mcp_json artifact the caller must write. It stops short of describing what happens on a call after already_delivered (error vs. status payload), which is the one behavioral edge left implicit.

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 tight sentences, front-loaded with the purpose, then the payoff, then the operational cadence. No filler and nothing repeated from the schema.

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?

With no output schema present, the description compensates by naming the returned fields (mcp_key, cursor_mcp_json) and the terminal status values. Combined with the polling instructions and auth note, an agent has everything needed to invoke and loop this tool 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 both parameters are already documented by the schema; baseline 3 applies. The description reinforces setup_id's provenance ('from request_signup') but adds no syntax or semantics for the optional client enum beyond what the schema states.

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?

Names a specific verb (poll/check) and resource (request_signup session), and ties itself explicitly to the request_signup sibling that produces the setup_id. An agent can distinguish it from create_mcp_key or list_mcp_keys 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?

Specifies the polling cadence (every 3 seconds) and the exact termination conditions (ready, expired, already_delivered), which is precisely the when-to-call/when-to-stop guidance an agent needs. The prerequisite (setup_id from request_signup) is stated inline, removing ambiguity about ordering.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious context: JDG companies are excluded, CEIDG data lives elsewhere and is RODO-gated, and sparse/zero counts in JDG-heavy PKDs come back with a `hint`. That hint signal is valuable for interpreting an odd result.

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 tight sentences, front-loaded with purpose and return shape before the caveats. The jargon ('Compabase', 'RODO-gated') costs a little clarity but does not pad the text.

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?

With no output schema, the description usefully discloses the return shape (a single number, occasionally with a `hint`). It also explains the main exclusion that would confuse an agent. A one-line indication of what the filter set covers would close the remaining gap for a 29-parameter tool.

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 all 29 parameters are already documented, including the nuanced `year` and `registration_date_min` usage notes. The description adds nothing per-parameter, so the baseline 3 applies; it compensates only at the aggregate level by calling out that filters are matched against KRS companies.

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 (count) and resource (KRS companies) and immediately delimits scope by declaring it returns a single number, not a list. This cleanly separates it from search_companies and export_companies, which an agent can now distinguish without opening either 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?

The 'returns a single number — no company list' clause implicitly routes the agent to a listing tool when actual records are needed, and the JDG exclusion tells the agent when the count will not be authoritative. It stops short of explicitly naming the alternative tool or the exact condition for choosing count over 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds a genuinely important behavioral fact not in the schema: the raw key is returned once and is unrecoverable. It does not cover permissions/scopes or duplicate-name behavior, so not a 5.

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 short sentences with zero filler; the one-time-secret warning is front-loaded where the agent will read it before calling.

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 creation tool with no output schema, the description covers the essential return behavior (raw key shown once). It omits edge cases like duplicate names or key scoping, but nothing critical for correct invocation is 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?

Schema description coverage is 100% for the single 'name' parameter, so the schema already documents it fully; the description adds no syntax or constraint detail beyond that. Baseline 3 is appropriate.

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 and resource ('Create a new REST API key') and even gives the key prefix format (cb_…), which cleanly distinguishes it from create_mcp_key and set_byok_key in the sibling 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?

The description says what the tool does but never states when to choose it over create_mcp_key or set_byok_key, nor any precondition (plan tier, existing-key limits). The agent must infer from the name alone.

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?

Annotations already mark this as a non-read-only, non-idempotent, non-destructive creation. The description adds genuinely useful behavior beyond that: the raw key is returned exactly once and cannot be retrieved later, which tells the agent to surface/store the value immediately. It stops short of stating auth requirements or key 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?

Two sentences, zero filler, and the most actionable fact (one-time retrieval) is front-loaded right after the purpose. Nothing to trim.

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 creation tool with full schema coverage and no output schema, the description covers the essential lifecycle detail (one-time reveal). It could mention whether the key is scoped/permission-bound or requires a particular plan, but nothing critical for a correct invocation is 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?

Schema coverage is 100% and the single 'name' parameter is fully documented in the schema (max 100 chars), so the baseline of 3 applies. The description adds the key-format prefix, but no naming conventions or constraints beyond what the schema already carries.

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 and resource ('Create a new MCP key') and even names the returned key format prefix (mcpk_…). It is clearly differentiated from generic key creation only implicitly, however — the sibling create_api_key is not contrasted, so the agent must infer the distinction from the name alone.

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 gives no guidance on when to create an MCP key versus create_api_key, nor any prerequisites such as plan limits or existing key count. With several key-management siblings (create_api_key, list_mcp_keys, delete_mcp_key), the absence of selection guidance is a real gap.

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?

Annotations cover the safety profile (destructive, idempotent, not read-only). The description adds valuable context beyond that: 'The key stops working immediately', telling the agent about propagation timing. Not a full 5 since reversibility and auth requirements aren't addressed.

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 short sentences, front-loaded with the action verb and resource, second sentence adds the critical behavioral note. Zero waste.

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?

Adequate for a single-param destructive mutation tool with annotations carrying the safety profile and a schema documenting the parameter. Missing only edge-case behavior (e.g., what happens if the key doesn't exist or is already revoked), but the essential information is present.

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 param is already documented including the 'from list_api_keys' hint. The description reinforces 'by its ID' which is consistent, but adds no new syntax or format details. Slightly above baseline due to reinforcement of the identifier 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?

Specific verb+resource: 'Revoke (deactivate) a REST API key by its ID'. Clearly distinguishes from siblings like delete_mcp_key and delete_byok_key by scoping to REST API keys, and matches the name exactly.

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?

Implies usage through 'by its ID' and the schema notes 'from list_api_keys' which hints at the list-then-revoke pattern. But no explicit when/when-not guidance or alternatives (e.g., vs delete_mcp_key) are given.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds a genuinely useful post-condition beyond the annotations: the platform falls back to its own model access, which tells the agent the effect is a configuration revert rather than data loss.

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 tight sentences, zero filler, with the primary action front-loaded and the consequence second. Every sentence earns its place.

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 single-param destructive tool with no output schema, the description plus rich annotations cover action, selectivity, idempotency, and the resulting state. It stops short of noting reversibility (whether the key can be re-added) or permission requirements, but nothing essential is 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?

Single required 'provider' parameter with 100% schema description coverage and an enum of allowed values, so the schema carries the full specification. The description adds no provider-specific detail or constraint, making the baseline 3 appropriate.

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 ('Remove') and precise resource ('BYOK provider key'), which cleanly separates it from sibling counterparts set_byok_key and get_byok_keys. An agent can identify the operation 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?

The description says what happens after removal but gives no when-to-use guidance, no prerequisites (e.g., admin scope), and no reference to alternatives such as set_byok_key for rotating a key. Usage is only inferable from the tool name.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false. The description adds real value beyond them: 'deactivate' signals a revocation (not physical deletion), the immediate-effect timing ('stops working immediately'), and the self-key guard. It stops short of stating whether the action is reversible or recoverable.

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 short sentences with zero filler, front-loaded with the action and its effect, followed by the one blocking constraint. Every sentence earns its place.

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 single-parameter revoke tool with rich annotations and no output schema, the description covers action, timing, and the main precondition. It leaves minor gaps (reversibility, effect on existing records/audit, whether an error is returned for the in-use key), but nothing critical to invoking 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 coverage is 100% and the sole key_id parameter is fully documented in the schema, including its source ('from list_mcp_keys'). The description adds nothing parameter-specific beyond 'by its ID', 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 and resource ('Revoke (deactivate) an MCP key by its ID') and clarifies the resource as an MCP key, which distinguishes it from the delete_api_key and delete_byok_key siblings. An agent can identify 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 supplies a precondition ('Cannot revoke the key currently in use'), which is useful selection context, but never says when to choose this over delete_api_key or delete_byok_key, nor what to do instead if the key is in use. Implied usage only.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, and the tool title repeats 'Read-Only', so the description's 'read-only' framing adds no new safety information. It also omits practical behaviors an agent would want: row/result limits, timeout, cost, and whether queries can be rejected — no value beyond the structured fields.

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 the core action and followed by the usage trigger. Every clause earns its place; there is no filler or restated boilerplate.

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-only tool with full annotation coverage, the description is nearly sufficient. The main residual gap is that no output schema exists, so the agent gets no hint about result shape or size limits — a minor omission for a generic query executor but one worth noting.

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 is a single parameter with 100% schema description coverage, so the schema already documents the 'query' argument as a SELECT/WITH…SELECT statement. The description restates that constraint without adding syntax, dialect, or example-level detail, so the baseline 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?

States a specific verb and resource ('Execute a read-only SQL SELECT query against the Compabase database'), leaving no ambiguity about what the tool does. It is also clearly distinguishable from the many dedicated get_*/search_* siblings, which retrieve specific entity data rather than arbitrary queries.

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?

'Use when dedicated tools are not enough (aggregations, joins, custom analysis)' gives a clear trigger condition and names the alternative category (dedicated tools). It stops short of an explicit list of which sibling to prefer for which case, but the routing intent is unambiguous.

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?

Adds genuinely non-structural behavior: the 500-row cap per call, that quota is consumed only after the file is built successfully, and that `full` dumps can break MCP clients. These go beyond the annotations (readOnlyHint=false, idempotentHint=false) by explaining the cost/size semantics. It stops short of describing response shape or error behavior.

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?

Dense but front-loaded: format and row cap first, then the `fields` tiers, then the quota note, then the routing alternative. Every clause carries information, though the field-preset sentence is long enough to require a second read.

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 15-parameter, zero-required export tool with no output schema, the description covers the decisions that matter (which preset, what format, size ceiling, quota). Filter parameters are left to the fully documented schema, which is reasonable, but filter combination behavior is not addressed.

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 already 100%, so the baseline is 3, but the description adds useful aggregate semantics by naming the concrete column set behind each `fields` preset (e.g. `summary` adds location, PKD, latest revenue/profit) rather than just restating the enum.

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 ('Bulk file export of companies matching filters') plus the three output formats, and clearly distinguishes this from search_companies by pointing at the alternative for short email lists. 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?

Gives explicit guidance on which `fields` preset to choose, warns that `full` often exceeds MCP client limits, and names the alternative path ('for a short list of emails after search_companies, use search with fields=contacts_only instead'). When-to-use and when-not-to-use are both present.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description still adds genuine behavioral context beyond the annotations: it discloses the return contents (provider list, key prefix, last-used date) and explicitly states the actual key is never returned, which is meaningful for an agent reasoning about secret exposure.

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 tight sentences, zero boilerplate: what it lists, what each entry contains, and the security guarantee. The most decision-relevant fact (it is a status listing, not a key retrieval) is front-loaded.

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?

With no output schema, the description carries the return-shape burden and discharges it by naming the fields returned. It is complete enough to call correctly; the only gap is that the empty input schema is never confirmed (i.e. that no provider filter argument is accepted).

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing to under-document and the description does not introduce pseudo-parameters or filtering options that the empty schema would contradict.

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?

Specific verb (list) plus precise resource (configured BYOK provider keys) with scope details: which providers, prefix, last-used date. It is distinguishable from siblings like set_byok_key and delete_byok_key by name alone, but it never explicitly acknowledges those siblings or contrasts itself with list_api_keys/list_mcp_keys.

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 only implied: an agent can infer this is the read-side counterpart to set_byok_key/delete_byok_key, but the description never states when to call it (e.g. to audit configured keys before setting or deleting one) or any prerequisites. No alternatives or exclusions are named.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context beyond them: the period-consistency guarantee for all money fields, the Ohlson/RIM basis of estimated_value, the MF white-list provenance of vat, and the RODO-driven NIP-lookup edge case returning a CEIDG/JDG firm.

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?

Content is front-loaded on what the response contains and every clause carries information, but the opening is a dense, parenthetical-heavy run-on and the period-consistency point is stated twice ('...for one latest filed period' and 'All money fields in this response are that same period').

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?

There is no output schema, so the description must carry the return contract, and it does: it enumerates the field groups, defines the monetary-estimate methodology, discloses the VAT data source, and flags the excluded balance-sheet items. An agent has enough to call and interpret the tool 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 the baseline is 3, but the description adds meaning beyond the schema by explaining that a NIP lookup can return a CEIDG/JDG sole proprietorship when it has a public contact email. It does not, however, explain precedence when multiple identifiers are supplied.

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 names a specific verb+resource (company registry profile plus headline financials) and enumerates the exact fields returned (revenue, profit, PKD, address, vat, KRS changes). It actively distinguishes itself from the most confusable sibling by stating what it excludes and pointing to get_financials.

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 an explicit when-not and a named alternative: 'Does NOT include balance-sheet line items... For those or earlier years, use get_financials.' That is strong routing guidance, but it says nothing about when to prefer this over the many other get_company_* siblings (people, beneficiaries, articles, etc.), leaving that inference to the agent.

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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine behavioral detail beyond that: all names are returned, PESEL is never exposed (birth_year only), and JDG entities are out of scope — meaningful output and privacy characteristics.

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 short, front-loaded sentences with no filler. Each sentence carries distinct payload: scope, output content, and the JDG exclusion.

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?

With no output schema, the description usefully sketches the return shape (all names, birth_year, no PESEL) and states the domain exclusion. For a safe read tool with full annotations and 100% schema coverage, this is nearly complete; only the relationship to get_company_people remains unaddressed.

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 three parameters (krs, nip, name) are already documented in the schema, including that NIP resolves KRS. The description only reaffirms the KRS scope and adds no new syntax or fallback logic, so the baseline of 3 is appropriate.

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 ('Get') and a precise resource ('CRBR beneficial owners'), scoped to a KRS company. An agent can distinguish it from generic siblings like get_company, but it does not explicitly differentiate itself from the closest sibling, get_company_people, which likely overlaps in owner/person 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 statement 'JDG are not in CRBR' gives one useful when-not exclusion, implying the tool is inappropriate for sole proprietorships. However, there is no guidance on when to prefer this over get_company_people or which of the three identifiers to use, leaving the main routing decision 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that matching is by KRS/NIP and lists notice categories, but says nothing about pagination, result volume, or behavior when no identifier matches.

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 tight sentences with the resource and entity scope front-loaded and no filler. Every clause carries information about what is retrieved and how it is keyed.

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 carried some burden to characterize the return, and it does so only at the level of notice categories. It omits return shape, ordering, and the optional name fallback behavior, leaving gaps for a lookup tool with three optional identifiers.

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% and the three parameters are self-documenting; the description's mention of 'Matched by KRS or NIP' mirrors the schema rather than adding syntax, format, or precedence rules. Baseline 3 is appropriate.

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 ('Get Court and Commercial Gazette (MSiG) notices for one company') and scopes it to a single entity, which separates it from sibling read tools like get_company_articles or get_company_procurement. It does not, however, explicitly name or rule out those siblings.

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 matching keys (KRS or NIP) and enumerates the notice categories retrieved (creditor calls, dissolution, mergers, liquidation), which implies when the tool is relevant. There is no explicit statement of when to prefer it over sibling company-detail tools or what to do if it returns nothing.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds domain routing context (which register applies to which entity type) but says nothing about the nature or completeness of the returned proceedings data.

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 short sentences, front-loaded with the resource, then the key-selection rule. Telegraphic but every clause carries information; no filler.

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?

There is no output schema, so the description carries the burden of explaining what comes back, and it does not describe the proceedings records at all. For a zero-required-param lookup tool with three aliasing keys, the routing guidance is adequate but the return-value side is 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?

Schema coverage is 100% so the baseline is 3, but the description adds real semantic mapping beyond the schema: krs for registered companies, nip for CEIDG/sole proprietors, and name as the fallback. That clarifies when each key applies rather than just restating the field names.

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?

Names a specific resource (KRZ insolvency / restructuring proceedings) retrieved via a clear verb. It does not contrast itself against the many sibling get_company_* tools (e.g. get_company_sanctions, get_company_court_gazette), so sibling differentiation is weak, but the purpose itself is 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?

It implies usage through the KRS vs NIP vs name routing ('KRS companies via company_krz; sole proprietors via CEIDG KRZ by NIP'), which helps the agent pick a lookup key. However, it names no alternative sibling tool and gives no explicit when-to-use/when-not guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds meaningful context beyond that: the data domains returned, that pending applications are included, and that the record is keyed by NIP.

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 compact sentences with the payload scope front-loaded, then the identification options. No filler or restated title noise.

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?

With no output schema, the description carries the return-value burden and does so at a high level (concessions list, validity dates, pending applications, NIP keying). It stops short of describing the record shape or behavior when a company cannot be resolved, which is a small residual gap for a 3-param lookup.

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 100% schema coverage the baseline is 3, and the schema already documents all three identifiers. The description adds a preference signal ('NIP — preferred for URE') that the schema does not convey, nudging above baseline.

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?

Names a specific verb+resource (URE energy concessions for a company) and enumerates the covered domains — electricity, gas, heat, liquid fuels — plus what the payload contains (validity dates, pending applications). This is clearly distinguishable from siblings such as get_company_waste_registry or get_company_sanctions.

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?

States the lookup conditions explicitly: 'Identify company by name, KRS, or NIP' and flags NIP as preferred for URE. Clear context for when/how to call, though it names no alternative tool or exclusion case (no close sibling overlaps, so this is minor).

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?

Annotations already declare readOnly, idempotent, non-destructive, non-openWorld, so the safety profile is covered. The description adds meaningful context beyond that: data provenance (official MFiPR lists), the fund family (cohesion/shared-management), and what fields come back. No auth, rate-limit, or pagination details, but the additions are substantive.

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 tight sentences, front-loaded with the core action and scope, then the keying rule, then the disambiguation. Every clause earns its place, though the exclusion list is dense in a way that slightly compresses readability.

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?

With no output schema, the description usefully previews the return content (projects, EU co-financing, programme, dates). Identification is fully addressed across all three optional params. It doesn't state there are zero required params, but for a read-only lookup tool the coverage is sufficient.

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 schema already documents all three identifiers, including noting NIP is 'preferred for FE'. The description reinforces NIP as the primary key and lists the name/KRS/NIP alternatives, but adds no new syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 (get EU/European Funds projects for a company) and pins down the source (official MFiPR lists) and payload (EU co-financing, programme, dates). The closing exclusions ('not TED procurement, not FTS Commission grants, and not SUDOP state aid') sharply separate it from sibling tools like get_company_eu_tenders and get_company_public_aid.

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 explicit when-not guidance by naming three adjacent data domains it does NOT cover, plus identification guidance ('Keyed by NIP', 'Identify company by name, KRS, or NIP'). It stops short of routing the agent to the specific sibling tool to use instead, so it's clear but not fully prescriptive.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful data-scope context ('full awards as contractor and notices as buyer'), but says nothing about auth, rate limits, result volume, or date coverage for a daily-updated dataset.

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 densely packed sentences with the core scope front-loaded and no filler. The telegraphic fragment style is slightly terse but every clause carries information.

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?

With no output schema, the description partially compensates by naming the return categories (awards vs notices), but omits pagination, date-range behavior, and result limits for what is a daily-updating dataset. Adequate but with clear gaps for a discovery-style tool.

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 baseline is 3. The description largely restates the schema ('Identify company by name, KRS, or NIP' and 'Keyed by NIP'), and the schema itself already marks NIP as 'preferred for TED', so it adds no meaning beyond structured fields.

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 and resource ('Get TED EU-threshold public procurement') with a defined scope that sets it apart from generic procurement retrieval. However, it never distinguishes itself from the near-identical siblings get_company_procurement and get_company_public_tenders, so the agent cannot tell which EU/PL tender tool to pick.

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?

There is no when-to-use guidance and no exclusion relative to the closest siblings (get_company_procurement, get_company_public_tenders). The only routing hint is the identifier preference, which is about parameters, not about tool selection.

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?

Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral context: the exact fields returned and the null-when-absent behavior, which the annotations do not convey.

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 resource and scope, then the return fields, then the key/null note in three tight clauses. No filler, though the entity-type enumeration is somewhat long for the value it adds.

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, but the description compensates by naming the returned fields (kind, KNF number, status, dates, services) and the null case. An agent has enough to call it correctly; only sibling-selection guidance is 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?

Schema description coverage is 100%, so all three parameters (krs, nip, name) are already documented in the schema. The description only adds that the record is 'keyed by NIP', a marginal hint about primary-key preference that doesn't add syntax or fallback guidance.

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 resource (KNF register / Polish Financial Supervision Authority), the covered entity types (banks, payment/e-money institutions, insurers, agents), and what is returned. This scoping lets an agent distinguish it from the many sibling get_company_* registry lookups 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?

Provides useful lookup context ('Keyed by NIP; null when the company has no KNF entry'), implying usage for companies that may hold KNF licences. However, it never states when to prefer this over sibling registries (e.g. get_company_sanctions or get_company_stock_market) or any prerequisites, leaving selection 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. With no output schema, the description earns credit by disclosing the return shape: display names, role labels, and relationship type vocabulary (management, supervisory, ownership, procuration). It omits any note on result cardinality or pagination.

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 the action and scope, then the identifier options. No filler, no restatement of the title, and every clause carries information.

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 read-only lookup with four optional params and no output schema, the description supplies the return vocabulary an agent needs. The remaining gap is behavioral ambiguity around zero required parameters — whether any single identifier suffices and what happens when several are given is left unstated.

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% and each parameter is already documented, so the baseline is 3. The description restates the identity options and repeats the same relationship filter values as the schema (including re-explaining 'supervisory') without adding new semantics such as precedence when multiple identifiers are supplied.

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?

Names a specific verb and resource ('Get people associated with a company') and enumerates the sub-populations returned (management board, supervisory board, shareholders, proxies), which meaningfully separates it from neighbors like get_company_beneficiaries and get_company_court_gazette. It never explicitly names an alternative or says 'not this one', so it stops short of full sibling differentiation.

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 second sentence gives identification guidance (name, KRS, or NIP), which implies how to call it, but there is no when-to-use statement, no condition excluding it in favor of a sibling, and no note on whether an identifier is mandatory (all 4 params are optional). Usage is inferable but not 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the notion of a 'full case list' but nothing beyond that—no pagination, rate limits, or completeness caveats—so it earns only modest credit over the annotations.

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?

A single dense sentence plus a short clause; the resource and lookup keys are front-loaded and nothing is padding. Slightly compressed by the em-dash list, but efficient overall.

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?

With no output schema, the description usefully enumerates the returned fields (amounts, grantor, measure, purpose) and identifies accepted lookup keys, covering the essentials for a read-only retrieval tool. It omits edge cases like empty results or identifier-precedence behavior, keeping it just short of 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 coverage is 100% and all three parameters are self-documented, so the schema carries the load. The description recaps 'Identify company by name, KRS, or NIP' and adds the NIP preference note, but goes no further than the schema already does—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: getting SUDOP public aid/grants for a company, and scopes what is returned (full case list with amounts, grantor, measure, purpose). The 'SUDOP' qualifier helps distinguish it from sibling tools like get_company_eu_funds or get_company_procurement, though it never explicitly names an alternative to differentiate against.

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 lookup-key guidance ('Keyed by NIP', identify by name, KRS, or NIP), which implies usage, but offers no explicit when-to-use vs. when-not or which sibling to prefer for adjacent funding data. An agent gets context for invoking it but not for choosing it over neighbors.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine value by disclosing what the data contains — contractor-side awards and buyer-side notices with award values — which the annotations cannot convey, though it omits any note on coverage limits or pagination.

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 compact sentences with no filler, leading with the resource and scope before the keying detail. The em-dash clause is dense but clear; nothing here is wasted, though phrasing is slightly compressed.

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 should carry the return-value burden, and it only partially does — it names the content categories and award values but says nothing about volume, date coverage, or result shape. With all three parameters optional, an agent also gets no guidance on which identifier to supply when several are available beyond the NIP hint already in the schema.

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 each parameter is already documented, including the schema's own note that NIP is preferred for BZP. The description's 'Keyed by NIP' and the name/KRS/NIP list restate the schema rather than adding new semantics, so the baseline 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?

States a specific verb ('Get'), a specific resource (BZP public procurement data), and defines scope precisely: full awards as contractor plus notices as buyer, with award values. It arguably differentiates from get_company_eu_tenders by naming BZP, but it never explicitly distinguishes itself from the close sibling get_company_procurement.

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 identity-resolution sentence ('Identify company by name, KRS, or NIP'), which tells the agent how to call it, but there is no explicit when-to-use or when-not-to-use guidance and no routing against the overlapping siblings get_company_procurement and get_company_eu_tenders.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful return-shape context: rows come from company_financial_rankings with one row per scope, which goes beyond annotations.

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 well-structured sentences with no wasted words. The core purpose and return structure are front-loaded, followed by a concrete usage example.

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 read-only, idempotent ranking lookup with four optional parameters and no output schema, the description supplies the key return structure (one row per scope) and scope values. It does not describe row fields or pagination, but the essential calling context is present.

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 baseline is 3. The description still adds meaning by explaining that each scope produces one row and by naming the scope values, clarifying the scope_type enum beyond the raw list 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 states a specific verb (Get) and resource (company revenue rank positions) with clear scope: industry (PKD), region (voivodeship), and all of Poland. It distinguishes this tool from siblings like get_financials and get_company_* by focusing on rank positions and naming the underlying ranking table.

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 explicitly says to use it for questions like 'where does company X rank in Poland / its industry / its region?', giving clear usage context. It does not name alternative tools or state when not to use it, so it falls short of the top score.

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?

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds valuable return semantics: it returns sanctions measures and legal grounds when listed, and null when not listed, plus the identifier matching options. This goes beyond the structured annotations.

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 four short sentences, front-loaded with the core purpose then return behavior, matching keys, and sibling relationship. Every sentence adds relevant information without padding.

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?

With no output schema, the description fully explains the return shape (measures and legal grounds, or null). It also covers matching identifiers and the relationship to get_company, while annotations cover safety. An agent has enough information to invoke the tool 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 three parameters (krs, nip, name) are already documented in the schema. The description adds that matching can use KRS, NIP, or REGON, but omits the name fallback that the schema provides. This is useful but marginal over 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 states a specific verb and resource: retrieving the official MSWiA sanctions listing for one company. It also explains the return behavior (measures/legal grounds or null) and clarifies the relationship to get_company, so an agent can distinguish this from sibling 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?

The description gives clear context that this is a single-company sanctions lookup and notes that the same payload is included on get_company as sanctions, which helps the agent avoid redundant calls. However, it does not explicitly say when to prefer this standalone tool over get_company 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.

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

Annotations already declare this a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint=false), so the safety bar is pre-cleared. The description still adds meaningful context beyond that: a data-freshness scope ('period ending 2025+') and return behavior ('null when nothing is disclosed').

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 resource is front-loaded and the content is dense but purposeful; the parenthetical Polish terms and attribute list all carry information. It is a single long sentence that could be split for readability, but there is little waste.

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?

With no output schema, the description takes on the burden of describing return values and does so thoroughly: it lists the returned fields (creditor, amount, secured debt, asset, KW numbers) and the null-case behavior. Nothing needed to interpret the call result is 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?

Schema description coverage is 100%, so all three parameters (krs, nip, name) are already documented in the schema. The description restates that the record is keyed by KRS but adds no syntax, format, or precedence guidance for choosing among krs/nip/name, matching 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 and resource and enumerates the returned liability subtypes (mortgages, pledges, transfers, assignments) with their attributes, so an agent knows exactly what it retrieves. It does not, however, differentiate itself from the similarly named sibling get_company_debt_registry, leaving potential ambiguity unaddressed.

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 only implied: 'Keyed by KRS' signals the lookup path, and 'null when nothing is disclosed' hints at edge-case handling. There is no explicit when-to-use, no when-not, and no routing to an alternative tool.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds meaningful operational context beyond annotations: quotes delayed ~15 minutes, values in PLN, and scope limited to a snapshot plus a few recent daily bars rather than full OHLCV history. No auth or rate-limit detail, but the data-freshness disclosure is valuable.

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 the purpose, then a dense but purposeful field list, followed by critical caveats (delay, currency, scope). Two sentences, no filler, every clause informs the call.

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?

With no output schema, the description carries the full burden of describing return content, and it does so thoroughly: field list, quote delay, currency, and scope limits. Nothing essential for calling or interpreting this tool is 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all three parameters. The description adds real value by clarifying that the tool is keyed by NIP and that a company can be identified by name, KRS, or NIP, resolving which identifier the agent should prefer.

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 and resource ('Get Warsaw Stock Exchange listing for a company') and enumerates the exact data returned, so the agent knows this is GPW stock/financial-market data. It does not explicitly contrast with siblings like get_financials or get_company, which could overlap on financials, so it stops short of a 5.

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 gives identification guidance ('Identify company by name, KRS, or NIP') and notes it is keyed by NIP, which implies usage context. However, it offers no explicit when-to-use versus alternatives, no exclusions, and no routing against siblings such as get_financials or get_financial_stats.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world lookup, so the safety profile is covered. The description adds real value beyond that by disclosing the returned data shape (activity flags, HQ decisions with issue and validity dates) and the keying behavior. It doesn't cover failure cases or pagination, keeping it short of a 5.

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 tight sentences: the first front-loads what data comes back, the second covers identifiers. Every clause earns its place, and the returned-field list is doing the work an absent output schema cannot.

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?

With no output schema and 100%-covered params, the description compensates by enumerating return fields, which is the right call. It is nearly complete for a read-only registry lookup; only the no-match/empty-result behavior is left unstated.

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 each of krs, nip, and name is already documented. The description reinforces NIP as preferred for BDO and name as a fallback, adding a light preference signal but no new syntax or format detail. Baseline 3 applies when the schema carries the 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?

Names a specific verb and resource ('Get BDO waste and packaging register data') and enumerates the exact payload (registration number, EUP site count, activity flags, headquarters decisions). The BDO waste/packaging registry is clearly distinct from the many other get_company_* registry siblings such as debt, court gazette, or sanctions, so an agent can route 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 states the lookup keys ('Keyed by NIP. Identify company by name, KRS, or NIP'), which implies usage but never says when to choose this tool over another registry lookup or what happens if no identifier matches. Context is present but there is no explicit when/when-not guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered without description help. The description adds the scope of returned data but says nothing about ordering, multi-year result shape, or behavior when no identifier matches.

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 tight sentences; the core scope is front-loaded and the identifier hint is appended where it belongs. The metrics list is somewhat enumeration-heavy but each named item conveys real return content.

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?

With no output schema and no annotations explaining returns, the description's enumeration of returned columns meaningfully compensates. It is nearly complete for this tool, lacking only the multi-period result structure and behavior on ambiguous or missing identifiers.

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, including year_from/year_to ranges. The description reinforces the identifier options (name, KRS, NIP) but adds no format detail, edge-case handling, or defaults beyond 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?

States a specific verb and resource ('Get full financial statement metrics per fiscal period') and names the underlying column set, which is concrete enough to distinguish this from a generic company lookup. It stops short of explicitly contrasting with the sibling get_financial_stats, so an agent must infer that this returns detail rather than aggregates.

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 tells you how to identify the company (name, KRS, or NIP), which is useful invocation guidance, but never says when to prefer this tool over get_financial_stats or get_company. Usage is implied by the field list rather than stated as a condition.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds useful non-structured context: results are 'precomputed', the recommendation to prefer median/winsor_mean over mean, and the cost_wages PLN-only constraint. No gaps that would mislead.

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, followed by the return set and usage examples. Efficient overall, though the inline list of returned statistics is dense; it earns its place given there is no output schema.

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?

With no output schema, the description compensates by enumerating the returned aggregates (median, p25/p75/p90, mean, total, n_companies, min/max), which is exactly what an agent needs. All parameters are documented in the schema, so nothing critical is 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?

Schema description coverage is 100%, so the schema already documents metric, currency, dimension_key, and dimension_type with enums and the PLN-only note. The description echoes the cost_wages constraint and adds the 'prefer median' guidance, but adds little syntax beyond the schema. Baseline 3 is appropriate.

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 and resource: 'Get precomputed aggregate financial statistics' for sectors/regions/PKD branches/countries. The word 'aggregate' implicitly distinguishes it from the company-level get_financials sibling, but it never names that alternative, so an agent must infer the boundary.

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 concrete example questions ('what is the median revenue / average profit / assets in industry X or region Y?') that clearly signal when to reach for this tool. It stops short of naming when-not-to-use or pointing to an alternative like get_financials for company-level data.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured fields. The description adds the returned field inventory (plan name, price, status, limits, credit balance, reset date), which is modest extra context but not behavioral depth like auth or rate-limit details.

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?

A single em-dash-delimited sentence that front-loads the verb and resource and packs the return-value enumeration efficiently. No filler, every clause earns its place.

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?

With no output schema, the description usefully compensates by listing the fields the caller will receive, and with zero params there is nothing else to document. It could be slightly stronger by noting the no-argument nature or routing to list_plans, but it is adequate for this simple read tool.

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 takes no parameters, so per the rubric this is a baseline 4. There is no parameter semantics to get wrong or explain.

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 ('Get the user's active billing plan details') and enumerates exactly what fields come back, so the agent knows this is a single-entity read rather than a catalog listing. It does not explicitly name list_plans as the contrasting sibling, so differentiation is left to inference.

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 word 'active' implies this is the tool for checking the current subscription state, but there is no explicit when-to-use statement and no mention of list_plans (catalog) or upgrade_plan (mutation) as alternatives. Usage is only implied.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value beyond that by spelling out the exact metrics returned plus the inclusion of limits and reset date, which is the key behavioral context for a quota tool and is especially useful given there is no output 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?

One front-loaded sentence naming the resource, then an em-dash list of metrics and a short clause on limits and reset date. No filler, and the highest-value information (usage + remaining quota) comes first.

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?

With no output schema, the description carries the return-value burden and does so by listing the metric keys, limits, and reset date. What remains missing is scope (which account/workspace the usage applies to) and the relationship to get_plan, both minor for a no-arg read tool.

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 takes zero parameters, so the baseline is 4. The description cannot add parameter meaning, and none is needed; the enumeration of metrics describes the response rather than inputs, which is a reasonable substitute.

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 ('Get') and resource ('current billing period usage and remaining quota') and enumerates the five metric buckets returned. It is clear what the tool does, but it never differentiates itself from the related sibling get_plan, so an agent must infer the boundary between 'usage/quota' and 'plan'.

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 phrase 'current billing period' implies a reporting context, but there is no statement of when to call this versus get_plan, get_financials, or the key-listing tools, and no mention of prerequisites or account scope. Usage is left entirely 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by specifying the 'active' filter and enumerating the returned fields (id, name, key_prefix, created_at, last_used_at), which the annotations do not convey.

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 short sentences, front-loaded with the action and scope, followed by the return fields. No filler or repetition.

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?

With no output schema, listing the returned fields is exactly the compensating detail needed, and annotations carry the safety profile. Nothing an agent needs to invoke this zero-arg list tool is 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?

The tool takes no parameters, so there is nothing to document; the schema is empty and 100% covered. The description correctly avoids inventing parameter 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?

States a specific verb (List) and resource (REST API keys) with explicit scoping ('active', 'cb_…', 'for the user's account'). The 'REST' qualifier cleanly separates it from the sibling list_mcp_keys, so an agent can route 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?

No guidance on when to use this versus list_mcp_keys, get_byok_keys, or create_api_key/delete_api_key. The purpose is implied clearly enough that misuse is unlikely, but no conditions or alternatives are 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds useful behavioral context: the result is scoped to active keys only and identifies the key format (mcpk_…), though it says nothing about ordering, limits, or permissions.

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 tight sentences, scope stated first, return fields second. Every clause earns its place with no filler.

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 parameterless read tool with annotations covering safety and no output schema, the description supplies what is otherwise missing: what is listed (active MCP keys) and what each item contains. An agent has everything needed 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it does not introduce confusion about inputs.

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 and resource ('List all active MCP keys (mcpk_…) for the user's account'), and naming the mcpk_ prefix distinguishes it from siblings like list_api_keys and get_byok_keys. It stops short of explicitly contrasting with those siblings, so a 4 rather than a 5.

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 'active' qualifier hints that only active keys are returned, but there is no guidance on when to call this versus list_api_keys, get_byok_keys, or create_mcp_key. No preconditions, no alternatives named.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds a genuinely useful behavioral fact not in annotations: 'No auth required', which tells the agent this can be called before credentials exist. It does not describe return format, but annotations carry the rest.

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 short sentences, zero waste, with the core purpose front-loaded and auth as the second beat. Every sentence carries new information.

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 no-param, no-output-schema read tool with rich annotations, the description covers purpose, auth requirement, and the natural next action. What a 'plan and limits' response actually contains is left implied, which is the only minor gap.

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 takes zero parameters, so the 4 baseline applies. The description correctly adds nothing about parameters and instead spends its words on auth and workflow context.

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 ('List') and resource ('Compabase billing plans and limits'), which cleanly separates it from the singular get_plan and the mutating upgrade_plan. It does not name those siblings explicitly, so an agent must infer the distinction from plural vs singular.

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 clear sequencing context: this is a pre/post sign-up catalog read, and it explicitly routes to upgrade_plan for checkout. It does not state when to prefer this over get_plan, but the usage window is clear.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that this is a scoped watchlist read with pagination, but says nothing about ordering, total counts, or behavior when the watchlist is empty.

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 tight sentences with no waste; the core purpose is front-loaded and the pagination note follows. Every clause earns its place.

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?

With no output schema, the description usefully enumerates returned fields, which an agent needs to know what it gets back. Combined with the read-only annotations, the definition is nearly complete; only ordering/empty-result behavior is unstated.

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 limit and offset with defaults and bounds. The description only restates that pagination is supported via limit/offset, adding no new meaning beyond the structured field documentation — 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 (list) and resource (user's watchlist companies), and enumerates the returned fields (name, KRS, NIP, revenue, city). It does not, however, explicitly distinguish itself from the sibling search_companies or add_to_watchlist, so the agent must infer the boundary.

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?

There is no when-to-use guidance and no mention of alternatives such as search_companies for non-watchlist lookups. The phrase "user's watchlist" hints at scope but no condition for choosing this tool over its many siblings is given.

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?

Annotations declare idempotentHint=true and destructiveHint=true, so the agent already knows this removes data. The description adds nothing beyond that – it doesn't say whether the removal is reversible, what gets deleted, or confirm the destructive nature. With full annotation coverage the bar is lower, but there is no added value.

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 and front-loaded with the action. Two short sentences, nothing wasted, though it borders on under-specification for a destructive 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?

For a destructive mutation with no output schema, the description omits important context: whether a company must be on the watchlist, error behavior, and consequences. Annotations cover safety hints but the description should complete the behavioral picture and doesn't.

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%, and the schema documents both krs and nip with format details. The description only lists the keys, adding no syntax or format beyond the schema. Baseline 3 is appropriate.

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 (Remove) and resource (company from watchlist), and uniquely names the identification keys. It is clearly distinguishable from siblings like add_to_watchlist and list_watchlist.

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 when-to-use guidance, no mention of alternatives or prerequisites. It doesn't state whether the company must already be on the watchlist or what happens if it isn't, nor does it reference add_to_watchlist.

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?

Annotations already declare the mutation profile (readOnlyHint=false, non-idempotent, open-world), and the description adds real value on top: it discloses the side effect (sends a magic link), the async follow-up step, the automatic MCP key delivery, and that no auth is required. It stops short of the return shape/rate details, but the flow disclosure is well beyond the annotations.

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?

Four tight sentences, front-loaded with the action, then the follow-up flow, then the anti-pattern warning. No filler; every sentence carries procedural information.

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 three-parameter initiation tool with no output schema, the description supplies everything an agent needs: the action, the async continuation, the automatic key delivery, and the absence of auth. Nothing required to call it correctly is 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?

Schema description coverage is 100%, so email, client, and locale are already documented in the schema. The description adds no parameter-specific meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 and resource ('Start Compabase account setup for an email') and immediately characterizes the mechanism ('Sends a magic link'). It clearly separates this initiation step from the sibling tool it names, check_signup, so an agent can pick the right one without opening a 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?

Gives the full operating procedure: poll check_signup with the returned setup_id until status is ready, and explicitly instructs not to ask the user to generate a key in the portal. This is a textbook when-to-use plus named-alternative plus explicit exclusion.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, and the 'add or update' phrasing is consistent with that. The description adds value beyond annotations by disclosing encryption at rest (AES-256-GCM) and the plan-gating requirement, though it says nothing about rate limits or how an overwrite affects an existing key.

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 compact sentences, action front-loaded, followed by guarantee, then constraint, then input formats. Every sentence carries distinct information with no filler.

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 two-parameter mutation tool with no output schema and annotations covering the safety profile, the description covers action, security, plan gating, and input formats. Only minor gaps remain, such as overwrite behavior on an existing provider key.

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 genuine meaning by pairing each provider enum value with its expected key prefix format (sk-, sk-ant-, AIza/AQ.), which helps validate input before the call.

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 pair ('Add or update') and resource ('BYOK provider API key'), which distinguishes it cleanly from delete_byok_key and get_byok_keys in the sibling list. An agent can identify the operation 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?

Gives a hard prerequisite ('Requires paid plan (Pro+)') and enumerates the supported providers, so the agent knows when the call is valid. It does not explicitly route to alternatives such as create_api_key or create_mcp_key, so it falls short of a 5.

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?

Annotations already declare the safety profile (not readOnly, not destructive, idempotent), so the bar is lower. The description adds genuine value by explaining the trigger events that produce an email (registry updates, new financial statements, deregistration), which is behavioral context not captured in any structured field.

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, zero waste, front-loaded with the purpose and followed by the behavioral consequence. Every sentence earns its place.

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 low-complexity, 3-param tool with 100% schema coverage, the description is nearly complete. The one gap is that no output schema exists and the 'get' return shape is never described in prose, though the schema's action description partially covers it.

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 baseline is 3, but the description goes beyond it by explaining the semantic consequence of email_notifications=true (receiving emails on watched-company data changes), adding meaning the schema's terse field description does not.

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 pair ('Get or update') and resource ('email notification preferences for watchlist changes'), clarifying that the tool handles both read and write despite the name 'set_'. No sibling covers notifications, so the agent can place it unambiguously.

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 explains the effect of enabling notifications but gives no explicit when-to-use guidance or when-not-to-use conditions. Usage is implied by the enum in 'action' rather than stated in the description, leaving the routing decision mostly to the schema.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the event taxonomy but does not disclose permission/auth needs, what 'delete' actually removes, or return behavior of 'get', so it adds only marginal context beyond the structured fields.

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 the tool's function and followed by the event list. No filler or repetition; only slight room to tighten the event enumeration.

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 3-parameter tool with full schema coverage and no output schema, the description covers the actions and events adequately. The one gap is that it doesn't describe what 'get' returns, which would be useful given the absence of an output schema.

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 genuine value by enumerating the concrete event type values (watchlist.company_changed, etc.) that the schema only refers to generically as 'event types'. It does not clarify the url parameter, but the schema handles that.

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 set (configure/view/remove) and the exact resource (webhook for watchlist event notifications), and it correctly expands the name beyond the narrow 'set' implied by the tool name. No sibling tool shares this scope, so an agent can identify it unambiguously.

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 action enum in the schema carries the get/set/delete routing, and the description reinforces the three modes implicitly. However, it offers no explicit when-to-use guidance, prerequisites, or tradeoffs for choosing this over alternatives (there are effectively none), leaving usage 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?

Annotations already declare openWorldHint, non-idempotent and non-readonly. The description adds genuinely new behavior: the result is a checkout_url on the external checkout.stripe.com domain that must be opened in a browser for the user to pay. It does not cover failure/expiry behavior of the session.

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 tight sentences, front-loaded with the action, then the constraint, then the return value. No filler; each sentence carries distinct information.

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?

With no output schema, the description correctly explains the return (checkout_url) and where it lives. The one gap is that required_parameters is 0 while plan_id is described as needed to produce a URL, so the no-plan_id behavior is left 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% with enums documented for all three parameters, so the baseline is 3. The description repeats the plan_id values ('pro' or 'scale') without adding format or normalization detail beyond 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?

States a specific verb and resource: 'Create a Stripe Checkout session for a plan upgrade.' This clearly separates it from siblings like list_plans and get_plan, which retrieve plan data rather than initiate payment.

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 explicit workflow ('Pass plan_id ... open it in the browser for the user to pay') and an exclusion ('Do not send the user to the marketing pricing page'). It does not, however, point to list_plans/get_plan as the way to discover plans, leaving that routing to inference.

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