Build and price an ELC community partnership: match, customize, 12-month plan, 16% AI discount.
The second legitimate ending besides request_offer: a direct booking link for a 1:1 intro meeting with Marian Kamenistak, ELC's founder. Offer it whenever the visitor hesitates, wants a human, or the package needs tailoring beyond the catalog. No contact details collected here — the booking page handles everything. Pass preset_id and item_ids if a package was composed: the response then carries a paste-ready booking note, so the call starts from their numbers instead of from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| item_ids | No | Optional: the basket composed so far, if any | |
| preset_id | No | Optional: the package composed so far, if any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavioral context beyond that: 'No contact details collected here — the booking page handles everything' and that passing preset_id/item_ids causes 'the response then carries a paste-ready booking note.' This clarifies the tool's side-effect-light nature without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: purpose first, then usage conditions, then parameter behavior. Every sentence earns its place, and there is no filler or repetition of schema content.
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?
Given three parameters, no output schema, and a set of sibling alternatives, the description covers what the tool does, when to use it, how the optional parameters change the response, and what the user-facing outcome is. An agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds real semantic value for the optional parameters: 'Pass preset_id and item_ids if a package was composed: the response then carries a paste-ready booking note, so the call starts from their numbers instead of from scratch.' This goes beyond the schema by explaining why and how these parameters affect the outcome.
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: 'book' a '1:1 intro meeting with Marian Kamenistak, ELC's founder.' It also positions itself as 'the second legitimate ending besides request_offer,' sharply distinguishing it from siblings and making the tool's purpose unmistakable.
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 names the alternative ('besides request_offer') and gives concrete trigger conditions: 'whenever the visitor hesitates, wants a human, or the package needs tailoring beyond the catalog.' This gives an agent clear decision criteria for when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns a composed basket into the argument that gets it approved: recruiter-fee equivalence, break-even hire count, cost per room, cost per month, what the spend replaces, and every assumption behind those numbers. Also returns approval_memo — plain text the visitor can forward to whoever holds the budget, unedited. Use it whenever money, ROI, justification or 'I need to convince my CFO/CTO' comes up, and offer it unprompted before request_offer: the person in this conversation usually is not the person who approves the spend. Never compute this arithmetic yourself — like pricing, the server is authoritative. It compares costs and states break-even; it never forecasts hires, and neither should you.
| Name | Required | Description | Default |
|---|---|---|---|
| kpis | No | Optional: what has to move this year, in their words | |
| company | No | Optional: company name, for the memo | |
| context | Yes | 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." | |
| item_ids | Yes | The basket: item ids toggled ON | |
| preset_id | Yes | The package being justified | |
| requester_name | No | Optional: who is asking for approval, signed at the memo's foot | |
| open_senior_roles | No | Optional: senior roles they need to fill in 12 months — sharpens the comparison into their numbers | |
| avg_first_year_salary | No | Optional: average first-year salary in EUR for those roles; turns the generic fee band into their own |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description adds critical behavioral context: the server is authoritative for arithmetic, the tool never forecasts hires, and it returns a forwardable plain-text memo meant for an approver rather than the current user. This goes well beyond what annotations alone convey and prevents misuse.
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 with no filler: the first states the core output, the second gives usage timing and audience context, the third explains the authoritative-computation boundary. Every sentence carries actionable weight and 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 tool with 8 parameters, no output schema, and a consequential business-decision purpose, the description explains what it returns, when to use it, what to avoid, and how it fits the conversation flow. Nothing an agent needs to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description does not add parameter-specific guidance beyond mentioning the 'basket' (item_ids) and 'package' (preset_id), but the schema already documents each parameter fully. It neither improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource mapping: 'Turns a composed basket into the argument that gets it approved,' then enumerates concrete outputs (recruiter-fee equivalence, break-even hire count, cost per room, approval_memo). It clearly distinguishes itself from siblings by positioning itself before request_offer and disclaiming hire forecasting.
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?
Provides explicit trigger conditions ('whenever money, ROI, justification or "I need to convince my CFO/CTO" comes up'), an explicit alternative ('before request_offer'), and a strong exclusion ('Never compute this arithmetic yourself'). This leaves no doubt about when to select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The conversational toggle board. Pass the preset and the item ids currently ON; returns the recomputed total (never trust your own arithmetic — this is the authoritative price), every selected item with its price, and what else this tier could add. Items marked foundation anchor the package; advise keeping them. Call again after every change the visitor asks for. Next: request_offer.
| Name | Required | Description | Default |
|---|---|---|---|
| seats | No | Starter only: how many people they are enrolling. Starter is priced per seat with volume bands, so ALWAYS ask for a headcount before quoting it — the bundle price is only the 3-seat entry. | |
| context | Yes | 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." | |
| item_ids | Yes | Item ids currently toggled ON (from match_package default_item_ids, plus/minus changes) | |
| preset_id | Yes | The package being customized |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that the tool is the authoritative price source and warns against doing own arithmetic, explains the return contents (total, selected items with prices, addable items), and gives guidance about foundation items. It also says to call again after every change, reinforcing idempotent stateless behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no filler. The purpose is front-loaded, and each sentence adds value: invocation, authoritative output, foundation-item guidance, and call frequency/next step.
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 adequately explains what will be returned and how to interpret it. It also covers when to call, what to pass, and what to advise about foundation items, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has substantial detail, including the seats headcount warning and item_ids provenance. The description only restates 'pass the preset and the item ids currently ON' without adding new parameter-level meaning, 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: customize a package by toggling line items and recomputing the authoritative total. It clearly distinguishes itself from related tools by describing this as the conversational toggle board that operates on currently-ON item IDs and hands off to request_offer next.
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?
Provides clear context: call it after every visitor change, pass the preset and currently-ON item IDs, and use its computed total as authoritative. It also routes the workflow forward with 'Next: request_offer.' It does not explicitly name alternatives or exclusions, but the intended usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The moment the package becomes a year: deterministic month-by-month plan of what lands when, computed from the basket's own scheduling metadata (lead times, anchors like the April 2027 conference, spacing, and heavy-event collision rules). Returns placed months, the recurring-every-month layer, and anything unplaceable WITH its reason. The plan contains ONLY items in the basket — narrate around it, never add or move an event. Call after customize_package, before request_offer.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| item_ids | Yes | The basket: item ids toggled ON | |
| preset_id | Yes | ||
| start_month | Yes | First membership month, YYYY-MM (ask the visitor; default to the month after the current one) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond those flags: the plan is deterministic, computed from the basket's scheduling metadata, and returns unplaceable items with reasons. It also reinforces that the tool does not mutate the basket, which matches and augments the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry a lot of information: the core output, the computation source, the return payload, the scope restriction, and the pipeline order. There is a slight stylistic flourish in 'The moment the package becomes a year,' but it is not wasted. The description is front-loaded with the result and does not repeat annotations.
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?
Despite having no output schema, the description tells the agent what the tool returns: placed months, the recurring-every-month layer, and unplaceable items with reasons. It also states the scope constraint and pipeline position. It could say more about how start_month or anchors influence output, but the essentials for correct invocation are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters, and context description is unusually detailed. The description adds the concept of the 'basket' mapping to item_ids and mentions scheduling metadata as the computation basis, but it does not provide deeper per-parameter guidance. With schema coverage at 75%, the description is adequate but does not go beyond what the schema supplies.
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 precise verb and resource: it produces a deterministic month-by-month plan of what lands when for a basket. It clearly distinguishes itself from siblings by explicitly saying the plan contains ONLY items in the basket and never adds or moves an event, which is different from customize_package and request_offer.
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 pipeline positioning: 'Call after customize_package, before request_offer.' It also implies when not to use the tool by warning against adding or moving events. It does not list every sibling alternative, but the sequencing is unambiguous and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the visitor names a NUMBER rather than a band — 'we have 8,000 approved', 'can we do this for five thousand'. Returns a deterministic best-value composition under that ceiling: what fits, what was left out AND why, how much budget is unspent, and what the cheapest excluded item costs. Foundation items are kept first, then the remaining items cheapest-first so the budget buys as much as possible. Priced against the AI-channel figure by default, since that is what they would actually pay. Never hand-pick a basket yourself when a budget is stated — this tool is the authoritative composition, the same way customize_package is the authoritative total.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | Yes | The visitor's ceiling in EUR, as a number (8000, not '8K') | |
| against | No | Price the budget against the AI-channel figure (default) or the list price | |
| context | Yes | 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." | |
| must_have | No | Optional: item ids the visitor explicitly asked for; kept first if they fit | |
| preset_id | Yes | The package to trim to budget (from match_package) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations covering readOnly and idempotent, the description adds rich behavioral detail: foundation items kept first, remaining items chosen cheapest-first, default AI-channel pricing, and exact response contents including unspent budget and cheapest excluded item. This goes far beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: trigger, return value, selection algorithm, pricing basis, and authority are all covered in dense, well-ordered prose. The most important usage condition is front-loaded with concrete examples.
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 clearly stating what the response contains: what fits, what was left out and why, unspent budget, and cost of the cheapest excluded item. Combined with full parameter schema coverage, no critical call-time decision is left unexplained.
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 meaning beyond the schema: budget is a ceiling, must-have items are kept first if they fit, and the 'against' parameter defaults to the AI-channel figure. This is useful supplemental semantics without needing to re-document every parameter.
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 verb and resource: composing the best package for an exact numeric budget, returning a deterministic best-value composition under a ceiling. It also differentiates itself from customize_package by framing it as the authoritative composition tool versus the authoritative total.
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 trigger is explicit: use when the visitor names a NUMBER rather than a band, with concrete examples ('8,000 approved', 'five thousand'). It also gives a clear when-not: never hand-pick a basket when a budget is stated, making this tool the authoritative composition.
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 and this returns the full menu instead of a dead end.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | A description of your goal and what kind of tool would help accomplish it, OR a plain greeting/liveness ping like 'hi' or 'test'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context beyond annotations: it returns the full menu instead of a dead end, and it can act as a connectivity/liveness test. This adds useful information about what the tool actually does.
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 concise and front-loaded with the primary purpose, then elaborates on the fallback use case. Every sentence earns its place, and it avoids unnecessary fluff.
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?
Given the tool's simplicity (single parameter, no output schema) and annotations covering safety, the description is complete. It explains when to use it, what to pass, and what the response will be (the full menu). No missing information an agent needs 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%, so the schema already fully documents the 'context' parameter. The description repeats the same information about greetings and liveness pings, adding no new meaning beyond what the schema provides. 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 the tool's purpose: to check for additional tools when a task might benefit from specialized capabilities, and to handle bare greetings or liveness pings as a fallback. It distinguishes itself from siblings by being the catch-all for messages too general to match a specific 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 explicitly states when to use it: whenever a task might benefit from specialized capabilities, even if existing tools could work, and for bare greetings or liveness tests. It also implies when not to use it by saying 'too general to match a specific tool', guiding the agent to use specific tools when they apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE for any company considering an ELC membership (personas: HR, CTO, employer branding). Returns how company membership works, real community reach figures, and the two qualifying questions with their valid answers. Companies only — individuals seeking a mentor for themselves get pointed to /mentor/ instead. After the visitor answers both questions, call match_package.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds behavioral context beyond annotations: it is an informational starting point, it routes non-qualifying users elsewhere, and it defines a follow-up action. It does not detail return format or pagination, but that is a minor gap for a simple read-only 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 compact and well-structured: it front-loads the primary usage ('START HERE'), then states what is returned, who is excluded, and what to do next. Every sentence provides distinct value with no filler or redundant restating of the tool 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?
For a one-parameter, read-only informational tool, the description is complete. It covers the target audience, the content returned, the exclusion case, and the follow-up tool. No output schema exists, but the description sufficiently explains what the agent can expect to deliver to the visitor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a thorough description of the only parameter, context, including word-count requirements, perspective rules, and sensitive-data restrictions. The tool description does not add parameter-level detail, but with 100% schema description coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'START HERE' and states exactly what the tool returns: how company membership works, community reach figures, and the two qualifying questions with valid answers. It clearly targets companies considering an ELC membership and distinguishes itself by routing individual mentor-seekers to /mentor/ and pointing to match_package as the next step, so it does not blur with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'START HERE for any company considering an ELC membership' with personas listed. It also states when not to use it ('Companies only — individuals seeking a mentor for themselves get pointed to /mentor/ instead') and names the follow-up tool ('After the visitor answers both questions, call match_package'). This gives clear decision rules and routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE when a company wants ONE thing once, not a year-long membership: a section or a dedicated send in the Leaders' Brief newsletter, a meetup hosted in their office, a podcast episode, a decision-maker dinner, a community survey, a demo session, a LinkedIn post, a job board listing. Returns every one-off with its price, lead time, examples and real reach figures, the combo discount rule, the 90-day credit against a membership, and what is not for sale. Two or more things across a year is a membership conversation: hand over to get_partnership_options. Next: quote_reach_combo once items are picked.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context by revealing exactly what the tool returns: prices, lead times, examples, real reach figures, the combo discount rule, the 90-day credit, and what is not for sale. It also communicates workflow behavior like 'START HERE' and handoff to siblings.
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 longer than minimal but every sentence earns its place: trigger condition, concrete item examples, return contents, membership boundary, and next step. It is front-loaded with the most important usage signal. The enumeration of examples is slightly dense but materially improves disambiguation.
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 compensates by specifying the return payload in useful detail: price, lead time, examples, reach figures, combo discount rule, credit, and exclusions. Combined with the clear usage conditions and next-step routing, the description gives an agent everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, context, and it is fully described with 100% coverage including word count and style rules. The description does not need to add parameter-level detail; per the rubric, high schema coverage sets a baseline of 3. No additional semantic value is required here.
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 is explicit and specific: it tells the agent this tool is the entry point for one-off purchases, enumerates concrete examples (newsletter send, meetup, podcast episode, etc.), and says it returns prices and reach figures. It clearly distinguishes itself from get_partnership_options and quote_reach_combo, so sibling confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is strong and explicit. It states the exact trigger condition ('START HERE when a company wants ONE thing once'), defines the boundary ('Two or more things across a year is a membership conversation'), and names the alternative tool to hand over to. It also gives a clear next step: call quote_reach_combo once items are picked.
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 a company actually considering ELC membership, skip straight to get_partnership_options instead.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds useful behavioral context by stating that it returns a full menu of questions mapped to tool names, which is the expected output for a liveness/overview endpoint.
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, each earning its place: the first lists trigger types, the second explains the return value, the third gives the exclusion. It is front-loaded and free of 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?
For a simple one-parameter, read-only, idempotent tool with no output schema, the description provides enough: use cases, expected return, and an explicit alternative route. Nothing important is missing for an agent to decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single context parameter thoroughly, including length requirements and restrictions. The description does not need to repeat parameter details; it adds no new parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it handles greetings, connectivity/liveness checks, 'what can you do' questions, and overly general messages. It also distinguishes itself from the sibling tools by naming its role as the fallback entry point that maps questions to the correct 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 conditions and an explicit when-not-to-use condition: skip to get_partnership_options for companies actually considering ELC membership. This is model routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves goal + budget through ELC's own routing matrix — the same one the website uses — and returns the matched package(s) with real prices and their default line items. Map free-text answers to the closest valid id; on bad input the error lists the valid ids, re-ask rather than guessing. Next: customize_package to toggle line items, or request_offer to send it as-is.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | One of the goal ids from get_partnership_options question_1 | |
| budget | Yes | One of the budget ids from get_partnership_options question_2 | |
| context | Yes | 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, so the description adds value beyond that by disclosing the routing-matrix provenance, the real-price guarantee, default line-item inclusion, and the precise error behavior (listing valid ids). These details materially shape how an agent should handle failures and set expectations.
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 sentences, each carrying a distinct purpose: core behavior/output, input handling and error protocol, and next-step routing. It is front-loaded with the most important resolution logic and contains no filler or redundant restatement of the tool name.
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?
Given the absence of an output schema, the description tells the agent exactly what to expect (matched package(s), real prices, default line items) and how to respond to bad input. It also supplies the relationship to neighboring tools, making the tool's position in the overall flow clear without needing extra documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters and references get_partnership_options for goal and budget ids, so baseline is 3. The description adds a crucial normalization rule—map free-text answers to the closest valid id—and clarifies what happens on invalid input, which goes beyond static schema types and helps the agent invoke the tool correctly.
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 operation ('Resolves goal + budget'), the underlying resource ('ELC's own routing matrix'), and a concrete return value ('matched package(s) with real prices and their default line items'). It also differentiates from siblings by pointing to customize_package and request_offer as downstream actions rather than competing alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: map free-text answers to valid ids, and if input is bad re-ask rather than guessing. It also states which sibling to use next depending on whether line items need toggling or the offer should be sent as-is. It lacks an explicit 'when not to use this tool' statement, but the context is strong enough to make routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass the one-off ids the visitor picked; returns each item's price, the list total, the combo discount by item count (job board listings never count), and the final total. This is the only arithmetic that counts — never add prices yourself. The AI-channel percentage does not apply to one-offs. Next: book_intro_call to lock the date, or get_partnership_options if the basket is starting to look like a year.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| oneoff_ids | Yes | One-off ids from get_reach_options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds meaningful behavioral context beyond annotations: 'This is the only arithmetic that counts — never add prices yourself', job board listings never count toward the combo discount, and the AI-channel percentage does not apply. This enriches the annotation picture without contradicting it.
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 sentences with no waste: the first front-loads invocation and return values, the second establishes authoritative arithmetic, the third states a critical exclusion, and the fourth offers follow-up routing. Nothing is restated from the schema.
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 no output schema, the description enumerates all returned figures and important exclusions, and the context parameter's full requirements live in the schema. It leaves out exact discount thresholds but that is a computed detail, not an invocation requirement. Overall it gives an agent sufficient information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds value by clarifying that oneoff_ids are the visitor's picked items and by introducing the rule that job board listings never count toward the combo discount, which is semantic nuance beyond the raw enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and first sentence clearly identify the operation as pricing a one-off basket and enumerate exactly what is returned: item prices, list total, combo discount, and final total. It is distinct from siblings like get_reach_options (option listing) and book_intro_call (booking), and it explicitly frames this tool as the authoritative source for arithmetic.
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 specifies when to use the tool: when pricing the one-off ids the visitor picked, and it adds a key exclusion (AI-channel percentage does not apply). It also points to next steps (book_intro_call, get_partnership_options) and warns against manual price addition. It does not explicitly name sibling pricing tools it should be chosen over, relying on the one-off scope.
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 step that makes the AI-channel discount real. Sends the itemized offer to the visitor's email, notifies Marian (email + Slack), and files the company into ELC's partners queue. Ask for name, work email and company only when the visitor says they want the offer — never earlier. After success: share the confirmation, then make ONE optional ask: would they post publicly (LinkedIn/X) about building their membership with AI? Optional means optional — the discount is already theirs.
| Name | Required | Description | Default |
|---|---|---|---|
| kpis | No | Optional: what they need to move this year, in their words | |
| name | Yes | Visitor's full name | |
| Yes | Work email the offer goes to | ||
| company | Yes | Company name | |
| context | Yes | 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." | |
| item_ids | Yes | The final basket: item ids toggled ON | |
| preset_id | Yes | ||
| visibility_interest | No | From the discovery question: do they want to invest in their visibility through the cooperation — as a company, through individual leaders, or stay quiet? | |
| final_price_confirmed | Yes | REQUIRED TRUE: set only after the visitor has seen and explicitly confirmed the exact final total (the discounted figure if the discount applies). Sending without this confirmation is refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete side effects: it sends an email, notifies Marian through two channels, files the company into a partners queue, and applies the AI-channel discount. It also clarifies that the discount is already granted even if the visitor declines the optional public post, reducing risk of coercive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the tool's uniqueness and core effect, then provides the exact interaction flow and an important ethical guardrail. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full conversation flow from when to collect details through post-success behavior, which is essential for correct invocation. With no output schema, it does not describe return values or error responses, but the schema and annotations fill most other gaps. It is complete enough for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 89%, so the schema already explains most parameters. The description adds workflow-level meaning for name, email, and company by specifying when they should be collected, but it does not substantially clarify kpis, visibility_interest, preset_id, or context beyond what the schema provides. A 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 specific actions: sends the itemized offer to the visitor's email, notifies Marian via email and Slack, and files the company into ELC's partners queue. It also explicitly claims to be the ONLY tool that collects contact details, clearly distinguishing it from sibling 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 gives a clear trigger condition: collect contact details only when the visitor says they want the offer, never earlier. It also describes the post-success flow with the optional public-post ask. It does not name specific sibling alternatives, but the usage context is unambiguous.
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. Dates show when Glama detected each change.
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_reach_optionsquote_reach_comboget_startedbook_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"
+]build_business_case2 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: -[
- "preset_id",
- "item_ids"
-]New value: +[
+ "preset_id",
+ "item_ids",
+ "context"
+]customize_package2 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: -[
- "preset_id",
- "item_ids"
-]New value: +[
+ "preset_id",
+ "item_ids",
+ "context"
+]design_journey2 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: -[
- "preset_id",
- "item_ids",
- "start_month"
-]New value: +[
+ "preset_id",
+ "item_ids",
+ "start_month",
+ "context"
+]fit_to_budget2 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: -[
- "preset_id",
- "budget"
-]New value: +[
+ "preset_id",
+ "budget",
+ "context"
+]get_more_toolsget_partnership_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"
+]match_package2 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: -[
- "goal",
- "budget"
-]New value: +[
+ "goal",
+ "budget",
+ "context"
+]request_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",
- "company",
- "final_price_confirmed",
- "preset_id",
- "item_ids"
-]New value: +[
+ "name",
+ "email",
+ "company",
+ "final_price_confirmed",
+ "preset_id",
+ "item_ids",
+ "context"
+]design_journey1 field changedInput schema / properties / start_month / descriptionPrevious value: -"First partnership month, YYYY-MM (ask the visitor; default to the month after the current one)"New value: +"First membership month, YYYY-MM (ask the visitor; default to the month after the current one)"book_intro_call1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]build_business_case1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]customize_package2 fields changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]Input schema / properties / seats / descriptionPrevious value: -"Team only: how many people they are enrolling. Team is priced per seat with volume bands, so ALWAYS ask for a headcount before quoting it — the bundle price is only the 3-seat entry."New value: +"Starter only: how many people they are enrolling. Starter is priced per seat with volume bands, so ALWAYS ask for a headcount before quoting it — the bundle price is only the 3-seat entry."design_journey1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]fit_to_budget1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]request_offer1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "team",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "starter",
+ "leadership-pilot",
+ "pilot-meetup",
+ "hiring",
+ "education",
+ "vital",
+ "visibility",
+ "story",
+ "product"
+]book_intro_call2 fields changedInput schema / properties / item_idsAdded value: +{
+ "description": "Optional: the basket composed so far, if any",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / preset_idAdded value: +{
+ "description": "Optional: the package composed so far, if any",
+ "enum": [
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "team",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+ ],
+ "type": "string"
+}build_business_casecustomize_package1 field changedInput schema / properties / seatsAdded value: +{
+ "description": "Team only: how many people they are enrolling. Team is priced per seat with volume bands, so ALWAYS ask for a headcount before quoting it — the bundle price is only the 3-seat entry.",
+ "type": "number"
+}fit_to_budgetcustomize_package1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "team",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]design_journey1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "team",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]request_offer1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "vital",
- "hiring",
- "visibility",
- "education",
- "product",
- "story"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "team",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]customize_package1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "orbit",
- "nebula",
- "supernova",
- "quasar"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]design_journey1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "orbit",
- "nebula",
- "supernova",
- "quasar"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]request_offer1 field changedInput schema / properties / preset_id / enumPrevious value: -[
- "free",
- "leadership-pilot",
- "pilot-meetup",
- "orbit",
- "nebula",
- "supernova",
- "quasar"
-]New value: +[
+ "free",
+ "leadership-pilot",
+ "pilot-meetup",
+ "vital",
+ "hiring",
+ "visibility",
+ "education",
+ "product",
+ "story"
+]request_offer2 fields changedInput schema / properties / final_price_confirmedAdded value: +{
+ "description": "REQUIRED TRUE: set only after the visitor has seen and explicitly confirmed the exact final total (the discounted figure if the discount applies). Sending without this confirmation is refused.",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "name",
- "email",
- "company",
- "preset_id",
- "item_ids"
-]New value: +[
+ "name",
+ "email",
+ "company",
+ "final_price_confirmed",
+ "preset_id",
+ "item_ids"
+]request_offer1 field changedInput schema / properties / visibility_interestAdded value: +{
+ "description": "From the discovery question: do they want to invest in their visibility through the cooperation — as a company, through individual leaders, or stay quiet?",
+ "enum": [
+ "company",
+ "individual",
+ "quiet",
+ "undecided"
+ ],
+ "type": "string"
+}book_intro_callcustomize_packagedesign_journeyget_partnership_optionsmatch_packagerequest_offerClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Leadership-ratio benchmark, partnership ROI builder, community-launch readiness test. ELC data.
Score a meetup topic, place a speaker on the right stage, price community reach. ELC data.
Build your mentoring inquiry with Marian Kamenistak: formal offer in 16 minutes, 16% AI discount.
EQ scoring plus a read-only Storelayer matcher and guarded self-install; no website credentials
Add one secure layer between your agents and this server.
Every tool targets a distinct stage or action in the partnership workflow, from discovery (get_partnership_options, get_reach_options) to closing (request_offer, book_intro_call). The only slight overlap between get_started and get_more_tools is clarified by their descriptions—one lists the menu, the other returns the full tool set—so agents can reliably distinguish them. No two tools appear to perform the same function.
All tool names follow a consistent verb_noun snake_case pattern (e.g., build_business_case, customize_package, quote_reach_combo). The verbs are action-oriented and the nouns clearly describe the target object or outcome, making the pattern highly predictable across the set.
With 12 tools, the server is well-scoped for a partnership builder covering membership and one-off reach options. Each tool serves a distinct purpose in the sales and customization lifecycle, and the count is within the ideal range where every tool earns its place.
The tool surface covers the entire partnership journey: initial qualification, package matching, customization, budget fitting, journey planning, business case generation, quoting, and closing (both offer request and booking). There are no obvious dead ends—even fallback entry points (get_started, get_more_tools) prevent stalled conversations.