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

With no annotations, the description carries full behavioral burden. It conveys a read-only preflight role ('Get ... Call this first') and the exact information returned. It doesn't cover things like authentication failure behavior or whether the request itself consumes usage, but for a simple 0-param account-info call this is adequate.

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

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

Two purposeful sentences: the first names the resource and return payload, the second states when to call it. No filler or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 0-parameter, no-output-schema info endpoint, the description is complete: it names the resource, the return categories, and the recommended invocation order. Siblings are sufficiently distinguishable from 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?

There are no parameters, so the schema is complete. The description adds context about what the returned account info contains, which is sufficient at the baseline for a 0-param tool.

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?

Description uses a specific verb and resource ('Get the authenticated Kooperativa account's') and enumerates the exact returned data: email, license status, and per-endpoint API usage. This clearly differentiates it from sibling tools that operate on people, companies, or monitors.

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 explicit context: call this first if unsure whether the license is active before running a large batch job. It does not list exclusions or directly name alternatives, so it falls just 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It usefully discloses that unmatched identifiers are silently skipped and counted in not_found, and that each array item must contain exactly one identifier. It stops short of explaining the full response shape or any side effects of enrichment, but the key edge-case behavior is well covered.

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

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

The description is three short sentences with no filler. The most important fact (batch size and single-call behavior) is front-loaded, followed by the payload requirement and the unmatched-identifier handling. Every sentence contributes meaningful 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?

Given the simple one-parameter schema and no output schema, the description covers the critical invocation details: batch limit, identifier selection, and partial-failure behavior. It is slightly incomplete in not describing what a successful response contains beyond not_found, but it is strong enough for an agent 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%, and the description mostly restates what the schema already says about the profiles array and the exactly-one-identifier rule. It adds a small amount of semantic value by clarifying behavior around unmatched identifiers, but it does not provide format examples or additional parameter context 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?

The description clearly states a specific verb ('enrich'), resource ('profiles'), and batch scope ('up to 100 profiles in a single call'). This distinguishes it from the singular sibling tool kooperativa_enrich_person, so an agent can immediately tell what this tool does and how it differs.

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

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

The description implies bulk usage ('up to 100 profiles in a single call') but does not explicitly state when to use this tool versus kooperativa_enrich_person or other people-related siblings. There is no mention of when not to use it or which alternative to prefer for a single profile.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the cheap/no-full-record behavior and specifies success return fields (id, name, fetched_at) plus the 404 case. It does not mention parameter precedence or side effects, but for a read-only existence check the disclosed behavior is reasonably complete.

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 filler. The key value proposition (cheap existence check) is front-loaded, and the return/error behavior is stated compactly.

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 four optional parameters and no required fields, the description should clarify that at least one identifier must be supplied and how multiple identifiers are handled. The absence of this guidance, combined with no output schema, leaves a meaningful gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning about how the parameters relate or whether one is required, so it stays at the baseline for well-covered schemas.

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

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

The description clearly states a specific action (cheaply check whether Kooperativa already holds a company) and a scope (existence check without fetching the full record). It also distinguishes itself from related tools like enrich_company and search_companies by emphasizing the lightweight, existence-only nature.

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 conveys when to use this tool: when you only need to verify existence cheaply rather than fetch the full record. It does not explicitly name alternatives or state when not to use it, but the use case is clearly 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It clearly states the low-cost read-only nature, explicitly says it does not fetch the full record, and discloses the success payload (matched id, full_name, fetched_at) and the failure case (404 if not indexed). It could add more detail about rate limits or error behavior beyond 404, but for a check-existence tool this is strong disclosure.

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

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

Three sentences carry substantial information: the operational behavior, the return/error semantics, and the use case. Every sentence earns its place, and the description is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description does well by specifying the return fields and the 404 case. The main gap is that all three parameters are optional with no stated requirement that one must be provided, and there is no note on which identifier takes precedence. But for a lightweight existence check, the description covers the essential operational context.

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 adds meaning by framing the parameters as alternative ways to identify a profile ('given profile'), but it does not explicitly say that exactly one of the three identifiers is expected. Since the schema requires none of them, the description could be clearer on the selection logic. Still, the existence-check context plus full schema coverage makes the parameters understandable.

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 ('check'), resource ('whether Kooperativa already holds a given profile'), and the key behavioral distinction: it is cheap and does not fetch the full record. It also names the sibling tool enrich_person, which helps disambiguate it from related operations.

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

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

The description explicitly says when to use it: 'Use this to filter a list before calling enrich_person on each one.' This is a clear usage directive, and the mention of enrich_person as the next step provides an alternative/complementary tool context. It also communicates an important non-goal: it does not fetch the full record.

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

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

With no annotations, the description carries the behavioral burden. It discloses that results are 'lightweight profile previews', that pagination is offset-based, and that the response includes total/pages. This is useful operational detail for a read-only listing tool, though it does not cover edge cases or potential failure 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?

Two sentences with no wasted words: the first states the action, scope, and required input; the second describes return shape and the natural next step. Information is front-loaded and the routing to enrich_person is placed exactly where a user would need it.

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 listing tool with no output schema and no annotations, the description covers the essential facts: what it lists, how to identify the company, what the response looks like, and how to continue processing a result. It leaves some detail implicit, such as exact profile fields, but is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, but the description adds the 'offset pagination (total/pages)' concept, which gives page and per_page parameters meaningful context. However, it mostly restates company_id as 'numeric', and it does not explicitly describe how page/per_page behave beyond the schema defaults.

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

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

The description opens with a specific action and resource: 'List people currently working at a company' and clearly identifies the required input ('numeric company_id'). The word 'currently' differentiates it from sibling kooperativa_company_past_employees, so purpose 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?

The description gives clear context: use this tool for current-employee lists keyed by company_id. It also provides a downstream workflow by routing result IDs to kooperativa_enrich_person. It does not explicitly exclude alternatives or name kooperativa_company_past_employees, but the 'currently working' language makes the primary use case 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?

With no annotations, the description carries the burden of disclosing behavior. It usefully warns that counts reflect only Kooperativa's indexed profiles, not the company's real total headcount. However, it does not mention data freshness, error behavior for unknown companies, or any other operational caveats.

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 concise sentences provide the core behavior, the seniority levels, the use cases, and the important limitation. There is no redundancy or filler, and the main purpose 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?

For a single-parameter tool with no output schema, the description explains the expected breakdown and the indexed-profiles caveat. It is mostly complete, though it could mention how to interpret missing or blank seniority categories.

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 only one parameter, company_id, and its schema description already covers it as a numeric company ID. The tool description adds no further parameter-level meaning, which is acceptable given 100% schema description coverage.

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 resource (company headcount by seniority) and the exact output (breakdown by c-level, vp, director, manager, individual). It also distinguishes this tool from a real total-headcount metric by clarifying it uses Kooperativa's indexed profiles, which separates it from sibling company 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 explicitly names use cases: org intelligence and account qualification. It does not compare against alternatives like kooperativa_company_current_employees, but the intended context is clear enough for an agent to decide when this breakdown is relevant.

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

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

With no annotations, the description carries the burden and does provide useful behavioral facts: ordering by join date descending, default look-back 90 days, max 365 days. However, it does not disclose response shape, pagination behavior, or whether results are limited to current employees, and there is no safety or auth information.

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, front-loaded sentence packs the core concept, ordering behavior, and key parameter constraints with 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?

The description is adequate for a basic listing call: required company_id is in the schema, days is explained with defaults, and page/per_page have schema defaults. But it is incomplete without annotations or an output schema: no mention of auth, rate limits, result fields, or how hiring signals differ from current/past employee tools.

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 description adds semantics for the look-back window (default 90, max 365) complementing the days parameter in the schema. company_id and days already have schema descriptions; page and per_page are undocumented in both schema and description, though their names and defaults make them fairly self-explanatory.

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

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

The description clearly identifies the resource (people who recently joined a company) and the concept (hiring signals), and adds distinguishing details: sorted by join date descending and a configurable look-back window. It lacks an explicit verb like 'list' or 'get', but the meaning is unambiguous and distinct from sibling tools such as current/past employees.

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 a clear use context: hiring signals indicate growth, investment, or expansion. It does not explicitly name alternatives or exclusion conditions, but an agent can infer when this tool is relevant from the stated signal rationale.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses what each result contains (a past_positions array with specific roles) and notes the pagination style (has_more/next_page). This is meaningful behavioral context beyond the schema, though it does not cover edge cases like invalid company IDs or result ordering.

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 contain all essential information with no filler. The core purpose is front-loaded, followed by result shape and pagination behavior. 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 paginated list tool with no output schema, the description covers the main facts needed to call it: what it returns, the past_positions array, and pagination. It could be more complete by explicitly mapping page/per_page to the pagination mechanism or describing typical response fields, but nothing critical is missing for a basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%; company_id is documented in the schema, while page and per_page are not described. The description reinforces that company_id is numeric and mentions pagination, which indirectly relates to page/per_page, but it does not explicitly explain the pagination parameters or their semantics. This is partial compensation for a low-coverage 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 uses a specific verb ('List'), identifies the resource ('people who previously worked at a company'), and explains the core concept with 'held a role there, since moved on'. It clearly distinguishes this from current-employee tools by emphasizing previously/ past positions, making sibling differentiation easy.

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 clearly frames when this tool is relevant: when listing former employees of a specific company. It does not explicitly name alternatives or exclusions, but the phrase 'since moved on' implies a boundary against current-employee tools, and the sibling names reinforce that context.

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

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

With no annotations provided, the description carries full behavioral disclosure, and it does so excellently. It states that Kooperativa sends a signed POST, requires HTTPS, enumerates monitored event types, and warns that the webhook_secret is displayed only once at creation time.

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

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

The description is three sentences, tightly written, with the core purpose front-loaded and critical caveats (HTTPS requirement and one-time secret) placed immediately after. Every sentence contributes useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description provides enough context to invoke the tool correctly: what events are monitored, how delivery works, the callback constraint, and the key return artifact (webhook_secret). No critical operational detail appears 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 meaningful extra semantics: webhook_url must be HTTPS, subject_url refers to a professional profile or company URL, and the events parameter is clarified with concrete examples per entity type.

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

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

The description clearly states the action ('Subscribe to change events') and the resource ('professional profile or company URL'), making the tool's purpose immediately identifiable. It also distinguishes itself from sibling tools like list_monitors or delete_monitor through the creation-specific webhook behavior and one-time secret disclosure.

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 for when to use this tool: to receive change notifications for monitored profiles or companies via a webhook. It does not explicitly mention alternatives or when not to use it, so it stops short of full 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?

With no annotations, the description carries the burden of disclosing behavior. It states the core action ('stop monitoring... delete the monitor') but reveals nothing about permanence, side effects, permissions, or failure behavior. The description is close to repeating the tool name and does not add meaningful behavioral context beyond the literal delete action.

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

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

The description is a single, compact sentence that front-loads the action ('Stop monitoring...') and the resource ('delete the monitor'). Every word is meaningful; there is no redundancy or 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 simple one-parameter delete operation with no output schema, the description is largely sufficient: it names the action, the target, and the identifier. It could improve by mentioning that the monitor ID can be obtained from kooperativa_list_monitors, but this is not essential for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single 'id' parameter is already clearly documented as 'Monitor ID to delete (UUID).' The description's 'delete the monitor by its ID' simply echoes the schema, adding no additional semantic value. 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?

The description uses a specific verb-resource pair, 'delete the monitor,' and clearly identifies the target by ID. It also clarifies that deletion stops monitoring, which distinguishes it from creating or listing monitors.

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

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

The description implies the use case: stop monitoring and delete a specific monitor. However, it does not explicitly say to use kooperativa_list_monitors to retrieve the ID first, nor does it contrast with kooperativa_create_monitor or other monitoring-related tools.

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

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

With no annotations, the description carries the disclosure burden. It usefully states 'Returns 404 if not indexed yet' and frames the operation as a read-only lookup, but it does not mention authentication requirements, rate limits, or behavior when multiple identifiers are supplied despite the 'exactly one' instruction.

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 front-loaded sentences cover output scope, input constraints, and error behavior with no filler or repetition of the title. Every clause contributes information an agent needs.

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?

Even without an output schema or annotations, the description is nearly complete: it names the returned profile fields, the accepted identifier types, and the failure mode. It could mention response shape or side effects, but for a lookup tool whose returned fields are listed, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by stating the mutual-exclusion rule 'Provide exactly one of linkedin_url, username, company_id, or id' and by noting the 404 outcome for unmatched identifiers, neither of which the JSON schema enforces.

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 opens with a specific verb ('Look up') and resource ('a company's full profile') and enumerates concrete data fields (headcount, follower count, founding year, HQ address, industries, specialities, office locations). This clearly distinguishes it from search/check siblings and explains what 'enrich' means operationally.

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

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

The description implies usage: when an agent already has one of the four identifiers and needs a complete company profile, use this tool. However, it never explicitly says when not to use it or points to alternatives such as kooperativa_search_companies or kooperativa_check_company for finding/verifying companies.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the 404 response for unindexed profiles and states that there is no on-demand live scrape, which sets accurate failure expectations. It does not mention auth or rate limits, but the key behavioral traits for a lookup operation are present.

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 exactly two sentences with no wasted words. It front-loads the action and data scope, then states the identifier constraint, then the failure behavior. It avoids repeating schema descriptions.

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, but the description lists the expected profile content categories and the 404 failure mode, which gives an agent enough context to call the tool correctly. It does not describe the exact response envelope, but for a single-profile lookup this is a minor gap rather than a critical one.

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%, with descriptions for each parameter already provided. The description adds the meaningful mutual-exclusion rule 'exactly one of linkedin_url, username, or id', which the schema does not encode. This goes beyond what the structured schema alone communicates.

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 uses a specific verb ('Look up') and resource ('person's full professional profile from the Kooperativa data lake'), and enumerates content categories (work history, education, skills, etc.). It clearly distinguishes this from search or check tools by emphasizing a complete profile and by constraining input to exactly one identifier.

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

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

The description implies when to use the tool (when a full indexed profile is needed) and gives the 'exactly one of' identifier instruction, but it does not explicitly name sibling alternatives like check_person, search_people, or bulk_enrich_people. The live-scrape caveat is a limitation, not a routing rule for choosing a different 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?

With no annotations available, the description carries the behavioral disclosure burden. It helpfully states that no authentication is required and characterizes the operation as a simple liveness probe, implying a lightweight, read-only connectivity check. It does not detail the exact response format, but this is a minor gap for such a simple tool.

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

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

The description is two short sentences with no filler. The core purpose and the key behavioral fact (no authentication) are front-loaded, and the usage guidance follows immediately.

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 zero-parameter liveness probe with no output schema, the description is fully adequate. It tells the agent what the tool does, that it needs no auth, and when to invoke it. 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?

The tool has zero parameters, so there is no parameter semantics burden. The baseline of 4 applies, and the description adds no misleading or unnecessary parameter-related information.

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

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

The description clearly identifies the tool as a 'Simple liveness probe for the Kooperativa API' with the specific purpose of verifying connectivity. It is easily distinguishable from the data-oriented sibling tools, which all perform operations like enrichment, search, or monitoring.

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 an explicit use case: 'Use to verify connectivity before running a batch job.' This provides clear contextual guidance, though it does not mention when not to use it or name alternatives—not necessary here since no sibling tool serves the same purpose.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that the operation is read-only, workspace-scoped, and filters to active monitors, which is useful. However, it does not mention return format, pagination, or how it behaves when no monitors exist, leaving some behavioral ambiguity.

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, front-loaded sentence says exactly what the tool does with no filler. Every word 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, no-output-schema, read-only listing tool, the description is complete. It names the resource, the filter, and the auth scope, which is sufficient for an agent to select and 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?

The tool has zero parameters, so there is nothing to document. The description still adds useful context by specifying the workspace scope and active-monitor filter, which is more than the empty schema provides.

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

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

The description states a specific action ('List'), a specific resource ('webhook monitors'), and a scope ('active' and 'authenticated workspace'). It clearly distinguishes itself from sibling tools like create_monitor and delete_monitor by being the read-only listing operation.

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 makes the use case clear: retrieve active webhook monitors for the current workspace. It does not explicitly name alternatives or when not to use this tool, but the sibling names and the 'list' framing provide enough context for an agent to select it for read/monitoring scenarios.

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

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

With no annotations supplied, the description carries the burden of explaining behavior. It is transparent that this is a read-only listing of current colleagues, excludes the person themselves ('everyone else'), and is limited to the profile's current company. It does not go into pagination limits or error cases, but the core behavior is clearly 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 description is two sentences and front-loads the action and scope immediately. The use-case sentence earns its place by helping with tool selection, and there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one required parameter, the description covers purpose, scope, and input provenance. It doesn't describe the return format, and there is no output schema, but the fact that it returns current colleagues is strongly implied by the definition; only minor details like pagination behavior are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% because only the id parameter has a description. The description adds value by telling the agent where to obtain the id (from enrich_person or search_people), but it does not explain page or per_page beyond their schema defaults, so it only partially compensates for the low schema coverage.

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 opens with a specific action and resource: 'List a person's current colleagues.' It also refines the scope with '(everyone else working at their current company right now)', which clearly distinguishes this from related sibling tools like company_current_employees or person_job_changes.

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 concrete use cases ('mapping org structure or finding an alternate contact at a target account') and gives the prerequisite input source, the Kooperativa profile id from enrich_person or search_people. It does not explicitly name alternatives or state when not to use it, so it misses the highest bar.

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

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

With no annotations, the description carries the burden and it does disclose important behavior: the returned set is people with recent new jobs, optionally filtered by prior company, and ordered most-recent-first. It does not discuss read-only status or output shape, but as a non-mutating list tool this is a reasonable disclosure.

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: use case, optional filter, and sort order. No filler; the most important semantic ('new role = new budget') 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?

For a simple optional-parameter list tool with no output schema, it covers the core invocation facts: target population, previous-company filter, and ordering. It could be stronger by mentioning that days controls the recency window and that results are paginated, but those are already represented 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 50%, so the description does not get the automatic baseline from high schema coverage. It adds clarity that company_id is an optional prior-company filter, but it largely repeats the schema's company_id description and does not elaborate on days, page, or per_page beyond what defaults convey.

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

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

The description clearly identifies the output as people who recently started a new job, and the 'sorted most-recent-first' note pins down the resource and ordering. This distinguishes it from sibling tools like company_current_employees, company_past_employees, and search_people by its focus on individual job changes.

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 use case ('strong outreach signal... new budget, new vendor decisions'), which tells an agent when this signal matters. It does not name alternatives or say when not to use it, so it falls short of the full 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?

No annotations are provided, so the description must carry the behavioral burden. It discloses the core behavior (returns similar people, excluding the input person) and the required input. However, it does not explicitly state that the operation is read-only, describe pagination behavior, or mention output structure.

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

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

Three concise, purposeful sentences front-load the core purpose, then add use cases and the key requirement. There is no filler or redundant explanation.

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 lookup-style tool, the description provides enough to select and call it: purpose, similarity criteria, use cases, and the required profile id. Pagination defaults are in the schema, and the read-only nature is implied by 'Find.' Minor gaps remain around output format and auth details, but they are not critical for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%: only 'id' is described, and the description merely repeats that the profile id is required. The pagination parameters (page, per_page) are undocumented in both the schema and the description, so the description fails to compensate for the low coverage.

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 uses a specific verb and resource: 'Find people similar to a given person' with explicit criteria (same seniority, industry, and country) and an exclusion rule ('excluding themselves'). This clearly differentiates it from siblings like search_people, person_colleagues, and check_person.

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 concrete use cases ('lookalike audiences or finding alternative contacts at competing companies') and states the prerequisite ('Requires the Kooperativa profile id'). It does not explicitly list when-not-to-use or alternatives, but the context is clear enough for routing.

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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It discloses non-obvious behavior: at least one filter is required, filters use AND logic, min_staff/max_staff are inclusive, and either staff bound can be omitted. It does not describe response shape or pagination behavior, but the tool is read-only by nature and schema covers pagination defaults.

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 two tight sentences with no filler. It front-loads the action and resource, then immediately lists the key constraints. Every sentence adds value.

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?

The description covers the most important non-schema requirements: at least one filter, AND logic, and inclusive staff bounds. A note about result/pagination behavior would be helpful since there is no output schema, but the schema's defaults and the tool's clear search purpose make the description sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the baseline is 3. The description adds meaningful cross-parameter semantics beyond individual property descriptions: filters combine with AND, at least one filter is required, and min_staff/max_staff inclusivity with optional omission. This helps the agent construct valid requests.

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?

Description clearly states a specific verb and resource: 'Search the Kooperativa data lake of companies' with the key filters (name, HQ location, industry, headcount range). It does not explicitly name or exclude sibling tools like kooperativa_search_people, so sibling differentiation is implied rather than stated.

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 operational context: filters are optional individually, combine with AND, and at least one is required. However, it does not say when to prefer this tool over sibling alternatives such as kooperativa_search_people, kooperativa_enrich_company, or kooperativa_check_company.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It meaningfully explains that filters combine with AND logic, that results are lightweight previews, and that pagination is applied. It does not cover potential edge behavior such as empty results, sort order, or rate limits, but it discloses the most important operational traits.

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

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

Two sentences with no filler: the first states purpose and scope, the second conveys filtering behavior, return type, pagination, and routing to enrichment. Every clause earns its place and the most important information 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?

Given the tool's complexity, the description covers the essential workflow: filter, paginate, retrieve previews, then enrich. It does not describe the output fields or pagination specifics, and there is no output schema to fill that gap, but for a search tool with zero required parameters it is reasonably 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 68%, so many parameters are already described in the schema. The description adds useful high-level semantics such as AND logic and the general filter categories, but it does not compensate for the undocumented parameters (city, page, per_page, boolean flags, seniority). For a 22-parameter tool, this is adequate but not exemplary.

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

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

States a specific verb ('Search') and resource ('Kooperativa data lake of professional profiles'), and lists the main filter dimensions. It clearly differentiates from kooperativa_enrich_person by noting it returns previews and that full records require a follow-up call, and from kooperativa_search_companies by targeting profiles rather than companies.

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 a clear search use case: combine filters, get previews, then pass an id to kooperativa_enrich_person for full data. It does not explicitly spell out when not to use this tool versus sibling tools like kooperativa_person_colleagues or kooperativa_check_person, but the search-and-enrich workflow is clearly implied.

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