Build your mentoring inquiry with Marian Kamenistak: formal offer in 16 minutes, 16% AI discount.
Scored across 10 tools
Most tools have clearly distinct roles in the funnel (book_first_session vs book_intro_call are sharply delineated by eligibility, and get_mentoring_options/match_mentoring_focus/compose_mentoring_brief/send_mentoring_offer form a clean pipeline). However, get_started and get_more_tools are nearly identical — both claim a bare greeting, a liveness test, and 'any message too general to match a tool,' and both return the full menu, which will cause misselection.
All ten tools use consistent snake_case verb_object naming (book_first_session, get_mentoring_options, match_mentoring_focus, send_mentoring_offer, compose_mentoring_brief, design_mentoring_program, check_booking). The pattern is predictable throughout with no casing or style drift.
Ten tools is well-scoped for a mentoring inquiry-to-booking funnel, with each step of the described workflow earning a slot. The only mild surplus is the redundant pair get_started/get_more_tools, which could be a single tool.
The surface covers the full lifecycle: discovery, routing/qualification, brief accumulation, program design, offer issuance, both booking paths, and CRM booking verification. Minor gaps remain — no reschedule/cancel booking, no offer status lookup, and no explicit follow-up tool for stalled leads — but core workflows have no dead ends.
THE MAIN ENDING (Marian, 2026-10-09): every onboarding that reaches an agreed price ends here, booking the first regular session. Returns the direct booking link for the paid 60-minute first session, plus the payment terms. Call it right after send_mentoring_offer succeeds. Company-paid mentees book now too: the purchase order is collected AFTER session 1, never before booking. 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, monthly, mentor-in-residence, mentor-in-residence-2day. | |
| 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. |
THE FALLBACK for anyone who has not decided (the main ending is book_first_session once the price is agreed). 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, monthly, mentor-in-residence, mentor-in-residence-2day. |
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, monthly, mentor-in-residence, mentor-in-residence-2day. | |
| 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?
Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description adds real behavioral context on top: the price is authoritative and the agent must never compute it, the AI-channel figure is supplied, and the free-sessions concession is conditionally reported for company deals. None of this is derivable from the structured fields.
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?
Four tight sentences, front-loaded with the tool's role as accumulator, then what it returns, then the conditional concession logic, then the handoff rule. No filler and no restatement of the 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?
There is no output schema, so the description carries the return burden and does so — it names exactly what is echoed back and what price data accompanies it. Combined with the safety annotations and full schema coverage, an agent has everything needed to call and consume 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 coverage is 100%, so the schema already documents all ten parameters including the enumerated answer ids. The description only restates the field list it echoes; it adds no syntax, format, or default guidance beyond what the schema provides, 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 and resource ('compose/echo the full structured brief') and enumerates the fields it carries plus the authoritative price. It also distinguishes itself from the sibling it hands off to (send_mentoring_offer) and from the option-listing tools, so an agent can place it without opening the 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?
Explicit timing ('call after every change') and an explicit downstream condition ('when they explicitly agree on the price, call send_mentoring_offer with price_agreed true'). It also gives the conversational protocol (read the brief back to the visitor) that gates the next call.
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, each with its planned theme (diagnostic, the visitor's focus areas — pass focus_area_ids — the mid-point checkpoint, operational to strategic, 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, monthly, mentor-in-residence, mentor-in-residence-2day. | |
| 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. | |
| focus_area_ids | No | Agreed focus area ids in priority order. They become the planned themes of the focus sessions; without them those sessions read as open. |
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 10 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds behavioral context about what the call produces (discount returned as data, formal offer under 10 minutes, valid answer ids), which is useful. It does not disclose side effects, rate limits, or how the recorded intent affects behavior — though the schema note covers the last point — so 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?
Two sentences, front-loaded with the 'START HERE' directive and an explicit next-step call, with no duplicated boilerplate. It is dense but every clause maps to a distinct output or audience; the marketing-toned 'why-Marian and pricing-defense material' is the only mildly promotional padding.
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 compensates by enumerating the returned payload (discount, time promise, qualifying questions with answer ids, packages with prices), which is exactly what an agent needs to know before calling. Combined with the read-only annotations and the routing to `match_mentoring_focus`, it is nearly complete; only the relationship to the `get_started` sibling is left ambiguous.
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 optional parameter (`context`) exists and schema description coverage is 100%, so the schema already carries its semantics. The description adds nothing about the parameter, which matches the baseline 3 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 states a specific resource (1:1 engineering-leadership mentoring options) and explicitly positions itself as the entry point ('START HERE') for a defined audience (Staff Engineer to CTO, and sponsoring companies). It enumerates what is returned (discount data, time promise, qualifying questions, packages with prices), so an agent can tell what this tool yields. It stops short of 5 because it never distinguishes itself from the unaddressed `get_started` sibling, which could plausibly be confused as the entry point.
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 clear when-to-use guidance ('anyone considering 1:1 mentoring') and an explicit routing instruction: 'After the visitor answers audience + role + motivation, call match_mentoring_focus.' That sequencing is genuinely actionable. There is no explicit when-not guidance or contrast against `get_started`/`get_more_tools`, keeping it below 5.
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 10-minute promise. Also pass every onboarding answer you gathered (heard_from, own_choice, payer, kpis, cadence_preference, session_language, nda_needed, homework_time_ok, in_person_wish, linkedin_url, li_post_consent, li_recommendation); all optional, never invented: 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 |
|---|---|---|---|
| kpis | No | Up to two measurable KPIs in their words, scored in session 1 and the last session | |
| name | No | Required. Visitor's full name | |
| No | Required. Email the offer goes to | ||
| notes | No | ||
| payer | No | Who pays. Company: the purchase order comes AFTER session 1, never before booking One of: self, company, undecided. | |
| 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, monthly, mentor-in-residence, mentor-in-residence-2day. | |
| role_band | No | Required. | |
| heard_from | No | How they found Marian, in their words (referral name, LinkedIn, Google, ChatGPT, ELC…) | |
| motivation | No | Required. | |
| nda_needed | No | One of: no, their-template, marian-template, unsure. | |
| own_choice | No | Mentee's own decision, sent by the company, or both One of: own, sent, both. | |
| 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) | |
| linkedin_url | No | Their LinkedIn profile URL | |
| 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. | |
| in_person_wish | No | Would they like to meet Marian in person (Prague) | |
| li_post_consent | No | May Marian post on LinkedIn that they work together (never the content) One of: yes, later, no. | |
| homework_time_ok | No | Can they give about an hour a week between sessions | |
| session_language | No | One of: cs, sk, en. | |
| li_recommendation | No | Would they write Marian a LinkedIn recommendation once happy One of: yes, later, no. | |
| cadence_preference | No | Preference only; the final cadence is settled after session 1 One of: weekly, biweekly, monthly, undecided. | |
| success_definition | No | Required. | |
| free_sessions_requested | No | Company deals only: the free-sessions proposal from the catalog progression (2, 4 or 8) |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
send_mentoring_offer12 fields changedInput schema / properties / cadence_preferenceAdded value: +{
+ "description": "Preference only; the final cadence is settled after session 1 One of: weekly, biweekly, monthly, undecided.",
+ "type": "string"
+}Input schema / properties / heard_fromAdded value: +{
+ "description": "How they found Marian, in their words (referral name, LinkedIn, Google, ChatGPT, ELC…)",
+ "type": "string"
+}Input schema / properties / homework_time_okAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Can they give about an hour a week between sessions"
+}Input schema / properties / in_person_wishAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Would they like to meet Marian in person (Prague)"
+}Input schema / properties / kpisAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Up to two measurable KPIs in their words, scored in session 1 and the last session"
+}Input schema / properties / li_post_consentAdded value: +{
+ "description": "May Marian post on LinkedIn that they work together (never the content) One of: yes, later, no.",
+ "type": "string"
+}Input schema / properties / li_recommendationAdded value: +{
+ "description": "Would they write Marian a LinkedIn recommendation once happy One of: yes, later, no.",
+ "type": "string"
+}Input schema / properties / linkedin_urlAdded value: +{
+ "description": "Their LinkedIn profile URL",
+ "type": "string"
+}Input schema / properties / nda_neededAdded value: +{
+ "description": "One of: no, their-template, marian-template, unsure.",
+ "type": "string"
+}Input schema / properties / own_choiceAdded value: +{
+ "description": "Mentee's own decision, sent by the company, or both One of: own, sent, both.",
+ "type": "string"
+}Input schema / properties / payerAdded value: +{
+ "description": "Who pays. Company: the purchase order comes AFTER session 1, never before booking One of: self, company, undecided.",
+ "type": "string"
+}Input schema / properties / session_languageAdded value: +{
+ "description": "One of: cs, sk, en.",
+ "type": "string"
+}design_mentoring_program1 field changedInput schema / properties / focus_area_idsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Agreed focus area ids in priority order. They become the planned themes of the focus sessions; without them those sessions read as open."
+}book_first_session1 field changedInput schema / properties / offer_id / descriptionPrevious value: -"Required. The agreed package One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."New value: +"Required. The agreed package One of: single-session, first-quarter, monthly, mentor-in-residence, mentor-in-residence-2day."book_intro_call1 field changedInput 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. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."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, monthly, mentor-in-residence, mentor-in-residence-2day."compose_mentoring_brief1 field changedInput schema / properties / offer_id / descriptionPrevious value: -"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."New value: +"Required. One of: single-session, first-quarter, monthly, mentor-in-residence, mentor-in-residence-2day."design_mentoring_program1 field changedInput schema / properties / offer_id / descriptionPrevious value: -"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."New value: +"Required. One of: single-session, first-quarter, monthly, mentor-in-residence, mentor-in-residence-2day."send_mentoring_offer1 field changedInput schema / properties / offer_id / descriptionPrevious value: -"Required. One of: single-session, first-quarter, two-quarters, monthly, mentor-in-residence."New value: +"Required. One of: single-session, first-quarter, monthly, mentor-in-residence, mentor-in-residence-2day."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_offerEmployee mentoring software. Goals, meetings, messages and surveys from your AI assistant.
AI Implementation Cost: the site's own MCP server — calculator, enquiry (enquiry = a human...
Pressure-test a startup idea in a live voice interview with an AI mentor; get a GO/NO-GO verdict.
Free preflight and exact-price discovery for paid website and AI-agent audits.
Add one secure layer between your agents and this server.