mba-mcp

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

No annotations are provided, so the description carries the burden. It explains the purpose and that notes accumulate (implying an append-like behavior), but does not mention persistence, permissions, or side effects. It adds some behavioral context beyond a bare 'add note' but lacks details about mutation or storage.

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 concise, front-loaded with the core purpose, and uses a short illustrative list. Every sentence contributes meaning 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?

For a simple two-parameter tool with an output schema, the description covers the core use case and intent. It could be stronger on explicit exclusions or storage behavior, but overall it is sufficient for an agent to select and invoke the tool correctly in most situations.

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 parameter descriptions in the schema already define 'kind' and 'note'. The description adds examples that map to kind values and clarifies that notes are for future resume bullets, which offers moderate extra context without replacing schema documentation.

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 clear verb ('capture') and resource ('something that happened since the CV was last written'), and distinguishes it from siblings by focusing on accumulation for later CV refresh, not on direct interaction logging or outreach.

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 clearly implies when to use: whenever there is a new achievement or event worth noting for a future CV update. It does not explicitly exclude alternatives like log_interaction or save_resume, but the context makes the intended use 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 present, the description carries the behavioral burden. It usefully discloses two non-obvious behaviors: automatic ATS board resolution and fallback to Adzuna when no URL is provided. It does not mention duplicate handling, required permissions, or side effects beyond the fallback search.

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 no filler: the first states the core operation, the second explains URL resolution, and the third covers the no-URL fallback. The description is front-loaded and every sentence contributes.

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 schema documents all parameters and an output schema exists, so return-value details are not needed. The description covers the main call behavior and the important fallback, but leaves duplicate/update behavior unstated; for a mutation tool without annotations that is a minor gap.

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

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

Since schema coverage is 100%, the baseline is 3, but the description adds real value by explaining ats_url: it is auto-resolved to a supported ATS, and omitting it changes job-search behavior. The priority and name parameters remain documented only by the schema, which is acceptable.

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 object: 'Add a company to the target list', clearly distinguishing this from pack-level operations like add_target_pack. It could more explicitly contrast with sibling tools, but the verb/resource pair 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 no guidance on when to choose this tool over sibling tools or when an alternative is preferred. It explains conditional behavior around ats_url, but that is a runtime fallback, not tool-selection 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 full burden. It discloses the side effect of resolving job boards and the benefit for find_jobs, but does not mention potential failure modes, permission requirements, or reversibility. The disclosed behavior is useful but not exhaustive.

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 compact and front-loaded with the core purpose in the first sentence. The second sentence adds a crucial behavioral detail in a few words. Every sentence earns its place with no 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?

