IsraBase

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful return-content context that annotations cannot convey: unlisted companies are included, and the response carries the IsraBase page URL and nesach order URL.

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 key fact (what record, keyed by what) is front-loaded and the whole thing is short. The Hebrew sentence duplicates the English content, but it plausibly serves Hebrew-query matching, so the redundancy is defensible rather than wasteful.

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 must hint at returns, and it does: unlisted-company coverage plus the two URLs. It is slightly thin on what other fields the record contains (status, directors, etc.), but nothing needed to invoke the tool 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 coverage is 100% – the single parameter is fully documented with a 9-digit pattern and integer range. The description only adds the Hebrew term ח.פ as an alias, which is mild value 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: retrieve the full registry record for one Israeli company, keyed by its 9-digit ח.פ. The 'one company by number' framing implicitly separates it from search_companies, though no sibling is named explicitly.

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

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

Usage is only implied: an agent infers it should call this when it already holds a company number and wants the detail record. There is no explicit when-not (e.g., 'use search_companies if you only have a name') and no prerequisites 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 cover safety (readOnly, idempotent, non-destructive), and the description adds real value beyond them: the price (38 ILS incl. VAT) and the explicit statement that the tool does not take payment. It still doesn't say what the response looks like (a URL string), but the cost/no-payment disclosure is meaningful context.

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

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

Short and front-loaded, with the core purpose stated first and the cost caveat last. The bilingual English/Hebrew pair repeats the same content, which is mild redundancy but justified for Hebrew-speaking users.

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 link tool with no output schema and annotations already carrying the safety profile, the description covers what it returns, what it costs, and what it does not do. Only the return format 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?

There is one parameter and schema coverage is 100%, with the schema fully documenting the 9-digit company number as string or integer. The description adds no further parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete outcome — returning a link to order an official company extract (נסח חברה) on IsraBase — which is a specific verb+resource. It is implicitly distinguishable from the data-fetching siblings (get_company, search_companies), but it never names or contrasts them explicitly.

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

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

Usage is only implied: an agent can infer this is for when a user wants to purchase an official extract. There is no stated when-not-to-use case and no pointer to any sibling tool for related needs.

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, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower. The description still adds real value by disclosing coverage scope — records outside public listings are returned here — which tells the agent this tool can succeed where a listing search returns nothing.

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 purpose and scope caveat second. The Hebrew sentence duplicates the English content, which costs space for monolingual readers but is defensible given the Israeli nonprofit domain.

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 state the result is a 'Full registry record.' Combined with annotations that fully cover the safety profile and a 100%-documented single parameter, this is close to complete; a brief note on the record's shape would make it airtight.

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 single parameter's format (string pattern or integer) is fully documented in the schema. The description only restates that lookup is by registration number, adding no syntax or formatting detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Full registry record for one Israeli nonprofit') and the exact lookup key ('by registration number'). It is cleanly distinguishable from siblings like get_company and get_partnership by entity type and identifier, so an agent needn't open schemas to pick it.

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: use this when you have a registration number and need the complete record rather than a listing. The line 'Includes nonprofits that are not in the public listings' hints at an advantage over search/list tools, but it never explicitly says when to prefer this over search_companies or list_marketplace_listings, nor that a registration number is required first.

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 and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact - that non-public-listing partnerships are included - but says nothing about not-found behavior or record completeness.

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?

Short and front-loaded: the resource and key come first, then the scoping note. The mirrored Hebrew sentence is redundant for an English-speaking agent, though it may aid Hebrew query matching, so it is not pure 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 still gives no sense of what a 'full registry record' contains, and openWorldHint is the only signal about scope. For a single-parameter lookup with strong annotations this is adequate but leaves the return shape entirely 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 the single parameter already documents both accepted types and the numeric pattern. 'By registration number' restates the schema rather than adding format, range or edge-case guidance, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Full registry record for one Israeli partnership') and the lookup key ('by registration number'). The entity noun 'partnership' inherently separates it from get_company and get_nonprofit, though no sibling is called out explicitly.

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

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

