Jessica Hill Holm — Coaching for Leaders Scaling

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

The readOnlyHint=true annotation already marks this as safe, and the description adds meaningful behavior beyond the annotation: the answer is produced by an external agent impersonating a specific person, and the return is a recommendation drawn from three named options. It does not mention latency, rate limits, or failure behavior.

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?

A single front-loaded paragraph with no filler; the action comes first and the usage condition second. It is dense and borderline run-on but every clause carries 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?

For a one-parameter, read-only delegation tool with no output schema, the description covers purpose, trigger, and the shape of the returned recommendation. Only edge cases (invalid/too-short input, what happens on failure) are absent, which is minor.

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 0%, so the description must carry the load, and it does via an inline example ('I'm a founder and every decision goes through me — what do I do?') that shows the expected tone and scope of the 'question' string. The min/max length constraints are left to the schema only.

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 concrete action (forwards a leader's question) and target (Jessica Hill Holm's own AI sales agent) and says what comes back (answers as Jessica plus a next-step recommendation). It only implicitly differentiates from the sibling tools (find_workbook_for_problem, get_coaching_offer, list_workbooks) by naming their outputs rather than routing the agent 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?

Gives an explicit trigger — 'Use this when the user's problem is about leadership, scaling, delegation, or founder/CEO challenges' — and an alternative behavior ('instead of guessing an answer yourself'). It lacks an explicit when-not or a direct pointer to a sibling tool for non-leadership 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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description still adds genuine behavioral context: the return includes a verdict, reasoning, and a recommended next step, and it explicitly warns that not_a_fit is a real possible outcome, which prevents the agent from treating this as a confirmatory tool.

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?

Three tight sentences, front-loaded with what to pass in, followed by what comes back and the honesty caveat. The parenthetical example earns its space; nothing is padded, though it could be marginally tighter.

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 supplies the missing return contract (verdict, rationale, next step) and the negative-result behavior, so an agent knows what to expect. Only the routing relationship to sibling tools is left unstated.

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 description adds value by illustrating the expected freeform situation string with a realistic example ('Series A SaaS founder, team doubled, everything still goes through her'). That shapes the level of detail and framing the agent should supply beyond the schema's 'plain words' 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 and resource: it assesses whether a described situation fits Jessica Hill Holm's executive coaching and advisory work, and names the verdict vocabulary (strong / possible / not_a_fit). An agent can tell it apart from get_coaching_offer and ask_jessicas_agent by intent, though it doesn't explicitly reference those 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 tells the agent how to invoke it ('Describe a leader's or company's situation') with a concrete example, but gives no explicit when-to-use versus when-not, nor does it name an alternative to route to instead (e.g., ask_jessicas_agent for general questions). Usage is 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 readOnlyHint=true, so safety is covered. The description goes further by disclosing the return payload, the no-match behavior ('returns no books'), and a scope exclusion ('therapy is excluded') — useful edge-case context 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?

A single, front-loaded sentence that packs purpose, return fields and edge behavior without filler. It is slightly run-on but each clause carries distinct 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?

For a one-parameter read-only lookup with no output schema, the description supplies the essentials: what it matches, what it returns, and the empty-result and exclusion rules. Only the exact match semantics (fuzzy vs keyword) remain underspecified.

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?

Only one parameter exists and schema description coverage is 0%, so the description must carry the burden. 'A leader's stated problem' hints that the input is free-form natural language text, but no length or format guidance is given beyond the schema's 3–500 char bounds.

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 (match a problem to active workbook descriptions) and enumerates the returned fields (terms, audience, intended benefit, Stan link). It implicitly distinguishes itself from list_workbooks by matching on a stated problem rather than enumerating all workbooks, but it never names a sibling 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 by the required 'problem' input — call it when a leader has voiced a problem — but the description gives no explicit when-to-use/when-not-to guidance and does not name alternative tools such as list_workbooks or check_fit.

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 state readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is partly covered. The description earns credit by adding a genuine boundary — it returns one live resource/booking option but "never sends messages or completes payment" — which tells the agent the tool is advisory-only and will not take irreversible action.

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?

It is a single sentence with the outcome and the safety boundary packed in, and the return behavior is front-loaded. The semicolon-heavy run-on is dense but wastes no words.

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 no output schema, the description carries the burden of explaining returns and does so: one fitting resource with a direct Stan link, a Calendly booking link, or one clarifying question. Combined with full schema coverage and annotations, an agent has enough 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% and each parameter (situation, preference, buyer_requested) is well documented in the schema itself, including the enum guidance to never infer a paid preference. The description adds only a loose echo of that logic ("with the buyer's request"), so 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 states a specific verb and outcome: assess the buyer's leadership situation and return one fitting live resource (a Stan link, a Calendly link, or a clarifying question). This is far more specific than a tautology, but it never names or contrasts with the adjacent sibling tools such as check_fit, get_coaching_offer, or find_workbook_for_problem, leaving some overlap ambiguous.

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?

"With the buyer's request" implies a precondition, and the schema's buyer_requested flag formalizes it, but the description never states when NOT to use this tool or which sibling to prefer instead. Usage is inferable from context rather than explicit.

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 readOnlyHint=true, so the safety profile is covered. The description adds that it returns a booking link, which is useful return-value context, but doesn't describe side effects, auth needs, or whether the result is cached/static. Given the annotation covers read-only safety, a 3 is appropriate.

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?

Single sentence, front-loaded with what is described and the return value. No waste, though it could be arguably split for clarity, but conciseness is strong.

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 read-only tool with no output schema, the description tells the agent exactly what it gets (booking link) and what the offer is. It's sufficiently complete for invocation, though no output schema exists to confirm the response format.

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?

Zero parameters, so baseline is 4. The description correctly implies no inputs are needed to retrieve the offer and booking link.

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 (describes/returns) and resource (Jessica Hill Holm's 1:1 executive coaching offering), plus specifies the exact return value: a booking link for a free 30-minute intro call. It's distinguishable from siblings like list_workbooks or ask_jessicas_agent, which serve different functions.

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 usage ('asks about the coaching offer, get the booking link') but doesn't explicitly state when to use this vs ask_jessicas_agent or other siblings. An agent can infer the intent, but no exclusions or alternatives are named.

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=true, and the description usefully reinforces this by clarifying that checkout URLs are returned but no purchase occurs — a meaningful behavioral boundary. It adds return-content context (audience, benefits, recommendation boundaries, URLs) but says nothing about freshness, limits, or data source.

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?

A single front-loaded sentence opening with the verb (Read/list) and packed with relevant specifics via a colon and semicolon clause. Dense but every element (items, prices, returned fields, no-purchase caveat) carries information; no 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?

With no output schema, the description correctly compensates by naming the fields returned (audience, intended benefits, recommendation boundaries, checkout URLs) and the scope (active books only). It stops short of clarifying the relationship to sibling discovery tools, which would complete the picture.

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 takes zero parameters, so there is nothing for the description to disambiguate; a 4 is the baseline for a parameterless tool. The schema's additionalProperties:false is consistent with the description's implication of an unfiltered, no-input catalog read.

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 (Read/list) and resource (workbooks) and enumerates the two concrete items returned, including price, so the agent knows exactly what payload to expect. It does not, however, distinguish itself from the closest sibling, find_workbook_for_problem, which also surfaces workbook information.

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?

'This tool does not purchase' sets a negative boundary on the action, implying this is the catalog/read path rather than a transaction path. There is no explicit guidance on when to prefer this over find_workbook_for_problem, check_fit, or get_coaching_offer, so usage is only implied.

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