eng-leadership-toolkit

Start here — what can this MCP server do?

get_started

Read-onlyIdempotent

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, so the next call can go straight to the right tool.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

Name	Required	Description
`math`	No	Napkin math behind the case.
`email`	No	Forwardable email to the manager.
`level`	No	Seniority level the score maps to, when the tool computes one.
`report`	Yes	The full human-readable report.
`source`	Yes	Canonical marian.coach page this answer is derived from.
`verdict`	No	Headline verdict, when the tool returns one.
`evidence`	No	Sources the case may cite.
`onePager`	No	Manager-facing one-pager, forwardable to finance.
`salaryEur`	No	Estimated 2026 Western-Europe gross annual salary in EUR.
`objections`	No	The usual objections, answered.
`slackShort`	No	Slack/Teams-length version of the ask.
`totalScore`	No	Weighted 0-10 score, when the tool computes one.
`valueFormula`	No	The four value lines to add up (money saved, cost of delay, missed opportunity, roadmap slippage) plus the count-then-halve CFO rule.
`talkingPoints`	No	Five talking points for the conversation.
`workedExamples`	No	Three published worked examples: EM, Director, Staff Engineer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026

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

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

AddedSep 3, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses that the return is a full menu keyed by tool name and that the first call is meant to route the next one. It does not address potential overlap with the sibling get_more_tools, which is a modest gap.

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

Conciseness5/5

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

Two sentences, each earning its place: the first enumerates triggers, the second explains the payload and its routing purpose. Front-loaded with the concrete invocation cases and free of padding.

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 the description needn't detail return values, and it still briefly characterizes the response as a question-to-tool menu. For a zero-required-parameter router tool, nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and the single 'context' parameter is already documented in the schema as optional intent that never changes the answer. The description doesn't add syntax or format meaning beyond what the schema provides, so baseline 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 concrete verb+resource: it handles greetings, liveness checks, and general/unmatched messages, and returns a menu of questions mapped to tool names. This clearly distinguishes it from the task-specific siblings like get_one_on_one_playbook or calculate_developer_value, which it implicitly routes to.

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 explicit trigger conditions ('hi, hello', connectivity test, 'what can you do', messages too general to match a specific tool) and states the routing role — call this so the next call goes straight to the right tool. That is a clear when-to-use rule that an agent can act on directly.

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

All eng-leadership-toolkit tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.