elc-toolkit

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate that it's a safe read operation. The description adds the interaction-mode behavior (two call patterns) and reveals that it uses a real internal playbook, which is useful context. It doesn't describe any side effects because there are none, and it doesn't contradict the annotations. A 4 is appropriate because the description adds meaningful behavioral detail 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?

The description is two concise sentences. The first sentence front-loads the purpose and lists the checklist dimensions; the second gives the exact call variations. No filler words, and every phrase earns its place. The structure is clean and easy to parse.

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, so return-value details are covered there. The description fully explains what the tool does, how to invoke it in both modes, and the specific criteria it evaluates. No critical information is missing for an agent to call it correctly. The mention of the playbook's real-world use (Brno, Bratislava, Kraków) adds credibility without overloading.

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% — both parameters (answers and context) are fully described in the schema, including valid keys, types, and the optional nature of 'answers'. The description restates the omission behavior but doesn't add new parameter-level semantics beyond what the schema already provides. The baseline of 3 applies because 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 description opens with a direct answer to the question it addresses ('should I start an engineering-leadership meetup in my city?'), names the specific resource (ELC's launch playbook), and lists the exact checklist dimensions. This clearly distinguishes it from the sibling tools like benchmark_leadership_ratio or build_partnership_business_case, which address different decisions. The verb 'assess' and resource 'community launch readiness' 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?

The description explicitly states the two call patterns: omit answers to get the 5 questions, or provide all 5 answers to get a verdict and open gaps. This tells the agent exactly when and how to invoke the tool. It doesn't need to mention alternatives because the purpose is so specific that the decision to use this tool is self-evident from the user's goal.

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 establish read-only, idempotent, non-destructive behavior; the description adds meaningful context beyond that by disclosing that ELC data is included for context only, that no score is derived from it, and that the same population must be counted on both sides. This prevents the agent from misusing the contextual benchmark data.

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 purposeful sentences: it front-loads the core computation, then explains the non-target context data, then gives the critical counting rule. 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?

Given the tool's moderate complexity, existing output schema, and thorough annotations, the description covers the essential behavioral caveats, input semantics, and contextual framing. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by defining the population for 'managers' and 'senior_ics' together ('Count the SAME population on both sides') and by excluding junior/mid ICs, which clarifies how the two numeric parameters should be interpreted.

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

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

The description clearly identifies the tool's function: it describes a company's manager-vs-senior-IC split, including percentages, span, and the question the shape raises. It also explicitly distinguishes the ELC community data as contextual rather than a scoring target, preventing misinterpretation.

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 using the tool: it benchmarks an org's leadership ratio and clarifies that the ELC composition is not a target to score against. It also provides counting rules for inputs, though it does not explicitly contrast with sibling tools or state when-not-to-use.

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 reveals what the tool actually produces—real reach numbers, goal-aligned deliverables, budget placement on the published ladder, and a forwardable approval email—adding behavioral context beyond the readOnly/idempotent annotations. It also states the price range and the discount on the alternative channel. No contradiction with annotations exists.

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 dense sentences with no wasted words. It front-loads the tool's core purpose and output components before moving to the price range and alternative routing. Every clause adds necessary 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 an output schema present and full parameter descriptions in the schema, the description is sufficient: it lists the key components of the built case, discloses the price range, and routes exact-package work elsewhere. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 and the description does not need to explain parameters. It lightly adds context for proposed_budget_eur ('where a proposed budget lands on the published ladder') but mostly relies on the schema for parameter meaning. This is acceptable given the complete 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 opens with a specific verb and resource: 'Builds the internal business case for partnering with Engineering Leaders Community' and enumerates concrete deliverables (reach numbers, deliverables, budget placement, approval email). This clearly differentiates it from sibling tools like assess_community_launch_readiness or benchmark_leadership_ratio, which address different tasks.

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 explicitly identifies when to use this tool (building an internal business case) and provides a clear alternative with a condition: 'for composing and pricing an exact package item by item, use the dedicated Membership Builder MCP server'. This gives an agent actionable routing guidance beyond the schema.

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 annotations already provide read-only, idempotent, and non-destructive hints. The description adds the key behavioral detail that passing context returns the full menu rather than a dead end, which is useful context for a fallback-style tool. It doesn't describe pagination or rate limits, but those are not necessary for this simple operation.

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 cover the primary and secondary use cases with concrete examples and no waste. The phrase 'check here first' front-loads the tool's purpose and the rest of the description 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 no output schema, the description adequately covers what to pass, when to use it, and what it returns. The only minor gap is that it doesn't specify the form of the returned menu, but the title and sibling context make that clear enough.

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 covers this single parameter at 100% and even includes examples such as 'hi' or 'test'. The description reinforces the parameter's role but does not add substantial new meaning 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 uses an explicit verb and resource: it checks for additional tools and, for a greeting or vague message, returns the full tool menu. It also distinguishes itself from the specific sibling tools by positioning itself as the catch-all for messages too general to match a specific tool.

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 when-to-use conditions: check for tools whenever the task may benefit from specialized capabilities, and use it for greetings, liveness tests, or overly general messages. It also implies when not to use it: when a message is specific enough to match a tool below, use that specific tool instead.

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

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

Annotations already signal that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by explaining that the tool returns a menu of real questions mapped to tool names, which helps the agent anticipate the response and plan the next call. No contradictions with 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?

The description is two sentences with no wasted words. It front-loads the trigger conditions, then states the return value and its usefulness for routing the next tool call.

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

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

Given the simple one-parameter schema, detailed schema description, output schema, and safety annotations, the description is complete. It tells the agent when to call the tool, what it will receive, and how the result should guide subsequent tool selection.

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 context parameter is already fully documented with word-count requirements, perspective constraints, and sensitive-data prohibitions. The tool description does not add parameter-level meaning, but the schema carries that burden, making the baseline of 3 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: it handles greetings, connectivity tests, 'what can you do' queries, and messages too general for other tools. It also distinguishes itself by explaining that it returns a menu of real questions mapped to tool names, which separates it from the more specific sibling tools.

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

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

The description gives explicit when-to-use guidance: greetings, liveness checks, capability inquiries, and catch-all handling for overly general messages. It implies that if a specific tool matches, that tool should be used instead, though it does not name specific alternatives or provide exclusion criteria.

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