elc-partnership-builder

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds useful behavioral context: it returns a direct booking link and does not collect contact details, since the booking page handles that. This goes beyond the structured 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?

The description is concise (three sentences) and front-loaded with purpose and context. Every sentence adds value: what it is, when to use, and what it does not do.

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

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

For a zero-parameter tool with rich annotations, the description provides sufficient context: purpose, usage triggers, alternative ending, and behavioral details (booking link, no contact collection). No gaps remain.

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 an empty schema, so there is nothing to clarify. Per the rubric, a baseline of 4 applies for a no-parameter tool, 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?

The description clearly states the tool books a 1:1 intro meeting with Marian Kamenistak, and explicitly positions it as an alternative ending to request_offer. It uses a specific verb+resource (book intro meeting) and differentiates from siblings.

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

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

It gives explicit when-to-use guidance: 'Offer it whenever the visitor hesitates, wants a human, or the package needs tailoring beyond the catalog.' It also names the primary alternative request_offer, providing clear context for selection.

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

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

The description discloses important behavioral traits: the returned total is authoritative, the return includes selected items with prices and tier additions, and foundation items anchor the package. This goes beyond the readOnly/idempotent annotations and does not contradict them.

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 and well-structured, with three sentences front-loaded with the tool's purpose and immediate instruction. Every sentence adds value, covering input, output, and usage.

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

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

For a two-parameter tool with no output schema, the description adequately explains the return values (total, items, prices, additions) and provides usage flow ('Call again', 'Next: request_offer'). It equips the agent with all essential context for correct invocation and interpretation.

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 describes both parameters, including that item_ids are 'currently toggled ON'. The description adds little new parameter meaning beyond restating this, 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's purpose: customize a package by toggling line items, passing the preset and item_ids, and returning the recomputed total. It uses specific verbs and resources, and distinguishes its role by noting 'Next: request_offer' and referencing the authoritative price.

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 clear usage instructions: 'Call again after every change the visitor asks for' and advises keeping foundation items. It implicitly distinguishes from siblings by referencing match_package in the schema, but it does not explicitly state when not to use this tool or provide alternative tool comparisons.

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

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

Annotations already declare the tool read-only, idempotent, non-destructive, and closed-world. The description adds meaningful behavioral detail: it is deterministic, computed from scheduling metadata (lead times, anchors, collision rules), and returns unplaceable items with reasons. This goes well beyond the annotations and helps the agent anticipate outputs and constraints.

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, front-loaded with the core idea, and every clause earns its place. It packs a lot of information (determinism, computation source, return content, constraints, workflow position) without redundancy or fluff. The structure is logical: what, how, output, caveats, when to use.

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

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

Despite no output schema, the description specifies return contents (placed months, recurring layer, unplaceable with reasons) and constraints. It explains the trigger ('after customize_package') and the requirement to only use basket items. This is sufficient for an agent to select and invoke the tool correctly in a complex workflow.

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 already describes preset_id (enum), item_ids ('basket: item ids toggled ON'), and start_month (format and default). The description adds context about how the parameters interact (via scheduling metadata) but does not provide new per-parameter semantics. With 67% schema coverage, a baseline score of 3 is appropriate; the description supplements but does not carry the load.

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: generating a deterministic 12-month plan computed from the basket's scheduling metadata. It distinguishes itself from siblings by specifying it operates only on items already in the basket and by its position in the workflow ('Call after customize_package, before request_offer'). The verb 'plan' and the resource 'basket' are specific 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?

Explicitly gives position in the overall process: 'Call after customize_package, before request_offer.' It also states what the tool should not do ('never add or move an event') and that the plan contains only basket items, guiding the agent on when not to use it (e.g., when modifications are needed). This is clear contextual guidance beyond a simple placeholder.

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, lowering the burden. The description adds useful context about the target audience, the /mentor/ routing for individuals, and the follow-up call to match_package. It does not delve into internal mechanics or return format, but given the annotations, it is sufficiently transparent.

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

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

