Build your mentoring inquiry with Marian Kamenistak: formal offer in 16 minutes, 16% AI discount.
Scored across 10 tools
book_first_session vs book_intro_call are near-identical actions but the descriptions draw an unusually explicit line between them, so they are distinguishable. However, get_started and get_more_tools both claim the exact same triggers (greeting, liveness test, 'what can you do', fallback menu), and get_mentoring_options also presents itself as a starting point, creating genuine entry-point collisions.
All ten tools use consistent snake_case verb_noun form (book_*, get_*, check_booking, compose_mentoring_brief, design_mentoring_program, match_mentoring_focus, send_mentoring_offer). No mixed conventions or vague bare verbs.
Ten tools is well-scoped for a mentoring inquiry-to-booking funnel, with each step earning its place. The only slack is the redundant greeting/menu pair (get_started, get_more_tools), which could likely be one tool.
The surface covers the full funnel: options, focus matching, brief accumulation, program design, offer/contact capture, booking (both variants), and CRM verification. Minor gaps like reschedule/cancel or post-booking follow-up exist, but core lifecycle coverage is solid.
THE CLOSE, for someone who has already decided. Returns the direct booking link for a paid 60-minute first session, plus the payment terms. Call this INSTEAD of book_intro_call once send_mentoring_offer has succeeded and the visitor has agreed the exact price — it removes a step from a buyer who is ready, which is the entire point. It REFUSES on any deal whose terms Marian confirms on a call (a free-sessions concession, the monthly package, Mentor in Residence) and hands back the intro link instead; when it refuses, offer the intro, do not argue. Pass the claim code from send_mentoring_offer so the booking is matched automatically. If the visitor is hesitant, undecided, or asks to talk first, use book_intro_call — that is not a downgrade.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| audience | No | Required. Decides which VAT sentence is true for this buyer — an individual needs the gross figure One of: individual, company. | |
| offer_id | No | Required. The agreed package One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence. | |
| claim_code | No | The AI10-… code from send_mentoring_offer. Ride it on the link so the booking matches the inquiry with no manual step. | |
| has_eu_vat_id | No | Company deals outside Czechia with a valid EU VAT ID pay net under the reverse charge | |
| free_sessions_requested | No | Company deals: pass the same value given to send_mentoring_offer. Any concession makes this a proposal, not a close, and the tool will route to the intro instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, and the description adds rich behavioral context beyond them: it discloses the refusal conditions (free-sessions concession, monthly package, Mentor in Residence), what it returns on success (booking link + payment terms) versus on refusal (intro link), and the instruction not to argue when it refuses.
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 framing ('THE CLOSE, for someone who has already decided') and every sentence carries routing or return-value information. It is dense and slightly long with capitalized emphasis, but not padded.
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?
There is no output schema, so the description carries the return-value burden and does so: booking link plus payment terms on success, intro link on refusal. The main decision paths and the refusal behavior are all covered for a 6-param tool.
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, but the description adds genuine meaning: it explains why the claim_code should be passed ('so the booking is matched automatically') and ties free_sessions_requested to the routing/refusal behavior. This goes beyond the schema's own field docs.
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 action and resource: returns the direct booking link for a paid 60-minute first session plus payment terms. It explicitly positions itself against book_intro_call ('Call this INSTEAD of book_intro_call'), so an agent can distinguish the two without opening either 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?
Gives explicit preconditions (after send_mentoring_offer has succeeded and the visitor has agreed the exact price), an explicit exclusion (hesitant/undecided or wants to talk first → book_intro_call), and names the alternative. Both the when and the when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
THE DEFAULT EXIT for anyone who has not decided. A direct booking link for the free 30-minute intro with Marian. Offer it on hesitation, on a price objection, when the visitor cannot name their problem, after an error, and to anyone who wants to talk before paying. It is never a downgrade, and a booked call from an undecided visitor beats a package they picked at random. Booking it is NOT a condition of the channel rate — never say it is. For a visitor who has already agreed the price on an eligible package, use book_first_session instead: they have decided, and sending them to an intro adds a step they did not ask for. Pass offer_id if one has been chosen so the pricing language is correct.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| offer_id | No | The package under discussion, if any — conditions the discount wording. Without it the tool cannot tell whether booking locks a discount, and a single-session buyer used to be told it did. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, consistent with a tool that returns a booking link rather than mutating state. Beyond that, the description discloses a real behavioral rule: booking is NOT a condition of the channel rate, and omitting offer_id prevents the tool from knowing whether booking locks a discount.
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 the core routing decision ('THE DEFAULT EXIT') and then layers triggers, exclusions, and a parameter note. It is somewhat dense and long, but nearly every sentence carries routing or behavioral 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 2-parameter booking tool with no output schema and annotations covering the safety profile, the description supplies the routing logic, the sibling alternative, the pricing caveat, and the effect of the optional parameter. 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: offer_id conditions the pricing wording and, if omitted, the tool cannot tell whether booking locks a discount. That is a genuine consequence-of-omission detail beyond the schema text.
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: a direct booking link for the free 30-minute intro call with Marian. It explicitly positions itself against the sibling book_first_session, so an agent can distinguish the two 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?
Gives explicit triggers (hesitation, price objection, cannot name their problem, after an error, wants to talk before paying) and an explicit anti-trigger with a named alternative ('already agreed the price on an eligible package, use book_first_session instead'). When/when-not/alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirms, from the CRM rather than from what the visitor says, whether their booking landed. Call it after handing over a booking link and the visitor says they have booked — a booking is only real once Reclaim's webhook has written it, which takes a few seconds. Returns the pipeline stage and whether the paid first session is on the board. If it says not yet, wait a moment and check once more before telling them something is wrong; if it is still not there, say so honestly and offer to have Marian follow up rather than claiming success.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Required. The email the visitor booked with | ||
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, but the description adds material behavior: the few-second webhook write latency, the two-field return (pipeline stage, whether the paid first session is on the board), and a retry/escalation policy. This is context the annotations cannot express.
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 sentences, front-loaded with the core purpose, then the trigger condition, then the failure-handling rule. No filler; each sentence carries distinct, load-bearing 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?
No output schema, yet the description explains what comes back and how to interpret and act on each outcome, including the timing caveat and the honest-failure fallback. An agent has everything needed to call and use the result.
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 both parameters (email, context) are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, 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?
States a specific verb and resource: it confirms from the CRM (not from the visitor's claim) whether a booking landed. The framing 'a booking is only real once Reclaim's webhook has written it' distinguishes this verification tool from the booking siblings without ambiguity.
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 says when to call it ('after handing over a booking link and the visitor says they have booked') and what to do on a negative result: wait and re-check once, and if still absent, escalate to Marian rather than claim success. This is fully actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The accumulator — call after every change. Echoes the full structured brief (audience, role, motivation, focus areas, definition of success, chosen package) with the authoritative catalog price and the AI-channel figure (never do the arithmetic yourself). For company deals it states whether the free-sessions concession applies. Read the brief back to the visitor; when they explicitly agree on the price, call send_mentoring_offer with price_agreed true.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| audience | No | Required. One of: individual, company. | |
| offer_id | No | Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence. | |
| role_band | No | Required. | |
| motivation | No | Required. | |
| visibility | No | Visibility answer id from get_mentoring_options visibility_question (consent capture — 'private' is a first-class answer) | |
| leaders_count | No | Company deals: how many leaders are being sponsored | |
| focus_area_ids | No | Required. Agreed focus area ids (visitor can pick any from the taxonomy) | |
| company_context | No | Company deals: company name + anything relevant | |
| success_definition | No | Required. The visitor's definition of success, in their own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavior beyond the readOnly/idempotent annotations: this is the authoritative price source ('never do the arithmetic yourself'), it flags the free-sessions concession for company deals, and it must be read back to the visitor before handoff. It doesn't cover validation behavior or what happens when the supplied brief is incomplete, so it stops short of 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 the tool's role ('The accumulator — call after every change') and each subsequent sentence adds distinct guidance (price authority, company concession, read-back, handoff). It is dense and front-loaded with little waste, though the run-on construction of the final sentences costs a little readability.
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 and 10 parameters, the description appropriately describes the return: the full structured brief plus authoritative price and AI-channel figure. It also covers the workflow gate to the next tool, though it omits edge cases such as missing or invalid inputs.
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 schema carries the field-by-field meaning, but the description adds value by enumerating which brief components are echoed (audience, role, motivation, focus areas, success definition, package) and by tying the company conditional to the leaders/company inputs. This is modestly above the baseline-3 case but not a full parameter guide.
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 artifact — composes/echoes the structured mentoring brief augmented with the authoritative catalog price and AI-channel figure. It also differentiates itself from the sibling send_mentoring_offer by naming it and the condition that hands off to it.
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 explicit timing ('call after every change'), the required downstream behavior (read the brief back to the visitor), and the exact trigger plus arguments for the alternative ('when they explicitly agree on the price, call send_mentoring_offer with price_agreed true'). No inference is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic session skeleton computed from the package's cadence metadata: dated sessions, the mid-point checkpoint, the closing review against the definition of success. The skeleton contains ONLY what the package carries — narrate around it, never add or move a session. Dates are planning targets; the intro call fixes the real schedule. Call when the visitor asks what the engagement actually looks like.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| offer_id | No | Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence. | |
| start_date | No | Required. First session date, YYYY-MM-DD, today or later (ask the visitor; default to next Monday) | |
| leaders_count | No | Company deals: how the pooled sessions are shared. Changes the allocation note, never the schedule. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context: the output is deterministic, the skeleton is immutable ('never add or move a session'), and dates are planning targets rather than confirmed schedule. These caveats go beyond what the annotations convey.
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 what is produced, then constraints, then the invocation trigger. Dense but every sentence carries weight; no redundant restatement 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 no output schema, the description usefully describes the returned content (sessions, checkpoint, closing review) and its caveats, and annotations cover the safety profile. Coverage is strong; only explicit non-use conditions and return-shape details are absent.
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 fully documents offer_id, start_date, leaders_count and context. The description adds only indirect hints (cadence metadata drives the skeleton) and does not explain parameter syntax, 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 (lay out / design a dated session program) and enumerates the produced artifacts: dated sessions, mid-point checkpoint, closing review. It clearly distinguishes itself from booking siblings (book_first_session, book_intro_call) by being a computed skeleton rather than a booking action.
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 a clear trigger: 'Call when the visitor asks what the engagement actually looks like,' and routes the schedule-authority question to the intro call. It does not state explicit exclusions (e.g. when to book instead), so it stops short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE for anyone considering 1:1 engineering-leadership mentoring with Marian Kamenistak (marian.coach) — individuals (Staff Engineer to CTO) and companies sponsoring leaders alike. Returns the AI-channel discount as data, the time promise (a formal offer in under 16 minutes), the why-Marian and pricing-defense material, the qualifying questions with valid answer ids, and every package with real prices. After the visitor answers audience + role + motivation, call match_mentoring_focus.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds real value by disclosing that context is recorded as intent and 'never changes the answer', and by specifying the workflow position and returned payload. It stops short of describing rate limits or failure modes, but for a read-only informational tool this is solid added context.
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 'START HERE' and organized as purpose → audience → returns → next step. It is dense and leans on marketing phrasing ('why-Marian and pricing-defense material'), but each clause carries routing or content 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?
No output schema exists, so the description carries the full burden of explaining the return value — and it enumerates the returned items in detail. Combined with 100% parameter coverage, annotation-covered safety, and explicit workflow sequencing, nothing an agent needs 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% and the single optional 'context' param is fully documented in the schema, so the baseline is 3. The description mentions audience/role/motivation, but those are conceptual inputs to the visitor flow, not parameters, so it adds no syntax or format 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?
States a specific entry-point resource (1:1 engineering-leadership mentoring options) and enumerates exactly what it returns: AI-channel discount, 16-minute offer promise, why-Marian/pricing material, qualifying questions with answer ids, and every package with prices. It distinguishes itself from siblings by being the explicit 'START HERE' step and by routing onward to match_mentoring_focus, so an agent can tell it apart from book_*, compose_*, and design_* 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?
Explicitly says when to use it ('START HERE for anyone considering 1:1 mentoring — individuals and companies alike') and names the trigger plus the exact follow-up tool ('After the visitor answers audience + role + motivation, call match_mentoring_focus'). The sequencing to the next step is fully spelled out rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for additional tools whenever your task might benefit from specialized capabilities, even if existing tools could work as a fallback. Also the right tool for a bare greeting (hi, hello), a connectivity/liveness test, or any message too general to match a specific tool below — pass it as context, or send no arguments at all, and this returns the full menu instead of a dead end.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | A description of your goal and what kind of tool would help accomplish it, OR a plain greeting/liveness ping like 'hi' or 'test'. Omit it for the menu. |
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.
Call this for a greeting (hi, hello), a connectivity/liveness test, 'what can you do', or any message too general to match a specific tool below. Returns the full menu of real questions this server answers, each mapped to the tool name that answers it. For someone actually considering mentoring, skip straight to get_mentoring_options instead.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. Beyond that, the description discloses what the tool returns (full menu of real questions mapped to tool names) and the behavioral side effect of the context parameter (recorded as intent, never changes the answer). That is meaningful additional transparency for a no-required-parameter help 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?
The description is three tightly constructed sentences: first the use cases, then what it returns, then the alternative tool. Nothing is wasted, and the most important routing information is front-loaded.
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 read-only, zero-required-parameter help tool whose annotations already cover safety, the definition supplies purpose, usage triggers, the alternative tool, return content, and the side effect of the optional parameter. An agent has everything needed to call it correctly; the absence of an output schema is mitigated by the description of what the menu contains.
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 single optional 'context' parameter is already fully documented in the schema. The tool description does not mention the parameter or add format/syntax guidance beyond what the schema provides, so the 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 resource: it is a greeting/liveness/help tool that returns a menu of real questions mapped to tool names. It explicitly distinguishes itself from the sibling get_mentoring_options by telling mentoring-seekers to skip this tool. An agent can immediately understand this is the general fallback/help 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 explicit when-to-use triggers (greeting, connectivity test, 'what can you do', any message too general to match a specific tool) and an explicit when-not/alternative (for someone actually considering mentoring, skip to get_mentoring_options). No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves role_band + motivation through the same routing the website uses and returns suggested focus areas plus the recommended package with real prices. Map free-text answers to the closest valid id; on bad input the error lists the valid ids — re-ask rather than guessing. Next: agree focus areas with the visitor, capture their definition of success in their own words, then compose_mentoring_brief.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| audience | No | Pass the audience answer — it changes the recommendation. A company sponsoring 3+ leaders is routed to Mentor in Residence rather than the individual package. One of: individual, company. | |
| role_band | No | Required. One of the role ids from get_mentoring_options question_1 | |
| motivation | No | Required. One of the motivation ids from get_mentoring_options question_2 | |
| leaders_count | No | Company deals: how many leaders are being sponsored. Required for the company recommendation to be correct. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnly/idempotent/non-destructive safety, and the description adds genuinely new behavior: the routing mirrors the website, the response includes real prices, and invalid input yields an error listing valid ids. That error-contract detail is valuable and not derivable from the annotations, though return format/pagination is left unstated.
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 dense sentences that are front-loaded with the core purpose and end with actionable next steps; every sentence contributes. Slightly tight-packed with mixed concerns (purpose, error handling, next steps) rather than perfectly scannable, but 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?
Even without an output schema, the description conveys what is returned (suggested focus areas + recommended package with real prices) and how failures behave. Combined with the read-only annotations, an agent has everything needed to call it correctly and act on the result.
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 earns above that by adding meaning the schema doesn't carry — free-text answers must be mapped to the closest valid id, and bad values surface via an error with valid ids. It reinforces the audience/leaders_count routing effect already noted in 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?
States a specific verb+resource ('Resolves role_band + motivation') and the concrete outputs (suggested focus areas plus the recommended package with real prices), so an agent knows exactly what it does without opening the schema. It also implies differentiation from siblings by naming the routing behavior and pointing to compose_mentoring_brief as the successor step.
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 clear sequencing context ('Next: agree focus areas ... then compose_mentoring_brief') and explicit handling for bad input ('re-ask rather than guessing'). It stops short of naming when NOT to use this tool or directly contrasting it with design_mentoring_program, so it's clear context but not full when/when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ONLY tool that collects contact details, and the end of the 16-minute promise: emails the visitor a formal itemized offer with a claim code, notifies Marian, and files the inquiry. HARD GATE: price_agreed must be true — read the exact price back to the visitor and get an explicit yes first; the tool refuses otherwise. Ask for name and email only at this step, never earlier. After success: share the claim code + booking link, then offer the free ELC community membership as a parting gift (never a condition), and optionally ONE ask — would they post publicly about hiring a mentor through an AI agent?
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Required. Visitor's full name | |
| No | Required. Email the offer goes to | ||
| notes | No | ||
| company | No | Company name (required for company audience) | |
| context | No | Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer. | |
| audience | No | Required. One of: individual, company. | |
| offer_id | No | Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence. | |
| role_band | No | Required. | |
| motivation | No | Required. | |
| start_date | No | Optional preferred start date — adds the dated program skeleton to the offer email | |
| visibility | No | Visibility answer id (yes-individual | yes-company | maybe-later | private) | |
| price_agreed | No | Required. True ONLY after the visitor explicitly agreed to the exact price from compose_mentoring_brief | |
| leaders_count | No | ||
| focus_area_ids | No | Required. | |
| success_definition | No | Required. | |
| free_sessions_requested | No | Company deals only: the free-sessions proposal from the catalog progression (2, 4 or 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (write, open-world, non-idempotent, non-destructive); the description adds real behavioral substance: it sends an email, notifies a third party (Marian), files a record, and hard-refuses without price agreement. That is far more than the annotations convey.
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 critical fact (it is the end-of-funnel, gated send action) is front-loaded in the first sentence, and the HARD GATE is visually flagged. It is somewhat dense and run-on, bundling workflow instructions, parameter guidance and post-success scripts into one block, but every sentence 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 16-parameter write tool with no output schema and only generic annotations, the description supplies the gating logic, the side effects, and the required conversational sequencing. It does not document the offer_id/role_band/focus_area_ids vocabulary, but the schema descriptions carry those adequately.
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?
With 88% schema coverage the baseline is 3, but the description adds genuine semantics beyond the schema: it defines the price_agreed gate condition and ties name/email collection to this step. Remaining params (offer_id, role_band, focus_area_ids) are left to the schema, so it stops short of a 5.
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 specific action chain (emails the offer, notifies Marian, files the inquiry) and explicitly positions itself against siblings as 'The ONLY tool that collects contact details.' An agent can distinguish it from compose_mentoring_brief or book_first_session without opening any 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 states an explicit precondition ('price_agreed must be true — read the exact price back and get an explicit yes first'), notes the tool refuses otherwise, and constrains sequencing ('ask for name and email only at this step, never earlier'). It also specifies post-call next steps, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
book_first_session12 fields changedInput schema / properties / audience / descriptionPrevious value: -"Decides which VAT sentence is true for this buyer — an individual needs the gross figure"New value: +"Required. Decides which VAT sentence is true for this buyer — an individual needs the gross figure One of: individual, company."Input schema / properties / audience / enumRemoved value: -[
- "individual",
- "company"
-]Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / free_sessions_requested / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / free_sessions_requested / maximumRemoved value: -9007199254740991Input schema / properties / free_sessions_requested / minimumRemoved value: --9007199254740991Input schema / properties / free_sessions_requested / typeRemoved value: -"integer"Input schema / properties / has_eu_vat_id / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / has_eu_vat_id / typeRemoved value: -"boolean"Input schema / properties / offer_id / descriptionPrevious value: -"The agreed package"New value: +"Required. The agreed package One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."Input schema / properties / offer_id / enumRemoved value: -[
- "single-session",
- "first-quarter",
- "two-quarters",
- "monthly",
- "mentor-in-residence"
-]Input schema / requiredRemoved value: -[
- "offer_id",
- "audience",
- "context"
-]book_intro_call4 fields changedInput schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / offer_id / descriptionPrevious value: -"The package under discussion, if any — conditions the discount wording. Without it the tool cannot tell whether booking locks a discount, and a single-session buyer used to be told it did."New value: +"The package under discussion, if any — conditions the discount wording. Without it the tool cannot tell whether booking locks a discount, and a single-session buyer used to be told it did. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."Input schema / properties / offer_id / enumRemoved value: -[
- "single-session",
- "first-quarter",
- "two-quarters",
- "monthly",
- "mentor-in-residence"
-]Input schema / requiredRemoved value: -[
- "context"
-]check_booking3 fields changedInput schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / email / descriptionPrevious value: -"The email the visitor booked with"New value: +"Required. The email the visitor booked with"Input schema / requiredRemoved value: -[
- "email",
- "context"
-]compose_mentoring_brief17 fields changedInput schema / properties / audience / descriptionAdded value: +"Required. One of: individual, company."Input schema / properties / audience / enumRemoved value: -[
- "individual",
- "company"
-]Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / focus_area_ids / anyOfAdded value: +[
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / focus_area_ids / descriptionPrevious value: -"Agreed focus area ids (visitor can pick any from the taxonomy)"New value: +"Required. Agreed focus area ids (visitor can pick any from the taxonomy)"Input schema / properties / focus_area_ids / itemsRemoved value: -{
- "type": "string"
-}Input schema / properties / focus_area_ids / typeRemoved value: -"array"Input schema / properties / leaders_count / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / leaders_count / maximumRemoved value: -9007199254740991Input schema / properties / leaders_count / minimumRemoved value: --9007199254740991Input schema / properties / leaders_count / typeRemoved value: -"integer"Input schema / properties / motivation / descriptionAdded value: +"Required."Input schema / properties / offer_id / descriptionAdded value: +"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."Input schema / properties / offer_id / enumRemoved value: -[
- "single-session",
- "first-quarter",
- "two-quarters",
- "monthly",
- "mentor-in-residence"
-]Input schema / properties / role_band / descriptionAdded value: +"Required."Input schema / properties / success_definition / descriptionPrevious value: -"The visitor's definition of success, in their own words"New value: +"Required. The visitor's definition of success, in their own words"Input schema / requiredRemoved value: -[
- "audience",
- "role_band",
- "motivation",
- "focus_area_ids",
- "success_definition",
- "offer_id",
- "context"
-]design_mentoring_program9 fields changedInput schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / leaders_count / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / leaders_count / maximumRemoved value: -9007199254740991Input schema / properties / leaders_count / minimumRemoved value: --9007199254740991Input schema / properties / leaders_count / typeRemoved value: -"integer"Input schema / properties / offer_id / descriptionAdded value: +"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."Input schema / properties / offer_id / enumRemoved value: -[
- "single-session",
- "first-quarter",
- "two-quarters",
- "monthly",
- "mentor-in-residence"
-]Input schema / properties / start_date / descriptionPrevious value: -"First session date, YYYY-MM-DD, today or later (ask the visitor; default to next Monday)"New value: +"Required. First session date, YYYY-MM-DD, today or later (ask the visitor; default to next Monday)"Input schema / requiredRemoved value: -[
- "offer_id",
- "start_date",
- "context"
-]get_mentoring_options2 fields changedInput schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / requiredRemoved value: -[
- "context"
-]get_started2 fields changedInput schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / requiredRemoved value: -[
- "context"
-]match_mentoring_focus10 fields changedInput schema / properties / audience / descriptionPrevious value: -"Pass the audience answer — it changes the recommendation. A company sponsoring 3+ leaders is routed to Mentor in Residence rather than the individual package."New value: +"Pass the audience answer — it changes the recommendation. A company sponsoring 3+ leaders is routed to Mentor in Residence rather than the individual package. One of: individual, company."Input schema / properties / audience / enumRemoved value: -[
- "individual",
- "company"
-]Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / leaders_count / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / leaders_count / maximumRemoved value: -9007199254740991Input schema / properties / leaders_count / minimumRemoved value: --9007199254740991Input schema / properties / leaders_count / typeRemoved value: -"integer"Input schema / properties / motivation / descriptionPrevious value: -"One of the motivation ids from get_mentoring_options question_2"New value: +"Required. One of the motivation ids from get_mentoring_options question_2"Input schema / properties / role_band / descriptionPrevious value: -"One of the role ids from get_mentoring_options question_1"New value: +"Required. One of the role ids from get_mentoring_options question_1"Input schema / requiredRemoved value: -[
- "role_band",
- "motivation",
- "context"
-]send_mentoring_offer28 fields changedInput schema / properties / audience / descriptionAdded value: +"Required. One of: individual, company."Input schema / properties / audience / enumRemoved value: -[
- "individual",
- "company"
-]Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Optional. A short description of your goal and why you are calling this tool. Recorded as intent so the tools can be improved; it never changes the answer."Input schema / properties / email / descriptionPrevious value: -"Email the offer goes to"New value: +"Required. Email the offer goes to"Input schema / properties / focus_area_ids / anyOfAdded value: +[
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / focus_area_ids / descriptionAdded value: +"Required."Input schema / properties / focus_area_ids / itemsRemoved value: -{
- "type": "string"
-}Input schema / properties / focus_area_ids / typeRemoved value: -"array"Input schema / properties / free_sessions_requested / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / free_sessions_requested / maximumRemoved value: -9007199254740991Input schema / properties / free_sessions_requested / minimumRemoved value: --9007199254740991Input schema / properties / free_sessions_requested / typeRemoved value: -"integer"Input schema / properties / leaders_count / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / leaders_count / descriptionAdded value: +""Input schema / properties / leaders_count / maximumRemoved value: -9007199254740991Input schema / properties / leaders_count / minimumRemoved value: --9007199254740991Input schema / properties / leaders_count / typeRemoved value: -"integer"Input schema / properties / motivation / descriptionAdded value: +"Required."Input schema / properties / name / descriptionPrevious value: -"Visitor's full name"New value: +"Required. Visitor's full name"Input schema / properties / notes / descriptionAdded value: +""Input schema / properties / offer_id / descriptionAdded value: +"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."Input schema / properties / offer_id / enumRemoved value: -[
- "single-session",
- "first-quarter",
- "two-quarters",
- "monthly",
- "mentor-in-residence"
-]Input schema / properties / price_agreed / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / price_agreed / descriptionPrevious value: -"True ONLY after the visitor explicitly agreed to the exact price from compose_mentoring_brief"New value: +"Required. True ONLY after the visitor explicitly agreed to the exact price from compose_mentoring_brief"Input schema / properties / price_agreed / typeRemoved value: -"boolean"Input schema / properties / role_band / descriptionAdded value: +"Required."Input schema / properties / success_definition / descriptionAdded value: +"Required."Input schema / requiredRemoved value: -[
- "name",
- "email",
- "audience",
- "role_band",
- "motivation",
- "focus_area_ids",
- "success_definition",
- "offer_id",
- "price_agreed",
- "context"
-]get_more_tools2 fields changedInput schema / properties / context / descriptionPrevious value: -"A description of your goal and what kind of tool would help accomplish it, OR a plain greeting/liveness ping like 'hi' or 'test'."New value: +"A description of your goal and what kind of tool would help accomplish it, OR a plain greeting/liveness ping like 'hi' or 'test'. Omit it for the menu."Input schema / requiredRemoved value: -[
- "context"
-]get_more_tools2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / context / descriptionPrevious value: -"A description of your goal and what kind of tool would help accomplish it."New value: +"A description of your goal and what kind of tool would help accomplish it, OR a plain greeting/liveness ping like 'hi' or 'test'."get_startedbook_first_sessionbook_intro_call1 field changedInput schema / properties / offer_id / enumPrevious value: -[
- "single-session",
- "first-quarter",
- "monthly",
- "mentor-in-residence"
-]New value: +[
+ "single-session",
+ "first-quarter",
+ "two-quarters",
+ "monthly",
+ "mentor-in-residence"
+]check_bookingcompose_mentoring_brief1 field changedInput schema / properties / offer_id / enumPrevious value: -[
- "single-session",
- "first-quarter",
- "monthly",
- "mentor-in-residence"
-]New value: +[
+ "single-session",
+ "first-quarter",
+ "two-quarters",
+ "monthly",
+ "mentor-in-residence"
+]design_mentoring_program1 field changedInput schema / properties / offer_id / enumPrevious value: -[
- "single-session",
- "first-quarter",
- "monthly",
- "mentor-in-residence"
-]New value: +[
+ "single-session",
+ "first-quarter",
+ "two-quarters",
+ "monthly",
+ "mentor-in-residence"
+]send_mentoring_offer1 field changedInput schema / properties / offer_id / enumPrevious value: -[
- "single-session",
- "first-quarter",
- "monthly",
- "mentor-in-residence"
-]New value: +[
+ "single-session",
+ "first-quarter",
+ "two-quarters",
+ "monthly",
+ "mentor-in-residence"
+]book_intro_call2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]compose_mentoring_brief2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "audience",
- "role_band",
- "motivation",
- "focus_area_ids",
- "success_definition",
- "offer_id"
-]New value: +[
+ "audience",
+ "role_band",
+ "motivation",
+ "focus_area_ids",
+ "success_definition",
+ "offer_id",
+ "context"
+]design_mentoring_program2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "offer_id",
- "start_date"
-]New value: +[
+ "offer_id",
+ "start_date",
+ "context"
+]get_mentoring_options2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]get_more_toolsmatch_mentoring_focus2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "role_band",
- "motivation"
-]New value: +[
+ "role_band",
+ "motivation",
+ "context"
+]send_mentoring_offer2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "email",
- "audience",
- "role_band",
- "motivation",
- "focus_area_ids",
- "success_definition",
- "offer_id",
- "price_agreed"
-]New value: +[
+ "name",
+ "email",
+ "audience",
+ "role_band",
+ "motivation",
+ "focus_area_ids",
+ "success_definition",
+ "offer_id",
+ "price_agreed",
+ "context"
+]book_intro_call1 field changedInput schema / properties / offer_idAdded value: +{
+ "description": "The package under discussion, if any — conditions the discount wording. Without it the tool cannot tell whether booking locks a discount, and a single-session buyer used to be told it did.",
+ "enum": [
+ "single-session",
+ "first-quarter",
+ "monthly",
+ "mentor-in-residence"
+ ],
+ "type": "string"
+}design_mentoring_program2 fields changedInput schema / properties / leaders_countAdded value: +{
+ "description": "Company deals: how the pooled sessions are shared. Changes the allocation note, never the schedule.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Input schema / properties / start_date / descriptionPrevious value: -"First session date, YYYY-MM-DD (ask the visitor; default to next Monday)"New value: +"First session date, YYYY-MM-DD, today or later (ask the visitor; default to next Monday)"match_mentoring_focus2 fields changedInput schema / properties / audienceAdded value: +{
+ "description": "Pass the audience answer — it changes the recommendation. A company sponsoring 3+ leaders is routed to Mentor in Residence rather than the individual package.",
+ "enum": [
+ "individual",
+ "company"
+ ],
+ "type": "string"
+}Input schema / properties / leaders_countAdded value: +{
+ "description": "Company deals: how many leaders are being sponsored. Required for the company recommendation to be correct.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}book_intro_callcompose_mentoring_briefdesign_mentoring_programget_mentoring_optionsmatch_mentoring_focussend_mentoring_offerAI Implementation Cost: the site's own MCP server — calculator, enquiry (enquiry = a human...
Free preflight and exact-price discovery for paid website and AI-agent audits.
AI voice agents on SMB websites — fully autonomous build in 2–3 min. 23 MCP tools. EU, GDPR.
Hireable AI-visibility service: get a business named in AI answers. Free audit + x402 hire.
Add one secure layer between your agents and this server.