Intakra Public Signal Review

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

Annotations already declare a non-destructive, idempotent write; the description goes beyond them by disclosing dedup behavior ('domains already on your list are skipped'), a plan-level account cap, and the asynchronous processing model ('next daily pass'). It omits what happens on partial failure or when the cap is exceeded.

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, each earning its place: what it does, when processing happens, and the dedup/limit caveats. The primary action and its keying mechanism are 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 mutation with no output schema, the description covers dedup, quota, and timing well. Auth requirements and the failure mode when the plan limit is reached are the remaining gaps, but they are minor.

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

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

Schema coverage is 100% and the schema already states the 1–200 item bound, so the baseline is 3. The description adds real value by showing the expected domain format via example values, which the schema does not illustrate.

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

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

States a specific verb and resource ('Add companies to your list') plus the keying mechanism ('by website domain') with a concrete example, which separates it from list_accounts/get_account. It stops short of explicitly contrasting with the sibling request_accounts, so an agent must infer which of the two add paths applies.

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

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

Usage is implied by 'Add companies to your list', and the description usefully notes that duplicates are skipped and plan limits apply. However, it never says when to prefer this over request_accounts or what to do if a domain is rejected, leaving the alternative path unaddressed.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds useful behavioral scope beyond that: a bounded result set (up to 12 findings), that findings carry dates and available links, and that leads include dated proof, which tells the agent what to expect from the call.

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, no waste. The output contents are front-loaded, input formats follow, and the scoping caveat lands last where it is most useful.

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 read tool with full annotation coverage, the description supplies what annotations and schema cannot: the shape and limits of the returned content. No output schema exists, yet return values are adequately characterized, so 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?

Schema coverage is 100% and the single parameter's description ('Domain, company name, or account id') mirrors the description's text almost verbatim. The only added value is the concrete format example 'acme.com', so this sits at 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 a specific verb and resource (read saved context for one company) and enumerates the payload: recent findings with dates/links plus open leads with dated proof. The closing clause 'This does not run a new check' explicitly separates it from check-running siblings such as get_account_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?

Clearly gives the trigger context (account on your tracked list) and the accepted input forms (domain, company name, or id), plus the negative case that it does not perform a fresh check. It stops short of naming an alternative tool to use when a new check is actually wanted.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds real value beyond them: it clarifies data freshness ('saved findings may describe older events discovered recently') and negative-result semantics ('No findings is not proof of no activity'), plus that it reads saved records rather than running new research. Only return/pagination behavior is left unstated, which is acceptable given the safety hints.

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 front-loaded with the triggering user questions, then the mechanics, then caveats, in a logical order with no filler sentences. There is minor redundancy between 'since a chosen date' and 'Defaults to the last seven days', keeping it just short of 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?

With no output schema, the description compensates by describing the returned fields (event date, recorded date, source links), the default window, the domain filter, and the freshness/negative-result caveats. An agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents limit, since, and domains, including defaults. The description restates 'Defaults to the last seven days' and 'Optional domains restrict the list', which duplicates structured data rather than adding new semantics, 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 names a specific verb and resource ('Return newly recorded findings for your tracked accounts since a chosen date') and includes the exact return fields (public event date, recorded date, source links). This distinguishes it from siblings like get_account (single account detail) and get_daily_brief, since it is scoped to change-findings over a window.

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 opens with concrete user-query triggers ('anything happening on my account list?', 'what changed at these companies this week?') and specifies the default window and the domains restriction condition. It stops short of explicitly naming which sibling to use instead, but the context is clear enough to select the tool.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lowered. The description still adds meaningful policy detail: emails are only supplied when available and never for EU/EEA/UK companies, results may degrade to a LinkedIn-only title match, and no messages are ever sent.

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 purpose and return fields are front-loaded, and the compliance caveat is clearly placed. The final sentence ('never writes or sends messages') partly restates the read-only annotation and is slightly redundant, but overall the text is tight and earns most of its space.

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

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

There is no output schema, so the description correctly carries the burden of describing what is returned (name, role, LinkedIn, verified email). Combined with annotations covering the safety profile, an agent has enough to call and interpret this tool; only pagination/empty-result behavior is unaddressed.

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

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

