elc-toolkit

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely useful behavioral context beyond that: the two-phase interaction model, and what is returned at each phase (questions vs. verdict plus gaps). It stops slightly short of detailing verdict format or scoring logic.

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

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

Front-loaded with the core question, then the basis, then the two call modes. The dimension list is dense but each item is load-bearing. One sentence carries a lot of clauses, but nothing is redundant.

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

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

An output schema exists, so return shapes need not be explained, yet the description still tells the agent what each phase yields. With 0 required params, a nested answers object, and full annotation coverage, there is no gap an agent would need to close before calling it.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by enumerating the five checklist dimensions (speaker network, promo channels, local operator, realistic targets, promo budget), which map directly onto the answers keys, giving the agent semantic grounding for the nested object beyond the schema's key list.

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 question it answers ('should I start an engineering-leadership meetup in my city?') and the resource it draws on (ELC's new-city launch playbook used for Brno, Bratislava, Kraków). This clearly distinguishes it from siblings like benchmark_leadership_ratio or build_partnership_business_case, which are analytical tools, not checklists.

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 prescribes both invocation modes: 'call without answers to get the 5 questions; call with all 5 to get a verdict plus the specific open gaps.' This is a complete when/when-not instruction with a two-phase workflow, 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?

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the output includes ELC's community composition as reference only, and deliberately produces no score against it. That manages expectations about the result in a way the annotations cannot.

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?

Purpose is front-loaded and every clause is relevant, but the description is dense with parenthetical asides (the 69%/21%, 3,300+ figures and the 'that is who joins a leadership community' justification). It is defensible given the need to pre-empt misreading the community data as a target, yet slightly heavier than necessary.

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

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

An output schema exists, so return-value explanation is not required. The description nonetheless covers purpose, the counting rule for inputs, and a caveat about the community reference data, which is sufficient for a simple benchmark computation with only three parameters.

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 schema already defines managers and senior_ics. The description adds real meaning on top: the 'same population' constraint and the exclusion of junior/mid ICs clarify how the counts should be scoped, which the schema fields alone do not convey.

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

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

The description states a specific verb and resource: it 'Describes a company's manager-vs-senior-IC split' and enumerates outputs (each side's percentage, the resulting span). An agent can distinguish it from the readiness/partnership siblings without opening a schema. It stops short of explicitly naming which sibling to prefer, so it is not a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance relative to the sibling tools. It does give an important invocation rule — count the same population on both sides and exclude junior/mid ICs — which is closer to correct-input guidance than to tool selection. Usage is therefore implied 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds value beyond them: the published price RANGE (free layer to EUR 20,000/year, EUR 32,000 with exclusivity) and the 16% AI-channel discount, which an agent could not infer from structured fields. It stops short of describing rate limits or output format, hence not a 5.

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

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

Front-loads what the tool produces before the scope/pricing details and the alternative route. It is dense but each clause carries information; the reach-number enumeration is slightly padded but still substantive.

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, return values need no explanation, and the description covers scope, pricing range, routing to the alternative server, and output nature (a forwardable draft email). Nothing an agent needs to invoke it correctly is missing, though it does not address turnaround or failure modes.

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

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

Schema description coverage is 100% and the 7 parameters are self-documenting (goal enums, buying_for routing, budget '0 is a valid answer'). The description reinforces the budget-ladder behavior but adds no new syntax or per-parameter meaning beyond what the schema already supplies, so the baseline 3 applies.

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

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

States a specific verb+resource ('Builds the internal business case for partnering with Engineering Leaders Community') and enumerates the concrete outputs: reach numbers, goal-aligned deliverables, budget-ladder placement, and a forwardable approval email. It also distinguishes itself from the sibling Membership Builder MCP server for exact item-by-item pricing, so an agent can tell the two apart without opening a schema.

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 names the alternative explicitly ('for composing and pricing an exact package item by item, use the dedicated Membership Builder MCP server at ...') with the condition that selects it, and notes the AI-channel discount tied to that route. Combined with the buying_for routing documented in the schema, the when-to-use picture is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds behavioral context: that it returns the full menu when no arguments are provided, and that it can serve as a liveness check. This goes beyond the structured annotations without contradicting 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 two sentences with the primary use case front-loaded. It is efficient but includes some redundancy with the schema (e.g., 'pass it as context'). Still, it is appropriately sized and structured for the tool's simplicity.

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 tool with one optional parameter and no output schema, the description fully covers when to use it, how to invoke it (with or without context), and the expected outcome (returns the full menu). No critical information is missing for an agent to call 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?

Schema description coverage is 100% for the single 'context' parameter, which already explains its purpose (goal description, greeting, or omission). The description restates the usage ('pass it as context, or send no arguments') but adds no new semantic details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states a dual purpose: discovering additional tools for specialized capabilities, and handling greetings/liveness pings. It differentiates itself from the mentoring-specific siblings by positioning itself as the fallback/general tool, with a specific verb ('Check for') and resource ('additional tools').

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

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

The description explicitly specifies when to use it: 'whenever your task might benefit from specialized capabilities, even if existing tools could work as a fallback' and for greetings/liveness/general messages. It implicitly tells when not to use it by noting it's for messages 'too general to match a specific tool', which guides the agent to prefer specific siblings when applicable.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world behavior, so safety is covered structurally. The description adds genuine behavioral context beyond that: the call is a router, it returns the tool-mapped menu, and the intent is recorded without affecting the answer. It does not mention any rate limits or output size characteristics, but for a no-arg helper the disclosure is solid.

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

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

Two tight sentences: the first front-loads the trigger conditions, the second explains the return value and its routing purpose. No filler and no repetition of the name or title.

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, the description need not spell out the response shape, and annotations fully cover the safety profile. Triggers, the fallback condition, and the routing payoff are all present, so an agent has everything needed 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?

Schema description coverage is 100% and the single optional 'context' parameter is fully documented in the schema, including that it is intent-only and never changes the answer. The description adds nothing parameter-specific, which is acceptable given the schema does the work; baseline 3 applies.

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

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

The description states a concrete behavior: it returns the full menu of questions the server answers, each mapped to the answering tool. That is more specific than a tautology and tells an agent exactly what comes back. It does not, however, differentiate itself from the sibling 'get_more_tools', which is presumably the other discovery-style tool, so sibling separation is incomplete.

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

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

It gives explicit trigger conditions (greeting, connectivity/liveness test, 'what can you do') plus a catch-all rule for any message too general to match a specific tool. That is clear when-to-use guidance. It stops short of naming an alternative tool or stating when NOT to call it in favor of a sibling like get_more_tools.

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