Usage is only implied: an agent can infer you call this when you already have a partnership number. There is no explicit when-to-use framing and no mention of when to prefer search_companies or list_marketplace_listings instead.

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 and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the provenance note that figures match the IsraBase statistics page; it says nothing about aggregation lag, caching, or result shape, so it adds modest value on top of 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?

It is short and front-loaded, with the data contents first and provenance last. However, the Hebrew sentence is a verbatim translation of the English one and consumes half the description without adding information for the calling agent, so not 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 no-parameter, read-only aggregate tool with no output schema, the description covers what the call returns at a high level (totals, status breakdown, top cities), which is the main thing an agent needs. Exact field names and structure are unstated, but that gap is minor given the tool's simplicity.

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 there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies the call is argument-free by describing a fixed aggregate view.

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 resource (registry statistics) and enumerates its contents: totals, company status breakdown, and top cities. That is enough to distinguish it from the entity-lookup siblings (get_company, search_companies), though it never states an explicit verb or directly contrasts itself with them.

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, no prerequisites, and no mention of alternatives. 'Same figures as the IsraBase statistics page' establishes provenance of the data but not the condition under which an agent should call this tool rather than search_companies or list_marketplace_listings.

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=true, idempotent=true and non-destructive, so the safety profile is covered. The description adds two useful facts: results are filtered to 'visible' companies, and the rows mirror the GET /api/v1/companies/by-city endpoint. It says nothing about ordering or pagination behavior, so it only modestly exceeds the annotation baseline.

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?

Short and front-loaded, but the description is repeated verbatim in Hebrew with no added information, and the endpoint-reference sentence is cryptic without elaboration. Roughly a third of the text does not earn 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 read-only, single-filter list tool with 100% schema coverage and no output schema, the basics are present and the endpoint parity note is a useful hint. However, nothing is said about result ordering, total counts, or how the pagination window behaves, leaving real gaps for agent planning.

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 city, limit and offset are fully documented in the schema itself. The description adds no parameter detail beyond what the schema already provides, making 3 the 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?

States the resource (companies) and the scoping filter (one city), which clearly distinguishes it from siblings like list_companies_by_type and list_companies_by_year. The word 'visible' is left unexplained, mildly clouding the scope.

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

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

No indication of when to use this versus search_companies or the other list_* siblings, and no stated prerequisites. The agent must infer selection 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds two useful behavioral facts beyond that: results are limited to 'visible' companies, and the output matches the GET /api/v1/companies/by-type endpoint. It says nothing about auth, rate limits, or pagination 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?

The description is short and the filtering scope is front-loaded, which is good. However, the Hebrew sentence 'חברות גלויות לפי סוג' is a verbatim restatement of the title and adds no information, so not 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 simple filtered-list tool with no output schema and fully documented parameters, the description covers scope, allowed segments, and result parity with the HTTP endpoint. It leaves return shape and pagination semantics implicit, 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%, so all three parameters (type, limit, offset) are already documented in the schema, including the enum values and bounds. The description restates the enum values but adds no meaning beyond the schema, 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?

The description states a specific verb (list) applied to a specific resource (companies) with a clear scope: 'visible companies in one segment,' and enumerates the four segment values. This distinguishes it functionally from list_companies_by_city and list_companies_by_year, though it never names those siblings explicitly.

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

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

There is no explicit guidance on when to use this tool versus search_companies or the other list_* siblings, nor any stated prerequisites. The only hint is the implied 'visible companies' scoping, which is a data property rather than usage 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — only 'visible' companies are returned — plus a REST endpoint cross-reference, but says nothing about permissions, result ordering, or pagination 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?

The core meaning is front-loaded in a single short clause, and the REST endpoint reference is useful for cross-referencing. The Hebrew restatement is redundant for most agents and does not earn its place, keeping this below a 5.

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 read with full schema coverage and annotations, the description is adequate but thin: with no output schema, it should say something about the returned row shape or result ordering/pagination, and it offers only an API path as a proxy.

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%: year (1900-2026), limit (max 100, default 20), and offset (max 200000) are all documented in the schema. The description adds no format, default, or range detail beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with a clear scope: companies registered in one year. The parallel siblings (list_companies_by_city, list_companies_by_type) make the slice obvious, but the description never names or contrasts them, 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?