The tool has an output schema (though not detailed here) and all parameters are documented in the schema. The description explains the key side effect and outcome. It is complete enough for an agent to call it correctly, though it could mention processing-time implications or error handling.

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 schema covers all parameters with descriptions (100% coverage), so the description adds minimal extra value. It does clarify the 'resolve' behavior in prose, but priority_max is only described in the schema. Baseline of 3 is appropriate given the high 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 clearly states the tool's action ('Add a whole track's worth of target firms at once') and the resource it operates on (target firms). It is distinct from sibling tools like add_target_company, which adds a single company, making it easy for an agent to differentiate.

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 tool is for batch adding target firms and explains a key behavioral consequence (resolving job boards so find_jobs works immediately). It does not explicitly list when not to use it or alternatives, but the context is clear enough for most 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, the description carries the full burden. It discloses the critical behavioral trait that the server never reads LinkedIn and that the user must perform actions manually, which is beyond the schema. It does not mention error handling or side effects, but the key quirk is 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 two sentences with no fluff. The purpose is front-loaded, and the behavioral note about LinkedIn is placed immediately after, making it highly readable and efficient.

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 an output schema exists, the description need not detail return fields. It explains the two categories of results and the required workflow, making it complete for an agent to invoke correctly. No critical operational details 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 100%, so all four parameters are documented in the input schema. The tool description adds no parameter-specific details beyond what the schema already provides, 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 action ('Find people from the user's school to reach out to, at a target firm') and clearly differentiates from siblings like find_warm_paths by describing its dual output (existing contacts + LinkedIn search links). It also notes a key constraint ('This server never reads LinkedIn'), making its role 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 clearly states the tool's purpose and the workflow (user opens links, connects, re-imports), which implies when it's useful. However, it does not explicitly mention when to choose this over the sibling find_warm_paths, though the difference is inferable from the output description.

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 burden of behavioral disclosure. It only states that the tool finds job postings, but does not mention whether it performs live web scraping, whether authentication is needed, rate limits, or any side effects. This is a significant gap.

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 sentence that is concise and front-loads the core purpose. It is appropriately sized, though it sacrifices useful context for brevity.

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 relatively simple interface, the description is minimal. It lacks usage context, behavioral details, and guidance on how this tool fits among siblings. Even with a rich output schema, the description alone is insufficient for an agent to fully decide when and how to use 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 description coverage is 100%, so the parameters are fully documented in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool finds open roles on target companies' job boards, using a specific verb and resource. It distinguishes itself from sibling tools like find_alumni or find_warm_paths, though it does not explicitly contrast with them.

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

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

No guidance is provided about when to use this tool versus alternatives, such as find_warm_paths or suggest_targets. The context of 'target companies' is implied but no exclusions or prerequisites are mentioned.

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. It discloses the scoring factors and transparency of results, which is useful context beyond the schema. However, it does not mention data sources, recency semantics, or any required setup/preconditions (e.g., must import connections first). Moderate transparency.

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

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

Two compact sentences. The first states the core function, the second elaborates on scoring transparency. Efficient, no fluff, and front-loaded with the main verb. Could arguably be one sentence but this is still clean.

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 there is an output schema, return values don't need description. The tool is a relatively simple ranked read with 2 params, and the description covers its purpose and scoring logic. Lacks preconditions like needing stored contacts (import_connections) but that is arguably implied. Overall 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% and parameter descriptions are succinct ('Maximum contacts to return' and 'Target company name'). The description does not add extra semantics beyond the schema, but none are really needed; baseline 3 is appropriate.

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

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

States a specific verb ('Rank') and resource ('stored contacts') and clearly distinguishes from siblings like find_alumni and find_jobs by focusing on contact warmth into a company. The description also names the output's transparency property, further differentiating it.

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

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

Implies usage when ranking contacts by warmth for a target company, but does not explicitly state when to prefer this over alternatives like find_alumni or suggest_targets. No explicit when-not-to-use guidance, but the context is clear enough.

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 burden. It discloses the ordering (most overdue first) but does not explicitly state that it is a read-only operation or describe any other behavioral traits such as pagination or rate limits. The verb 'get' implies read-only, but this is not stated. The description is adequate for a simple getter but lacks depth.

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, focused sentence that front-loads the primary purpose and ordering. There is no redundant information or unnecessary detail, making it highly concise and well-structured.

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 simplicity (one optional parameter, output schema present), the description is sufficient. It states the core function and ordering, and the schema covers the parameter details. The only minor gap is the lack of usage guidance, but this is not critical for a straightforward getter. Overall, the description is complete enough for an agent to call 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 schema description covers 100% of the parameter (within_days), so the description does not need to repeat it. The tool description does not mention the parameter, but since the schema already documents it fully, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: retrieving contacts that are owed a follow-up, with a specific ordering (most overdue first). It uses a clear verb ('get') and a specific resource ('contacts owed a follow-up'), distinguishing it from sibling tools like log_interaction or send_email which serve different purposes.

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 does not explicitly state when to use this tool or mention alternatives. It implies its usage (when you need to see contacts due for follow-up) but provides no exclusions or comparisons to siblings. Given the simplicity of the tool, the lack of explicit guidance is a minor gap.

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

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

With no annotations provided, the description carries the full behavioral burden and handles it well: it explicitly discloses that the dates are a curated template rather than live deadlines and instructs the agent to warn the user to confirm details. The 'projected onto the current cycle' phrasing also signals time-dependent output. This is genuine behavioral disclosure beyond what the schema provides.

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 core purpose is front-loaded, and the critical caveat follows immediately. Efficiently structured and appropriately sized for a simple tool.

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

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

For a single-parameter tool with an output schema, the description covers the core function and the essential caveat. It does not enumerate possible track values or output format, but the output schema handles the return side. Adequately complete for the tool's simplicity.

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

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

Schema description coverage is 100%, so the single 'track' parameter is already fully described in the schema. The description mentions 'recruiting track' but adds no syntax, format, or valid-value detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The first sentence states the tool returns 'key dates for a recruiting track, projected onto the current cycle' — a clear resource and operation (retrieve timeline dates). None of the 21 siblings overlap this function, so it is readily distinguished. The verb is implicit rather than explicit, but the 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 caveat ('not live firm deadlines — tell the user to confirm against their career centre') tells the agent how the output should be treated, but there is no explicit statement of when to choose this tool over alternatives or any exclusion conditions. No sibling is named as an alternative; usage is implied (for planning a recruiting timeline) rather than stated.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers meaningfully: it discloses that re-running is safe, that contacts are matched on name plus company, and that rows are updated in place rather than duplicated. This is valuable mutation context. It does not cover error conditions or the full side-effect profile, but the idempotency and matching disclosures go well beyond the schema.

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

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

Two sentences with zero waste. The purpose is front-loaded in sentence one, and the behaviorally important idempotency disclosure follows in sentence two. Every clause earns its place.

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

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

For a single-parameter tool with a full schema, an output schema, and 100% parameter coverage, the description is largely complete: it covers purpose, scope, matching logic, and update-in-place behavior. The only gap is error behavior for malformed or missing CSVs, which is a minor omission for this tool class.

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 schema already fully documents csv_path as the path to the LinkedIn data-export CSV. The description adds marginal context by naming the exact file (Connections.csv) and the matching semantics, but does not substantially extend parameter meaning beyond the schema.

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

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

States a specific verb (import) and resource (the user's own LinkedIn connections export / Connections.csv), and scopes it to the user's own data. None of the 22 siblings perform an import, so differentiation is inherent and 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?

Usage context is implied — importing connections is a one-time setup operation that populates contact data used by siblings like find_warm_paths and find_alumni — but the description never states when to use it, when not to, or names an alternative. The idempotency note ('Re-running is safe') hints at repeat use but isn't explicit 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. It does disclose useful behavioral traits: ordering by soonest deadline and aggregating counts per status. However, it does not explicitly confirm read-only behavior, pagination, or what 'pipeline' fully includes, so coverage is partial.

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 one short fragment with no filler; both the ordering and the per-status count fact are useful. It is slightly ungrammatical, but that does not hurt comprehension.

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?

This is a simple list operation with one optional, fully documented parameter and an output schema available. The description adds the key context (sort order and count aggregation), which is enough for an agent to invoke it correctly.

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

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

The only parameter, status, has 100% schema description coverage with the allowed values listed. The description itself adds little about the parameter, but the schema already provides the necessary meaning, so the baseline of 3 applies.

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

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

The description identifies the resource (the pipeline/applications) and adds concrete behavior: soonest deadline first and a count per status. It relies on the title for the explicit verb 'List,' and it does not contrast with any sibling, but the meaning is clear enough.

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

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

There is no guidance on when to use this tool versus siblings like get_followups, track_application, or find_warm_paths. The usage is only implied by the name and the pipeline framing; no exclusions or alternatives are mentioned.

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 full burden. The description is a noun phrase defining target packs, not an action verb describing behavior. It does not explicitly state that this is a read-only operation, nor does it disclose any side effects, pagination, or response characteristics.

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

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

The description is a single, concise sentence without filler. It efficiently conveys the core nature of the tool, though it could be improved by turning it into an imperative phrase. As is, it is appropriately small.

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 zero parameters and the existence of an output schema, the description provides enough content to understand what target packs are. However, it does not explain when to retrieve them versus listing individual targets, nor does it clarify the concept of a 'track.' For an agent choosing among 22 siblings, this is minimally sufficient but lacks routing guidance.

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 the baseline is 4. The description does not need to explain any parameters; the schema confirms an empty input. No additional parameter semantics are needed.

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 the resource (target packs) and adds that they are 'curated starter lists of firms, one per track.' This clarifies what the tool provides, but lacks an explicit verb like 'lists' and does not directly differentiate from sibling tools such as add_target_pack or list_targets.

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

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

Usage is implied by the title and description — it returns curated starter lists of target packs — but there is no explicit guidance on when to choose this tool over alternatives like list_targets or add_target_pack. No exclusions or alternative conditions are given.

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

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

With no annotations, the description carries the disclosure burden. It reveals the ordering behavior, but does not state whether the operation is read-only, whether it requires permissions, or whether results are paginated. The lack of a safety profile annotation is partly offset by the obvious read nature, but more context would help.

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 sentence containing both the action and the key ordering constraint. Every word earns its place, and the most important behavioral detail 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 parameterless list operation with an output schema, the description is nearly complete. It does not explain when to choose this over list_target_packs, but the core function is sufficiently clear for an agent to invoke it correctly without further detail.

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, and the schema coverage is trivially 100%. Per the rubric, a zero-parameter tool gets a baseline of 4; no parameter descriptions are needed or possible.

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 operation: listing target companies, and adds the ordering rule 'highest priority first.' It distinguishes itself from siblings like list_target_packs and add_target_company by specifying the exact resource (target 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?

The intended use is implied: call this when you need to see all target companies. However, it does not explicitly state when not to use it or mention alternative tools like find_warm_paths or list_target_packs, leaving some ambiguity for an agent navigating many siblings.

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 full burden of behavioral disclosure. It states the action ('Log') but does not mention whether this creates or updates a record, any side effects, permission requirements, or what happens if the same contact_id is used multiple times. The description adds minimal behavioral context beyond the tool's name.

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 sentence that efficiently conveys the core purpose and the key additional behavior (scheduling a follow-up). Every word adds value; no filler or redundant phrasing. Front-loaded with the verb 'Log'.

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 schema covers parameter details thoroughly, and the description covers the primary purpose. However, with no annotations and no output schema details, the agent lacks insight into return values, side effects, or usage context. For a simple logging tool this is acceptable but not complete.

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

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

Schema description coverage is 100% and each parameter has a helpful description, including defaults and the source of contact_id. The description adds no additional parameter semantics beyond implying next_followup via 'set when to circle back'. Baseline 3 is appropriate when the schema is already thorough.

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 ('Log') with a clear resource ('a touchpoint with a contact') and states the secondary action ('set when to circle back'). It accurately distinguishes this tool from siblings like send_email or track_application, as it records interactions rather than performing them.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or reference to sibling tools. The context of logging a touchpoint is implicit from the name and schema, but explicit usage guidance is absent.

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 burden, and it delivers the most important behavioral disclosure: this tool never sends anything. It makes the mutation boundary explicit (save-only, no transmission), which is exactly the kind of behavior an agent must not get wrong. Minor gaps remain — it doesn't disclose overwrite/conflict behavior for existing drafts or persistence semantics — but the critical non-sending trait is clearly 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?

Two sentences with zero waste: the first states the core purpose, the second delivers the essential 'nothing is sent' disclaimer plus the hand-off workflow. Front-loaded and 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?

Given that an output schema exists (so return values are covered structurally) and the description covers purpose, non-sending behavior, and the hand-off to send_email, little is missing for an agent to use this correctly. The only absent context is conflict/overwrite semantics, which is a minor gap for a draft-saving 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 schema already documents all four parameters (body, subject, to_email, contact_id). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies — the schema does the heavy lifting and the description does not need to compensate.

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 ('Store') + resource ('outreach email') + scope ('for a contact'), and explicitly disambiguates from the sibling send_email with 'Nothing is sent here.' An agent can instantly tell this tool saves a draft rather than transmits it, which is the critical distinction 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?

Provides explicit workflow guidance: show the draft to the user, revise it with them, and only call send_email with confirm=True upon approval. It names the alternative tool and the exact condition for switching to it, leaving nothing to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden and does so well by explicitly stating that the tool replaces whatever was stored before. It also advises reading the current CV back before editing only part, mitigating the risk of data loss. It does not discuss persistence or authorization, but those are less critical 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 short sentences, each earning its place: purpose, input modality, and overwrite/read-first behavior. There is no filler, and the most important behavioral warning is clearly stated.

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 tool with a fully documented schema and an output schema present, the definition is complete. It covers input form, destructive overwrite behavior, and an editing safeguard; nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and already describes the text parameter as the full CV in plain text or Markdown. The description adds no additional parameter-level format, constraints, or examples, 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 ('Store') and resource ('user's CV') and connects it to the downstream purpose of tailoring against real postings. This makes it clearly distinct from sibling tools like set_profile or add_resume_note.

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?

Explains the expected input mode (pasted chat text, not files/folders) and gives a conditional workflow for partial edits: read the current version back first. It does not explicitly name alternative tools or when-not conditions, 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 burden of behavioral disclosure. It clearly states the confirmation requirement, the one-email-per-call limit, and the fact that only the user's own saved Gmail draft is sent. This is valuable safety-relevant behavior beyond a generic 'send email.'

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 compact and front-loaded with the core purpose. Each sentence delivers distinct guidance: what it sends, the confirmation requirement, and a clear anti-loop instruction. No wasted words.

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 tool is simple, all parameters are fully documented in the schema, and an output schema is present. The description supplies the behavioral guardrails an agent needs—confirmation, single-send, and no looping—so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces confirm=True as an explicit human approval, which adds a nuance, but it does not substantially expand on draft_id or to_email beyond what the 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 verb and resource: 'Send exactly one saved draft from the user's own Gmail account.' It clearly differentiates from sibling tools like save_outreach_draft or suggest_email by emphasizing it sends an existing draft, not creating or suggesting one.

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 strong usage constraints: confirm=True must be an explicit human yes, one call sends one email, and never loop over contacts. It does not explicitly compare to alternatives, but the when-to-use guidance is clear and actionable.

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. 'Save' communicates that this is a persistent write, and 'confirmed' adds an important precondition. However, it does not disclose whether an existing contact email is overwritten, what permissions are needed, or whether any side effects occur.

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, front-loaded sentence with no filler. Every word contributes meaning: the action, the confirmation precondition, and the target resource.

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

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

For a simple two-parameter tool with a fully documented schema and an output schema, the core invocation details are covered. Completeness is reduced by the lack of explicit side-effect disclosure and alternative tool routing, though these are not critical for basic use.

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 both parameters. The description adds minimal semantic value beyond the schema, mainly reinforcing the 'confirmed' constraint already present in the email parameter description.

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 ('Save') with a precise object ('confirmed email address') and target ('on a contact'). This clearly distinguishes it from sibling tools like suggest_email and send_email, which suggest or send rather than persist an address.

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

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

The word 'confirmed' implies the tool should be used only after the user has verified the email address, and 'on a contact' implies an existing contact. However, no alternatives are named and no explicit when-not-to-use guidance is provided, so usage context is only implicit.

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 burden. It discloses the most critical behavior: 'Only the fields you pass are changed.' This clearly indicates a partial-update, non-destructive semantics. It also implies persistence by the verb 'Save'. It does not discuss error conditions or auth, but for a profile setter this is sufficient.

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 tightly written with every sentence earning its place: a direct purpose statement, a timing instruction, a rationale for several fields and a behavioral note. The most important behavioral detail is placed at the end, while the key 'who' and 'when' appear first. No fluff 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?

Given the tool has an output schema, return values are covered. The description provides the essential calling context: when to invoke (start), how to gather data (conversation, not interrogation), and update semantics (partial update). For an all-optional parameter set, this is complete enough for an agent to call correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds beyond the schema by explaining the purpose and acquisition strategy for key parameters: 'School and graduation year make alumni outreach work. Background, goals and constraints are what let you judge fit properly instead of guessing.' This gives the agent context for how to value and fill these fields, which the bare schema descriptions lack.

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 and resource: 'Save who the user is.' It clearly identifies the tool's purpose as storing the user's profile information, which distinguishes it from all sibling tools. The added instruction 'Ask for this once, at the start' provides temporal context that pins down its role in the conversation flow.

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 states when to use the tool ('Ask for this once, at the start') and gives guidance on how to populate fields ('fill them in from what the user tells you in conversation, not by interrogating them'). However, it does not explicitly mention exclusions or alternatives among siblings, though none seem directly competitive. This is clear context without formal when-not guidance.

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

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

With no annotations, the description itself carries the disclosure burden. It does well by stating every result is an unverified guess, advising the agent to show it to the user for sanity-checking, and warning that bounces may occur. This goes beyond a generic 'suggest' label and sets accurate expectations.

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 deliver the core purpose, the inference method, and a practical caveat. There is no filler or redundant restating of the tool name, 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?

For a single-parameter tool with a complete schema and an output schema present, the description supplies all essential context: what it does, how it infers, and how to treat the result. 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?

There is only one parameter, contact_id, and the schema already describes it well by pointing to find_warm_paths or find_alumni. The description does not add much parameter-level detail, but the schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description names a specific action ('work out a likely work email') and a clear resource (a contact), and distinguishes it from siblings like send_email and set_contact_email by emphasizing that this is a guess based on existing addresses. This is not a tautology and an agent can immediately understand what the tool is for.

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 the tool: when a contact's likely work email is needed and existing address conventions can be learned. It doesn't explicitly name alternatives or exclusions, but the contrast with send_email/set_contact_email is implied strongly enough that an agent can avoid misuse.

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 transparency burden. It discloses key behavioral traits: candidates are un-targeted, each includes specific evidence fields, and the tool deliberately does not score fit. It goes beyond a generic 'suggests targets' by explaining its epistemic limits and what data it actually provides.

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 front-loaded with the core purpose and then explains the evidence fields and non-scoring stance. It is somewhat verbose in its rationale but every part adds useful behavioral or selection-relevant context, so it remains efficient.

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 what the tool returns, why it returns it, what evidence is included, and what it deliberately does not do. With an output schema present and only two simple parameters, this is sufficient. It omits details like ordering or authentication, but those are 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%, so the baseline is 3. The description adds some context by clarifying that returned candidates are ones the user has not targeted yet, which relates to include_current, but it does not add significant meaning beyond the schema definitions for limit and include_current.

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 ('Returns candidates the user has not targeted yet') and a resource ('Firms worth considering'), and differentiates itself from siblings like list_targets by emphasizing candidates not yet targeted and evidence like job board readability and existing contacts.

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 use: it is for exploring new firms to target, providing evidence rather than a scored recommendation. It explicitly tells the agent not to rely on the tool for fit judgement. However, it does not name alternative tools or explicitly state when not to use it, leaving some routing to inference.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that this is a tracking action, not a submission action, which prevents a meaningful misuse. However, it does not explain what happens on duplicate entries, whether the action is reversible, or any persistence/confirmation behavior, so transparency is adequate but not rich.

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, purposeful sentences. The core action is front-loaded, the key non-behavior is stated immediately after, and the jd_text guidance is concise but meaningfully explained. 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?

Given the output schema exists and the input schema covers all parameters, the description covers the important contextual gaps: what the tool does, what it does not do, and when to include jd_text. It could add a note about duplicate handling or status defaults, but the schema already documents the status default, so the remaining context 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 description coverage is 100%, so the baseline is met. The description adds extra semantic value to jd_text by explaining why storing it matters ('tailor their CV against the real requirements later'), which goes beyond the schema's simple 'pasted in full' description. Other parameters are already well documented in the schema.

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

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

The description uses a specific action verb and resource ('Add a role to the application pipeline') and explicitly states it 'never submits one,' clearly distinguishing this from submitting or updating applications. This makes the tool's purpose and boundary immediately obvious.

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 to use it: when adding a role to the pipeline. It also gives explicit contextual guidance for jd_text ('Pass jd_text when the user has the posting to hand'), which helps the agent decide on parameter usage. It does not explicitly name sibling alternatives such as update_application, but the addition-versus-update distinction is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that status/deadline/notes can change, but does not explain side effects such as whether omitted fields are left unchanged, whether notes or deadline can be cleared, or what the response will contain. This is a meaningful gap for a mutation 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 a single concise sentence that front-loads the primary action (moving an application along the pipeline) and then mentions the optional revision targets. There is no filler or redundant wording.

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 provides the essential purpose and is supported by full parameter coverage and an output schema, but it omits usage guidance and behavioral details. For an update operation on an application, an agent would benefit from knowing whether fields are replaced wholesale and what happens when null is passed.

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

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

Schema description coverage is 100%, and each parameter has an explanatory description, including status values and the ISO date format for deadline. The tool description adds no parameter-level meaning beyond that, but because the schema already does the heavy lifting, a baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: moves an application along a pipeline or revises its deadline/notes. It goes beyond the tool name by naming specific updatable aspects, though it does not explicitly distinguish itself from closely related sibling tools like track_application.

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 the tool is useful: to change an application's status, deadline, or notes. However, it does not explicitly contrast this with alternatives or state when not to use it, which is a gap given sibling tools like track_application and list_applications exist.

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 burden of behavioral transparency. It clearly states the tool returns factual numbers, not coaching, and advises the agent to lead with the most important items — a behavioral trait of how to present output. It does not explicitly state read-only behavior, but the context strongly implies it.

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

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

Four concise sentences: the opening states the core functionality, the second details what's included, the third clarifies the split between factual data and coaching, and the fourth gives presentation guidance. Each sentence earns its place 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?

With an output schema present and full parameter coverage, the description focuses on the tool's role and output usage. It tells the agent what to expect and how to prioritize, which is sufficient for correct invocation. The only missing element is an explicit statement that no data is modified, which is not critical for this aggregation tool.

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

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

The input schema documents both parameters (lookahead_days, stale_after_days) with descriptions and defaults, giving 100% schema coverage. The description adds no extra semantic meaning about these parameters. Per the baseline rule, a score of 3 is appropriate when the schema fully covers parameter semantics.

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

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

The description opens with a clear purpose: 'Everything that needs attention this week, in one call.' It enumerates the types of content (overdue items, closing deadlines, quiet contacts, untouched target firms, and the user's cycle position), making it easy to distinguish from more specific sibling tools. It lacks an explicit verb like 'retrieve' or 'generate,' but the intent 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 phrase 'This is the habit' suggests a recurring weekly context, implying when this tool should be used. However, there are no explicit alternatives, exclusions, or conditions that would route an agent to a different tool. Usage guidance is present but only implicit.

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