elc-trade

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

Annotations already declare this a read-only, idempotent, closed-world operation, so the safety burden is lifted. The description adds real value beyond them by stating the output shape (verdict + specific gaps) and the provenance of the five questions (ELC's actual new-city playbook from Brno, Bratislava, Kraków), which tells the agent how authoritative the result is.

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, front-loaded with the question the tool answers, then the mechanism and return shape. The provenance clause about Brno/Bratislava/Kraków is compact and earns its place as a credibility signal for the verdict.

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 needn't be spelled out, and the description complements it with a one-line result summary. The only gap is that the two-mode behavior (questionnaire vs. assessment) is left entirely to the schema rather than surfaced in the description.

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 both the answers object and the heavily-constrained context parameter are fully documented in the schema itself. The description adds no parameter-level detail (e.g., how boolean answers map to the five questions), so 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?

Names a specific question it answers ('should I start an engineering-leadership meetup here?') and a concrete mechanism: a five-question readiness check returning a verdict plus open gaps. The domain (engineering-leadership meetup launch) implicitly separates it from assess_speaker_readiness, though no sibling is named explicitly.

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 decision context is clear — this is for evaluating whether to launch a new city chapter. However, it offers no exclusions or pointers to alternatives (e.g., assess_speaker_readiness for a different readiness question), and the 'call with no answers to get the questionnaire' mode is only discoverable from 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?

Annotations already establish this as a safe, read-only, idempotent, closed-world assessment. The description adds that the verdict is grounded in a specific vetting methodology ('seven years of putting people in front of 120+ engineering leaders'), which is useful context, but says nothing about determinism, scoring transparency, or limits of the judgement.

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 tightly structured sentences, front-loaded with the question the tool answers before describing the process and the output. The methodology clause ('seven years... 120+ engineering leaders') is credibility framing rather than operational information, which costs a point.

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, full parameter documentation, and explicit safety annotations, the description covers what an agent needs to decide to call it. Only a hint about how the verdict is graded or what 'gaps' look like 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 all seven parameters are already documented in the schema. The description adds no meaning about how inputs like prior_talks, has_dry_run, or speaker_background influence the verdict, so it stays at the baseline for a fully documented 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 states a specific verb+resource — assessing a proposed speaker and talk — and frames the outcome as a 'readiness verdict with the specific gaps to close.' It is easy to distinguish from siblings like evaluate_meetup_topic or assess_community_launch_readiness, but it never names those alternatives explicitly.

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 rather than stated: the tool is for judging 'is this person ready to speak' for a proposed speaker/talk before an event. There is no explicit when-not guidance, no prerequisites, and no pointer to a sibling for adjacent questions.

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, closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: ELC community composition is context only, uses a different denominator, and produces no delta or score. That preempts an agent misreading the comparison as a scorecard.

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, front-loaded with the question the tool answers, then the returned values. The em-dash aside about the ELC denominator is dense but earns its place by preventing a misreading. Slightly clause-heavy phrasing keeps it off a 5.

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 no elaboration, and the tool itself takes only two substantive numeric inputs. The description covers purpose, output shape, and the key caveat about the external benchmark. What is missing is input-side guidance (e.g. whether zero managers is valid) and the required/optional discrepancy.

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 and the schema already spells out managers, senior_ics, and the heavily-constrained context field. The description adds nothing about inputs, and notably does not resolve the ambiguity that the schema marks managers/senior_ics as 'Required' in their descriptions while only 'context' appears in the top-level required array.

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 concrete computation (manager-vs-senior-IC percentages, span = 1 manager per N senior ICs) and the question it answers, so an agent can predict its output. It is distinguishable from every sibling, none of which benchmark org composition. It stops short of stating the derivation from the managers/senior_ics inputs in a single crisp verb+resource sentence.

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 framing question ('what shape is my engineering org, and what should I ask about it?') implies the usage context, but there is no explicit when-to-call, when-not-to-call, or named alternative among the siblings. The only boundary drawn is against the external ELC benchmark ('no delta and no score is computed against it'), which is a scope caveat rather than usage 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, so the safety profile is covered, and the description adds genuinely useful behavior: it produces a forwardable approval email and returns ladder positioning rather than performing any purchase. The 'free for engineering leaders' routing rule is real behavioral context beyond structured fields. Minor gaps remain around what the approval email contains or how budget tiers are chosen.

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 core question is front-loaded in the first clause, followed by the output list and then the goal enumeration. It is efficient overall, though the goal list and the individual-buyer sentence repeat material already present in the schema descriptions.

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 7 parameters, a full schema, and an output schema present, the description covers the essential framing an agent needs: what it produces, the goal taxonomy, and the individual-buyer escape hatch. It does not need to explain return values, and nothing critical is missing, though the one_off/buy_reach route could be surfaced more prominently.

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 every parameter is already documented, and the description's goal list and buying_for=individual note largely restate schema text rather than adding new meaning. 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 description opens with the exact question the tool answers and enumerates its four outputs (reach numbers, matching deliverables, budget-ladder position, forwardable approval email), so the resource and result are unambiguous. It does not explicitly differentiate itself from the sibling buy_reach except indirectly through the buying_for=one_off note, so it falls short of 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?

It gives a clear triggering scenario ('justify a community partnership budget internally'), enumerates the valid goals, and states an explicit exclusion: for individuals, membership is free and no business case is needed. The routing to buy_reach for one-off purchases is only conveyed through the schema, not the prose, so it stops short of full when/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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real context by clarifying this produces a 'decision-ready quote a human can sign' rather than executing a purchase (important given the name 'buy_reach'), and that budget_eur does not alter prices. It stops short of stating pricing semantics or whether quotes expire.

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 question being answered, then the mechanics in one sentence. The nine-item enumeration makes it dense, but every clause conveys a distinct capability; a small trim of the item list would improve scannability.

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 needn't be described, and annotations cover the safety profile. The description still completes the picture by covering cart construction, discount application, and quote framing — everything needed to choose and call this 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?

Schema coverage is 100%, so baseline is 3; the description adds value beyond the schema by explaining the speaker-rung ladder ('from a meetup slot to the full coached programme'), the 30-word/link and no-jobs constraint on classifieds, and that combo discount applies automatically. It does not explain interactions between budget_eur and cart selection beyond the schema's own note.

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 (builds a cart, applies the published combo discount) and resource (ELC's nine published one-off reach items, named exhaustively), and the front-loaded question it answers makes the intent unambiguous. No sibling tool does pricing/quoting, and the description makes that distinction evident.

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 framing question ('how do we get in front of 3,500+ CEE engineering leaders, and what does it cost?') implies when to call it, but there is no explicit when-not or routing against siblings like build_partnership_business_case or assess_community_launch_readiness, which an agent could plausibly confuse with a cost/business-case tool.

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 that this is a read-only, idempotent, non-destructive, closed-world lookup. The description adds useful behavior beyond annotations: it names the returned citation fields and states that an unknown id returns the three nearest ids instead of a guess. It does not clarify what happens if neither id nor query is supplied.

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 tight sentences: the first frames the use case, the second states what is returned, and the third explains the unknown-id fallback. It is front-loaded and every sentence adds value.

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, rich annotations, and 100% parameter description coverage, the description is largely complete for invocation. The remaining gap is that it does not specify the relationship between the optional id and query parameters or the behavior when neither is provided.

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 because the schema already documents id, query, and context. The description adds meaning beyond the schema by explaining the unknown-id fallback behavior, though it still does not clarify whether id and query are alternatives or what happens when both are omitted.

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 and resource: it returns an ELC figure from the Data Points registry along with citation id, source, and verification date. It does not explicitly differentiate itself from siblings such as benchmark_leadership_ratio, so it falls short of 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?

The description implies its use case by framing it as answering 'where did that number come from?' and explains the unknown-id fallback. However, it gives no explicit guidance on when to choose this tool over sibling tools or when to use id versus query.

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, closed-world, so the safety profile is covered. The description adds genuine behavior beyond that: the basis of the evaluation (ELC's own topic-selection criteria), and the shape of the output (failure modes, title formulas, open questions for the organiser). It does not mention any limits or that results are opinion-based rather than deterministic, but that is a minor gap against an already-strong annotation set.

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?

One sentence, front-loaded with the user-facing question followed by mechanic and return values, with no wasted framing. The parenthetical about 12 meetups a year and 120+ attendees is slightly promotional but does justify the credibility of the criteria, so it largely 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?

With an output schema present, the description need not enumerate return fields, and it still names the three return categories. The remaining gap is guidance on minimal viable inputs and how this fits alongside the sibling assessment tools, but nothing needed 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 description coverage is 100%, so all four parameters including the mandatory context field are fully documented in the schema. The description adds nothing about parameters such as how a partial abstract or a missing audience affects scoring, so 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?

Specific verb ('Scores') plus specific resource ('a proposed engineering-leadership meetup title and abstract') and an explicit frame ('will this topic fill a room?'). It is clearly distinguishable from siblings like assess_speaker_readiness, which concern the speaker rather than the topic.

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 title states the decision context ('before you commit to it') and the description frames the question the tool answers, so an agent knows this is a pre-commitment vetting step. However, it never names an alternative or states a when-not condition, e.g. how it differs from assess_community_launch_readiness or assess_speaker_readiness.

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, and non-destructive behavior. The description adds useful behavioral context: passing a greeting or liveness test as `context` returns the menu 'instead of a dead end', and the schema confirms that omitting context also yields the menu. No contradiction 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 tight sentences with no filler. The primary purpose is front-loaded, and the secondary greeting/liveness use case is clearly separated in the second sentence.

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, rich annotations, and no output schema, the description plus schema fully cover invocation modes, use cases, and safety. Nothing essential is missing for an agent to decide when and how to call 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%, and the schema already describes the parameter meaning: 'What you are trying to do. Omit it for the menu.' The description reinforces that a greeting can be passed as context, but it adds only marginal 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?

The description uses specific verbs and resources: 'Check for additional specialised capabilities' and 'answers a plain hello'. It clearly identifies this as the meta/discovery entry point, distinct from the domain-specific sibling tools, and the title 'More tools? Check here first' reinforces that identity.

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 conditions for use: 'whenever your task might benefit from them' and for 'a bare greeting or a liveness test'. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that an agent can select it appropriately.

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, closed-world, so the safety profile is covered. The description adds genuine behavior beyond them: the call routes to a fitting tool or returns the full menu, and it discloses the membership framing. Return format is left to the output 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?

Front-loads 'START HERE' and the trigger list, then the routing behavior. Mostly efficient, though the membership sentence is slightly tangential and could be trimmed.

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 no explanation, and the routing behavior is described. For a single optional-param router, the definition covers what an agent needs to select and invoke it, with only the get_more_tools relationship unaddressed.

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% with a single optional parameter, so the schema already documents `context`. The description adds intent framing (pass the caller's message) but no format or syntax detail beyond the schema. 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 role: a start-here entry point for greetings, liveness tests, and overly general questions, plus routing. It clearly signals it is a meta/router tool, distinguishable from the domain siblings. It does not explicitly contrast with get_more_tools, the other meta sibling, so 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?

Gives concrete triggers ('hi', 'hello', connectivity test, 'what can you do', too general to match a tool) and a persona-based condition (caller is a person, not a company). It lacks an explicit when-not or a stated alternative to get_more_tools.

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