There is no explicit when-to-use, when-not-to-use, or alternative named. An agent must infer from the sibling names that this is the year-based slice; the description itself provides no routing 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description adds genuinely useful behavioral context: confidential listings are 'blind-safe' and carry no company number. That tells the agent not to expect a company identifier on every row, which it could not learn from the schema. It still says nothing about pagination or result shape.

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 short and front-loads the resource name, but the Hebrew text restates the same two facts already given in English ('active listings only', 'discreet listing has no company number'), so roughly half the content is duplicated rather than additive.

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 should say more about what a listing contains; it only discloses the blind-safe quirk. Combined with 100%-covered parameters and safety annotations, this is adequate but leaves the agent guessing about the returned fields.

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 city, limit, and category are already documented with types and constraints (max 20, default 10). The description adds no parameter-level meaning, 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?

The description names a specific resource (IsraBase marketplace listings / עסקים למכירה) and a scope constraint ('active listings only'), so the agent knows this is a browse-the-marketplace tool rather than a company lookup. It does not explicitly contrast itself with search_companies, but the resource is distinct enough to distinguish from 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?

There is no statement of when to use this tool versus search_companies or get_company, and no exclusions or prerequisites. The only usage signal is the implicit 'active listings only' scope, which the agent must infer.

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, openWorld and non-destructive, so the safety profile is carried. The description adds one genuinely useful behavioral fact — only 'visible' companies are returned — plus an equivalence note to the REST endpoint GET /api/v1/companies/recent, but says nothing about ordering direction guarantees, rate limits, or response shape. Modest value 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?

Front-loaded with the core fact, which is good, but the Hebrew sentence repeats the English one verbatim in meaning and the REST endpoint sentence is only marginally informative for an agent, so not 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 simple two-parameter listing tool with no output schema and full annotation coverage, the description covers the key essentials: what rows come back (visible companies), their ordering, and pagination handled by the schema. Missing only explicit sibling routing, which is a 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?

Schema description coverage is 100%, with both limit and offset fully documented (ranges and defaults), so the schema does the heavy lifting. The description adds no pagination syntax or meaning beyond the schema, which is the expected baseline of 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 (list companies) plus the ordering criterion (by incorporation date) and a scope qualifier ('visible'), which clearly separates it from list_companies_by_city/type/year. It does not explicitly name 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?

Usage is only implied: 'newest ... by incorporation date' suggests when an agent would pick this over the sibling list_* tools, but there is no explicit when-to-use statement, prerequisite, or named alternative. Adequate but leaves the 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 cover readOnly, idempotent, non-destructive and openWorld, so the bar is lower. The description still adds real context: active_only defaults to true and filters to publicly listed rows, and segment maps to the HTTP API type query. It does not describe result shape or pagination, but that is a minor gap given annotation coverage.

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 core action and search keys, then parameter-specific notes. The segment clarification is repeated between description and schema and the bilingual duplication adds length, but both serve a real purpose and nothing is wasted outright.

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 7-parameter search tool with no output schema and full annotation coverage, the description supplies the non-obvious semantics (active_only filter, segment mapping, company-only scope). Missing is any hint about result ordering, pagination or what a hit contains, which an agent may need to chain searches 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%, so baseline is 3; the description earns an extra point by clarifying that segment uses the HTTP API type values (government/public/foreign/bonds) and that city/status/segment apply only to companies. It also explains the active_only semantics beyond the terse schema line.

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 (search companies/nonprofits/partnerships) plus the matching keys (name or number), and explicitly contrasts with the get_* siblings. An agent can distinguish it from list_companies_by_* and get_* 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?

Explicitly says direct get_* tools look up by number regardless of listing, which routes the agent away from this tool for exact lookups. Also documents the active_only toggle condition. It does not address overlap with siblings like list_companies_by_city when the city param is used, so it falls short of full when/when-not coverage.

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