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?

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to repeat safety properties. It adds useful behavioral context by naming the output artifacts, stating that it reports a published price range rather than an exact package, and pointing to the separate exact-pricing tool. It does not cover auth or rate limits, but those are not central 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?

The description is front-loaded with the tool's purpose and main outputs, and the alternative-server guidance comes at the end where it is most useful. It is dense but every clause contributes concrete value, including reach metrics and pricing scope. It could be tightened slightly, but it is appropriately 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?

An output schema exists, so return values need not be fully explained, but the description still gives a strong sense of what the tool produces. It covers the core use case, the price-range limitation, and the alternative for exact package composition. For this tool's complexity and sibling set, it is 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 schema already documents every parameter, including goal, buying_for, and proposed_budget_eur. The description adds only indirect meaning by referring to the stated goal, proposed budget placement, and approval email. With full schema coverage, 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 states a specific verb and resource: it builds an internal business case for partnering with Engineering Leaders Community. It also enumerates the concrete outputs (reach numbers, deliverables, budget-ladder placement, approval email), making its purpose unmistakable. It distinguishes itself from the dedicated Membership Builder server for exact package composition and pricing.

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 an explicit alternative for a closely related task: use the dedicated Membership Builder MCP server for composing and pricing an exact package item by item. It also implies the appropriate use case is producing an internal business case rather than transactional package configuration. This is clear 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?

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: the three mutually exclusive path outcomes, the 'dead zone' rule the tool adjudicates itself (with the explicit instruction to report its verdict rather than infer one), the four 2027 checks, and the per-month proof artifact. It also discloses that the context parameter is recorded as intent and never changes the answer.

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 triggering user questions and then the output promise, which is the right order for an agent deciding whether to call. The embedded list of quoted user phrasings and the four check names make it dense, but each sentence carries routing or invocation information rather than 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?

For a 9-parameter, zero-required, branched tool with an output schema, the description supplies everything an agent needs to call it correctly: trigger conditions, the empty-call warm-up, one-question-at-a-time collection, and the two-call completion pattern. Return-value details can be deferred to the output schema.

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 would be 3, but the description adds real meaning: it explains that people_led and hands_on_hours_per_week jointly drive the dead-zone determination, that the yes/not_sure/no questions map to the four 2027 checks, and that the tool must be called once empty and once full. It does not explain the enum-style string values beyond what the schema already lists.

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

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

States a specific verb and resource: it picks one of three leadership career paths and returns a month-by-month 6-month plan with proof artifacts. It is instantly distinguishable from every sibling (launch readiness, leadership ratio, partnership case), none of which touch career planning.

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 opening lists the exact user questions that should trigger this tool ('what is my next role?', 'should I become a director or go back to IC?'), and it spells out the two-phase invocation: call with no arguments for the 7 questions, ask them one at a time, then call again with all answers. No explicit when-not-to-use or sibling alternatives are given, but the siblings are unrelated, so the gap is minor.

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