The description is four concise sentences, front-loaded with 'START HERE' and then efficiently covering what is returned, the exclusion for individuals, and the next step. Every sentence provides necessary information without redundancy.

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

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

Given the zero-parameter schema, strong annotations, and clear description of return content and audience, the description is complete for its purpose. It doesn't need to explain output schema (none exists) and covers the key behavioral aspects an agent needs to invoke and follow up correctly.

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

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

The tool has zero parameters, so baseline is 4. The description adds no parameter information (correctly, since there are none). The schema is empty and fully documented, so no issues.

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') and identifies the resource (ELC partnership/membership information, community reach figures, and qualifying questions). It distinguishes this tool as the entry point ('START HERE') and explicitly references a sibling tool (match_package) for the next step, making its role in the flow clear.

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

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

Explicitly states when to use (`START HERE for any company`), who it applies to (companies, personas HR/CTO/employer branding), and who it does not apply to (individuals seeking a mentor, pointed to /mentor/). It also provides a clear transition to a sibling tool (`After the visitor answers both questions, call match_package`).

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

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

Annotations declare read-only, idempotent, and non-destructive. The description adds valuable behavioral details beyond annotations: uses the website's routing matrix, returns real prices and default line items, handles free-text mapping, and on bad input lists valid IDs and advises re-asking instead of guessing. No contradictions.

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

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

The description is three sentences, front-loaded with the core purpose, followed by input handling guidance and next-step suggestions. Every sentence earns its place, with no redundancy or filler.

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

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

Despite lacking an output schema, the description covers purpose, parameter semantics, error handling, and successor tools. It also references the routing matrix and default line items, giving a complete picture of what the tool returns. The sibling context is appropriate and enhances completeness.

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 already documents both parameters with references to get_partnership_options IDs. The description adds that free-text answers should be mapped to the closest valid ID and that invalid input triggers an error listing valid IDs. This provides behavioral context beyond the schema, such as expectation of free-text mapping rather than direct ID passing.

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 function: 'Resolves goal + budget through ELC's own routing matrix' and returns matched packages with real prices and default line items. It distinguishes itself from sibling tools by explicitly naming customize_package and request_offer as next steps, positioning match_package as the initial matching step.

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 practical guidance: map free-text answers to valid IDs, re-ask on bad input, and next-step actions via customize_package or request_offer. It does not explicitly state when NOT to use this tool versus alternatives, but the workflow context is clear. The mention of get_partnership_options for valid IDs implies a prerequisite.

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?

The description richly discloses behavior beyond the annotations: it lists side effects (notifies Marian, files into partners queue), specifies when to collect data, and clarifies that the optional ask is truly optional. This provides the agent with concrete behavioral guardrails that annotations alone do not convey.

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

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

The description is concise and front-loaded, opening with a strong differentiator ('The ONLY tool') then immediately stating the actions. Every sentence serves a purpose—clarifying what happens, when to act, and how to handle follow-up—with no redundancy or fluff.

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

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

The description covers the essential workflow: sending, notifying, filing, and post-success behavior. However, since there is no output schema, it does not explicitly describe the return/confirmation message or response format. This is a minor gap but the description is otherwise complete enough for an agent to proceed 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?

With 83% schema description coverage, the input schema already documents most parameters well. The description adds value by naming the contact details (name, email, company) but does not elaborate on preset_id, item_ids, or kpis beyond what the schema provides. This meets the baseline for adequate 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 clearly states the tool's function with specific verbs: 'Sends the itemized offer to the visitor's email, notifies Marian (email + Slack), and files the company into ELC's partners queue.' It also distinguishes itself from siblings by claiming to be 'The ONLY tool that collects contact details,' making its purpose 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 explicit timing guidance: 'Ask for name, work email and company only when the visitor says they want the offer — never earlier.' It also details post-success steps. However, it does not directly name alternative tools for other actions, so it falls short of the 'explicit alternatives' benchmark, earning a 4 rather than a 5.

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