elc-toolkit

ELC membership business-case builder

build_partnership_business_case

Read-onlyIdempotent

Builds the internal business case for partnering with Engineering Leaders Community: real reach numbers (3,300+ members, 120+ per meetup, 500+ at the annual conference, newsletter open rate), the deliverables that actually serve the stated goal, where a proposed budget lands on the published ladder, and a forwardable approval email. States the published price RANGE (free layer to EUR 20,000/year, EUR 32,000 with category exclusivity); for composing and pricing an exact package item by item, use the dedicated Membership Builder MCP server at https://www.engineeringleaders.io/mcp/partnership.

Input Schema

Name	Required	Description
`goal`	No	Required. The primary reason to partner with ELC. people_development means developing your own engineering leaders through mentoring and the Academy One of: hiring, brand_awareness, product_feedback, thought_leadership, people_development.
`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.
`buying_for`	No	Who is buying. 'company' (default) builds the annual membership case. 'individual' means a person spending their own money — returns the free-membership route, not an approval email. 'one_off' means one thing once rather than a year, and routes to the one-off menu. One of: company, individual, one_off.
`sender_name`	No	Optional: who the approval email is signed by
`company_name`	No	Optional: the company considering the membership
`approver_name`	No	Optional: who the approval email is addressed to. Supplied, it is used in the greeting; omitted, the draft opens with a plain 'Hi,' rather than a placeholder
`proposed_budget_eur`	No	Optional: a proposed budget figure, if one exists yet. 0 is a valid answer and routes to the free membership layer

Output Schema

Name	Required	Description
`report`	Yes	The full human-readable report.
`source`	Yes	Canonical engineeringleaders.io page this answer is derived from.
`verdict`	No	Headline verdict, when the tool returns one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026
- addedInput schema / properties / proposed_budget_eur / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]
```
- removedInput schema / properties / proposed_budget_eur / type
```
Removed value: -"number"
```

Changed6 schema fields changedSep 11, 2026

changedInput schema / properties / buying_for / description

Previous value: -"Who is buying. 'company' (default) builds the annual membership case. 'individual' means a person spending their own money — returns the free-membership route, not an approval email. 'one_off' means one thing once rather than a year, and routes to the one-off menu."New value: +"Who is buying. 'company' (default) builds the annual membership case. 'individual' means a person spending their own money — returns the free-membership route, not an approval email. 'one_off' means one thing once rather than a year, and routes to the one-off menu. One of: company, individual, one_off."

removedInput schema / properties / buying_for / enum

Removed value: -[
-  "company",
-  "individual",
-  "one_off"
-]

changedInput schema / properties / context / description

Previous 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."

changedInput schema / properties / goal / description

Previous value: -"The primary reason to partner with ELC. One of: hiring, brand_awareness, product_feedback, thought_leadership, people_development (developing your own engineering leaders through mentoring and the Academy)"New value: +"Required. The primary reason to partner with ELC. people_development means developing your own engineering leaders through mentoring and the Academy One of: hiring, brand_awareness, product_feedback, thought_leadership, people_development."

removedInput schema / properties / goal / enum

Removed value: -[
-  "hiring",
-  "brand_awareness",
-  "product_feedback",
-  "thought_leadership",
-  "people_development"
-]

removedInput schema / required

Removed value: -[
-  "goal",
-  "context"
-]

Changed1 schema field changedSep 5, 2026

addedInput schema / properties / buying_for

Added value: +{
+  "description": "Who is buying. 'company' (default) builds the annual membership case. 'individual' means a person spending their own money — returns the free-membership route, not an approval email. 'one_off' means one thing once rather than a year, and routes to the one-off menu.",
+  "enum": [
+    "company",
+    "individual",
+    "one_off"
+  ],
+  "type": "string"
+}

Changed5 schema fields changedSep 5, 2026

addedInput schema / properties / approver_name

Added value: +{
+  "description": "Optional: who the approval email is addressed to. Supplied, it is used in the greeting; omitted, the draft opens with a plain 'Hi,' rather than a placeholder",
+  "type": "string"
+}

changedInput schema / properties / goal / description

Previous value: -"The primary reason to partner with ELC"New value: +"The primary reason to partner with ELC. One of: hiring, brand_awareness, product_feedback, thought_leadership, people_development (developing your own engineering leaders through mentoring and the Academy)"

changedInput schema / properties / goal / enum

Previous value: -[
-  "hiring",
-  "brand_awareness",
-  "product_feedback",
-  "thought_leadership"
-]New value: +[
+  "hiring",
+  "brand_awareness",
+  "product_feedback",
+  "thought_leadership",
+  "people_development"
+]

changedInput schema / properties / proposed_budget_eur / description

Previous value: -"Optional: a proposed budget figure, if one exists yet, to frame the per-outcome bar against"New value: +"Optional: a proposed budget figure, if one exists yet. 0 is a valid answer and routes to the free membership layer"

addedInput schema / properties / sender_name

Added value: +{
+  "description": "Optional: who the approval email is signed by",
+  "type": "string"
+}

Changed2 schema fields changedAug 27, 2026

addedInput schema / properties / context

Added 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"
+}

changedInput schema / required

Previous value: -[
-  "goal"
-]New value: +[
+  "goal",
+  "context"
+]

Changed1 schema field changedAug 21, 2026

changedInput schema / properties / company_name / description

Previous value: -"Optional: the company considering the partnership"New value: +"Optional: the company considering the membership"

First observedAug 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to repeat safety properties. It adds useful behavioral context by naming the output artifacts, stating that it reports a published price range rather than an exact package, and pointing to the separate exact-pricing tool. It does not cover auth or rate limits, but those are not central here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the tool's purpose and main outputs, and the alternative-server guidance comes at the end where it is most useful. It is dense but every clause contributes concrete value, including reach metrics and pricing scope. It could be tightened slightly, but it is appropriately structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be fully explained, but the description still gives a strong sense of what the tool produces. It covers the core use case, the price-range limitation, and the alternative for exact package composition. For this tool's complexity and sibling set, it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter, including goal, buying_for, and proposed_budget_eur. The description adds only indirect meaning by referring to the stated goal, proposed budget placement, and approval email. With full schema 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.

Purpose5/5

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 builds an internal business case for partnering with Engineering Leaders Community. It also enumerates the concrete outputs (reach numbers, deliverables, budget-ladder placement, approval email), making its purpose unmistakable. It distinguishes itself from the dedicated Membership Builder server for exact package composition and pricing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit alternative for a closely related task: use the dedicated Membership Builder MCP server for composing and pricing an exact package item by item. It also implies the appropriate use case is producing an internal business case rather than transactional package configuration. This is clear routing guidance.

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

All elc-toolkit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.