With a single parameter and 100% schema description coverage, the schema already documents the opportunity_id format and its origin tools (list_opportunities, get_daily_brief). The description adds no syntax or format detail beyond implying 'one lead', 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 resource (the person who most likely owns the project behind a lead) and enumerates the returned fields: name, role, LinkedIn, and email. It is clearly distinct from sibling tools, though it does not explicitly name or contrast any alternative.

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 via the domain reference to a lead and the note that results are sometimes only a LinkedIn search, but there is no explicit statement of when to call this versus siblings like get_account or list_opportunities. The implicit context is available but no exclusions or prerequisites are stated.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description adds genuinely useful behavior: fallback to the next note when none has gone out today, empty results on quiet days are normal, and items come dated with links. This is exactly the kind of expectation-setting the structured fields cannot carry.

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 usage trigger, then the return shape, then the edge cases and scope limit. Every sentence carries distinct information (content, fallback behavior, empty-result norm, no live research) with no repetition.

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

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

With no parameters, no output schema, and annotations covering safety, the description fully carries the remainder: what fields come back and how empty/no-note states behave. Nothing an agent needs to call and interpret it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. No parameter claims are made that could mislead.

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

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

States a specific resource (today's note / accounts in it) and its contents: what was found, what it means, who to reach, and time available. The closing scope note ('saved records only, no new research') separates it from research/request tools among the 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?

Gives explicit trigger phrasing ('what should I look at today?', 'who is worth a call?') and a clear exclusion (saved records only, no new research). It does not name a specific sibling alternative for the cases where it is the wrong tool, so routing to list_accounts/prioritize_accounts is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely beyond them: the result is capped at 20 material changes and contains before/after claims with dated sources, and it will not perform new research or send notifications.

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, front-loading what is read before qualifying it with scope limits. No filler; every clause carries information.

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

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

With no output schema, the description usefully previews the return shape (20 items, before/after claims, dated sources) and the no-side-effects boundary. It is only incomplete on the unexplained required parameter.

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 required parameter (opportunity_id) with 0% schema description coverage, and the description never mentions it. The gap is aggravated by a name mismatch: the tool is about 'project updates' but keys on an opportunity_id, and nothing explains that relationship.

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 (Read) and resource (this workspace's watch status plus the latest 20 material changes, with before/after claims and dated sources). The scope is concrete, though it does little to distinguish itself from the near-named sibling get_account_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?

The clause 'Saved evidence only; no new research or notification' tells the agent this reads cached evidence rather than triggering fresh analysis, which is useful implied guidance. However, no alternative tool is named and no explicit when-not condition is given, so the routing must still be inferred.

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 true and destructiveHint false, so the safety profile is covered. The description still adds useful behavioral context: it reads saved records, does not mutate, and discloses returned fields (missing domains, check dates, pagination) – though it does not mention auth or rate-limit 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?

Three tight sentences with the usage trigger front-loaded, then scope, then return shape, then the negative boundary. No filler or restatement of the 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 no-required-param read tool with no output schema, the description supplies the missing return information (missing domains, recorded check dates, pagination) and the mutation boundary. Nothing needed for correct invocation is absent.

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 meaning the schema lacks: the domains parameter is a match/check operation against the tracked list that surfaces unmatched ('missing') domains. That clarifies intent beyond the raw 'company domains to check against your tracked list' text.

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

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

The description names a specific verb+resource ('List accounts in your connected Intakra workspace') and adds a second mode ('match supplied domains against that list'), which no sibling offers. It also distinguishes itself from add_accounts and request_accounts by stating it 'does not add accounts or run a new check'.

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 trigger phrases ('here is my account list', 'which companies am I tracking?') and an explicit negative boundary against the write/refresh siblings. An agent can pick this tool over add_accounts or get_account without further inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description goes further by describing what each returned item contains (findings with dates and links, likely meaning, rough time frame), which is genuinely useful context 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-loads the core action ('List the current leads') and follows with payload detail and the filter hint. Slightly conversational phrasing ('what it usually means for someone selling what you sell') costs a little density but every sentence carries information.

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

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

With no output schema, the description usefully compensates by describing what returned items contain, and it clarifies the filter. It omits any mention of limit behavior, ordering, or pagination, but these are minor gaps for a two-parameter list tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning to the closing_soon enum value by explaining it selects leads that 'usually wind down within 30 days' – a semantic gloss the schema's brief enum description does not provide. The limit parameter is left entirely to the schema.

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

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

States a specific verb (List) and resource (current leads), and defines leads concretely as companies that 'started something you could help with.' However, it never distinguishes itself from siblings like list_suggestions or list_accounts, and the title 'List leads' diverges from the tool name list_opportunities, which could confuse selection.

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?

Offers one concrete conditional: use filter 'closing_soon' for leads that wind down within 30 days. But there is no guidance on when to prefer this over list_accounts, list_suggestions, or get_daily_brief, so the when-to-use decision is only partially supported.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact — suggestions do not count toward the plan until approved — but omits pagination behavior and any note on result ordering or volume.

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 what the tool returns, followed by the billing/approval caveat. No filler, though it is fairly terse for a tool with a state-filtering concept worth expanding.

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 annotations covering the safety profile, a fully documented 2-parameter schema, and no output schema to explain, the description is nearly sufficient. The main gap is the absence of any guidance on the state filter's role or how to route to sibling list 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?

Schema description coverage is 100%, with limit (default 25) and state (enum pending/approved/rejected, default pending) fully documented in the schema. The description adds no syntax or defaulting detail beyond that, so the 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 states a specific verb and resource ('Accounts Intakra suggested for your list') and explains where the suggestions come from (public filings, news, lookalikes). It implicitly separates these from real list accounts via the approval workflow, though it never names a sibling like list_accounts to make the distinction explicit.

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: the tool is for viewing suggested accounts awaiting approval. There is no explicit statement of when to call this versus list_accounts, request_accounts, or add_accounts, so an agent must infer the boundary from the 'suggested' framing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety and scope are partly covered. The description goes beyond them by disclosing that input is not persisted, no private data is accessed, no action is taken, and every fact stays labeled caller-supplied and unverified—genuinely useful behavioral context for a review artifact.

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

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

Three short sentences with the core purpose front-loaded and the constraint list kept compact. No filler or repetition; the caveats are dense but each one carries distinct information.

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

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

An output schema exists, so return values need no explanation, and the labeling/no-side-effect guarantees are well covered. What is missing is enough parameter-level and selection detail for a complex tool with nested objects, five parameters, and only 20% schema coverage—adequate but with clear gaps.

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 20%, so the description carries much of the burden for five parameters including nested vendor, account, signals, and fitCriteria objects. It adds essentially nothing parameter-specific beyond the general 'fit criteria and business signals' phrase—no mention of asOfDate, confidence, observedAt, or the assessment enum—so it does not compensate for the coverage gap.

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

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

The description states a specific verb and resource: 'Turn caller-supplied fit criteria and business signals into reviewable why-now and fit guidance.' That is far more concrete than the title alone. It does not, however, name or contrast with the sibling score_buying_signal_evidence, so an agent must infer the boundary between producing guidance and scoring evidence.

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 through exclusions ('does not research, infer budget or buyer intent as fact, draft outreach, access private data, persist input, or take action'), which tells the agent what situations this tool is not for. There is no explicit when-to-use statement and no routing to the sibling tool for scoring, so the selection guidance remains inferential.

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, non-open-world), yet the description adds real behavioral context: what is returned (dated proof, links, rough time frame, missing accounts, accounts without eligible signals) and an important epistemic caveat that public events suggest investigation but do not confirm need, budget or intent. It stops short of covering pagination or latency 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?

Front-loads the user questions it answers, then explains ranking, output, caveats and scope in tight sequence. The nested parenthetical about the account score is slightly dense but each sentence carries information; no filler.

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

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

With no output schema, the description must carry the return-value burden, and it does: it names the evidence returned (dated proof, links, time frame) and the edge cases (missing accounts, ineligible signals). Scope limits are stated. Only pagination/default behavior is left implicit.

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

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

Schema description coverage is 100%, so both parameters (limit, domains) are already documented. The description only restates that optional domains restrict the list and omits any mention of limit, adding essentially nothing 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: rank tracked accounts by saved open opportunities and an account score. The parenthetical explains the scoring dimensions (fit, timing, reach, 0-100). It does not name a sibling to distinguish itself from, 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?

Opens with concrete trigger phrasings ('who should I target', 'are these companies showing buying signals?') and closes with exclusions ('does not run fresh research or contact anyone'), which implies alternatives like score_buying_signal_evidence. No sibling is named explicitly, so it is clear context without full alternative 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?

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds substantial behavior beyond them: results are free until approved, the call requires user consent, it runs asynchronously in the background, and it is rate-limited to a few per day. It does not state what record is created or any permission requirements, so it stops short of full 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 tight sentences, purpose front-loaded, with the retrieval target (list_suggestions) and the quota/approval caveats packed in without padding. Dense but every clause carries information.

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

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

For an async, multi-param request tool with no output schema, the description covers where results land, that they are free until approved, consent requirements, and rate limits. Remaining gaps (the region parameter's purpose, timing of results) are minor for an agent deciding whether and how to call it.

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

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

Schema coverage is 57%, and the description adds business-level meaning for the main axes (short description, industry, size range, country, lookalike domains from your own customers). It does not clarify 'region' (the one undocumented param) or bounds like employee min/max, so it partially, not fully, compensates for the coverage gap.

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: asking Intakra to find/prospect companies matching a profile. It clearly distinguishes itself from siblings like list_accounts (existing accounts) and add_accounts (manual add) by framing this as a discovery/request operation that produces suggestions.

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

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

Gives concrete operating conditions: 'Ask the user before calling' and 'a few requests a day at most,' and routes the agent to list_suggestions for retrieving results. It lacks an explicit 'use this instead of X when Y' contrast against other discovery siblings, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value: deterministic scoring, review-only output, no source fetching, no workspace access, no input storage, no spend, no sending. It stops short of 5 only because it omits error behavior, determinism caveats, or limits.

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

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

Three tight sentences with zero waste: purpose first, then outputs, then boundaries. The negative capability list is packed into one clause rather than sprawling, and every sentence carries information.

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

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

With four required nested parameters and complex input, the description adequately conveys scope, safety posture, and outputs, and an output schema exists so return values need not be explained. The main shortfall is the absence of any parameter-level guidance or input constraints to pair with the low schema coverage.

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 20%, so the description is expected to compensate for undocumented parameters. It provides no guidance at all on fitCriteria, signals, asOfDate, or account/vendor structure, so the agent must infer the input contract from the schema alone. This leaves a meaningful gap the description does not fill.

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 precise verb ('score') plus the exact resource ('caller-supplied business-account fit and buying-signal evidence') and names the artifacts produced (review-only scorecard, evidence gaps, unsupported-claim flags). It does not explicitly contrast with the sibling prepare_why_now_review, so it falls just short of 5.

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

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

The repeated 'caller-supplied' framing implicitly conveys that this tool is for evaluating evidence the caller already has, and the negative list ('does not fetch sources') clarifies it is not a research tool. However, there is no explicit when-to-use statement, no prerequisites, and no naming of the sibling as an alternative.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the overwrite/non-read behavior is signaled structurally. The description adds real value by naming exactly what is lost ('the current description'), which clarifies the blast radius beyond the annotation flag. It omits auth/permission needs and return behavior, but the annotated bar is lower here.

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

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

Three tight sentences: purpose first, then a concrete example, then the downstream rationale. Every sentence carries information an agent needs, and the most important constraint (it overwrites) is stated up front.

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 write with no output schema and annotations covering safety, the description supplies purpose, format, example, and overwrite semantics. It is only marginally short of complete because it says nothing about the result of the call or confirmation behavior.

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

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

Schema coverage is 100% and the schema already specifies 'What you sell, 10 to 600 characters.' The description supplements this with an illustrative example and a 'sentence or two' length/tone cue that the schema's raw character cap does not 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?

States a concrete verb+resource (set/replace the offering description) and makes the effect unambiguous with 'It replaces the current description.' The example ('Payroll software for restaurant groups with 5 to 50 locations') makes the intended content type unmistakable, and none of the siblings overlap this action, so no differentiation is needed.

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

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

The description explains the downstream purpose ('We use it to decide which findings are worth your time') but gives no explicit when-to-call trigger, prerequisites, or alternative to prefer. Usage is only implied: call it when you want to declare your offering.

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