Engineering leadership benchmarks, 1:1 playbooks, developer value calculator. 3,400+ sessions.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 9 of 9 tools scored.
Each tool targets a specific leadership scenario: self-assessment, business case, salary calculation, mentor type selection, cost estimation, benchmarks, first-time manager guidance, and one-on-one scripts. No overlap in purposes, making it easy for an agent to choose correctly.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., choose_mentor_coach_or_advisor, get_first_time_manager_guidance). The verbs are diverse but the structure is uniform, aiding predictability.
Nine tools cover the essential aspects of an engineering leadership toolkit without being excessive. Each tool fills a distinct need, and the count is well-scoped for the domain.
The toolkit covers core areas like readiness assessment, business case, salary benchmarks, mentoring guidance, and 1:1 scripts. Minor gaps exist (e.g., conflict resolution, advanced strategy), but the major workflows are supported.
assess_team_lead_readinessTeam lead readiness test — should this engineer become a team lead?AAnswers "should I become a team lead?" with the same 17-question test as the live tool at marian.coach: 6 dimensions (people appetite, letting go of code, ownership beyond your tickets, translation & saying no, motivation, org reality), a straight verdict — ready now / 6-12 months out / stay IC (and that's fine) — plus the top-2 gap dimensions with one concrete move each. Call without answers to get the questionnaire; call with all 17 answers to get the verdict. Built from 3,400+ mentoring sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | Answers keyed by question id (q1-q17), each the 0-based index of the chosen option for that question (NOT a rating — option scores are calibrated and non-monotonic). Omit to receive the 17 questions with their options first. |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, etc.) are consistent and the description adds valuable behavioral context: built from 3,400+ mentoring sessions, non-monotonic scoring, and the structure of the output. No contradictions.
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?
Description is single, well-structured paragraph that front-loads the core function and uses efficient language without waste.
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 complexity, existing output schema, and annotations, the description completely covers purpose, usage modes, and output format. No gaps remain.
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%. The description adds meaning beyond the schema by noting that answers are indices and that scores are calibrated non-monotonically, preventing misuse.
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: answering 'should I become a team lead?' using a 17-question test, providing a verdict and top gap dimensions. It distinguishes itself from sibling tools by specifying it's a specific test from marian.coach.
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 usage guidance: call without answers to get the questionnaire, call with all 17 answers to get the verdict. Does not explicitly state when not to use, but sibling tools cover different scenarios, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_mentoring_business_caseMentoring business case & manager email builderABuild the business case to get your company to pay for leadership mentoring or coaching: computes the ROI in EUR (money saved + cost of delay avoided + missed opportunity + roadmap slippage avoided), suggests 3-6 month KPIs, and drafts a forwardable approval email for your manager. Based on 3,400+ mentoring sessions at marian.coach.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | The mentee's role — sets the suggested KPIs | |
| problem | No | The one problem to fix, e.g. "delivery predictability at 60%" | |
| team_size | No | Number of engineers in the team/org affected | |
| avg_salary_eur | No | Average fully-loaded annual cost per engineer in EUR (default 100000) | |
| at_risk_attrition | No | Senior people with a foot out the door (default 0) | |
| delayed_revenue_eur | No | Annual revenue attached to a slipping roadmap item, in EUR (default 0) |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral detail by listing computed components (money saved, cost of delay avoided, etc.) and sources (3,400+ sessions), which is consistent with read-only behavior. No contradictions.
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 a single sentence that front-loads the main purpose and outputs. It is efficient but slightly dense; could be split into two sentences for readability. No wasted words.
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 6 parameters with full schema coverage, present annotations, and an output schema, the description adequately explains what the tool does. It covers the primary use case and key outputs, though it does not describe return value structure.
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 input schema already explains all 6 parameters. The description mentions role-based KPIs and ROI components but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a business case, computes ROI, suggests KPIs, and drafts an email. It uses specific verbs (build, computes, suggests, drafts) and identifies the resource (mentoring business case). It distinguishes from siblings like calculate_developer_value or get_first_time_manager_guidance by focusing on justification for mentoring/coaching.
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 implies usage when needing to justify mentoring or coaching costs, but does not explicitly state when to use this tool versus alternatives such as estimate_coaching_cost or choose_mentor_coach_or_advisor. No 'use this when' or 'instead of' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_developer_valueDeveloper value & salary calculatorAAssess a software developer's market value: score 15 skills across 5 pillars (core craft, systems & judgment, impact & ownership, collaboration & influence, AI leverage), get a weighted total score, seniority level, and a 2026 Western-Europe gross salary estimate. Same logic as the live calculator at marian.coach. Unscored skills default to the level's baseline.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | The developer's current (or claimed) level — sets pillar weights and baseline | |
| scores | No | Optional 0-10 score per skill. Valid keys: discipline-mastery, code-quality, debugging, system-design, tech-decisions, data-performance, shipping-outcomes, production-ownership, domain-expertise, communication, mentoring, cross-functional, ai-output, ai-quality, ai-workflows. Omitted skills use the level baseline (junior 3, mid 5, senior 6, staff 7). |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and idempotent, which the description supports. The description adds transparency by explaining default scoring for unprovided skills and referencing the live calculator, providing extra behavioral context beyond 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 short (2 sentences plus a note) and front-loaded with the main action. While concise, it could be more structured (e.g., bullets) to improve scanability, but it's not verbose.
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 complexity (15 skills, 5 pillars, multiple outputs) and the presence of an output schema (not shown but assumed), the description covers key elements: inputs, default behavior, and outputs (score, seniority, salary). It mentions the region and year for salary, which is specific enough.
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%: both parameters are well-described with enums and key lists. The description adds a high-level overview of the 5 pillars and 15 skills, but this largely parrots the schema's detail. Baseline at 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 calculates a developer's market value by scoring 15 skills across 5 pillars, producing a weighted total score, seniority level, and salary estimate. It distinguishes itself from sibling tools (e.g., calculate_engineering_manager_value) by focusing on individual developers.
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?
No explicit guidance on when to use this tool versus alternatives. Sibling tools include other assessment tools (e.g., assess_team_lead_readiness, calculate_engineering_manager_value), but the description does not advise on selection criteria or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_engineering_manager_valueEngineering manager value & salary calculatorAAssess an engineering leader's market value: score 15 leadership skills across 5 pillars (people & talent, delivery & execution, technical direction, stakeholder influence, AI leverage), weighted by current level, get a total score, a level from Team Lead to Director/VP of Engineering, and a 2026 Western-Europe gross salary estimate. Same logic as the live EM salary calculator at marian.coach. Unscored skills default to the level's baseline.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | The leader's current (or claimed) level — sets pillar weights and baseline (team-lead, em, senior-em, director) | |
| track | No | Optional context: what kind of teams they lead. Framing only — scoring is weighted by level, identically across tracks (same as the live tool) | |
| scores | No | Optional 0-10 score per skill. Valid keys: hiring, coaching, performance, predictable-delivery, quality-ops, process-fit, architecture-judgment, tech-strategy, build-vs-buy, product-partnership, managing-upward, org-influence, ai-team-workflows, ai-product, ai-impact. Omitted skills use the level baseline (team-lead 3, em 5, senior-em 6, director 7). |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description's main contribution is detailing the scoring logic: 15 skills across 5 pillars, weighted by level, with default baselines for unscored skills. It also references the live calculator for consistency. This adds useful behavior context without contradiction.
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 with a clear function: core purpose and outcome, external reference, and default behavior. No superfluous words, and the most important information (what it does) appears first.
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 existence of an output schema (not shown but indicated), the description sufficiently covers inputs, process, and outputs. It mentions the salary region (Western Europe) and default logic. Some minor details (exact output level names) are omitted, but overall it supports effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining the three parameters' roles: level sets weights and baseline, track is 'framing only' with identical scoring, scores object maps to 15 specific skills. This contextualizes the parameters beyond their raw schema descriptions.
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: 'Assess an engineering leader's market value' by scoring skills, computing a level and salary estimate. The verb 'assess' and resource 'market value' are specific. It distinguishes from siblings like 'assess_team_lead_readiness' and 'calculate_developer_value' by focusing on value and salary, making its unique role evident.
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 explains when to use the tool: to get a salary estimate and level based on leadership skills. It provides context (e.g., '2026 Western-Europe gross salary estimate') but does not explicitly mention when not to use it or suggest alternatives. However, sibling tool names imply clear boundaries, so the guidance is adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
choose_mentor_coach_or_advisorMentor vs coach vs advisor — which one do you need?ADecide whether an engineering leader needs a mentor, a coach, or an advisor: what each brings, the typical question each answers, whether domain experience is required, time horizon, and a three-question self-test. Based on 3,400+ mentoring sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| situation | No | Optional: the leader's situation in one sentence — the three-question test below maps it to a recommendation |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds context about decision criteria and basis in 3,400+ sessions without contradicting 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?
Single sentence packs multiple details without wasted words, though list formatting could improve scanability.
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?
Covers all relevant aspects: what each role brings, typical question, domain experience, time horizon, self-test, and basis in experience. Output schema likely provides recommendation.
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 parameter description. The tool description adds context about the three-question test but does not significantly extend semantic meaning.
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?
Description clearly states the tool decides between mentor, coach, or advisor for engineering leaders, listing what each brings and a self-test. Sibling tools have no direct overlap.
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?
Describes when to use the tool (deciding type of support) but does not explicitly state exclusions. Context is clear based on sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_coaching_costCoaching cost estimator — what should a coach cost?AFair market rate for coaching or mentoring in 2026, by coaching type, client role, coach territory, coach seniority, and engagement length. Returns a per-session range, program total, and red flags (too cheap / brand margin). Anchored to ICF Global Coaching Study 2025, Tandem Coach 2026 credential bands, and CEE market survey data. Same logic as the live calculator at marian.coach.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Engagement length (default single-session) — longer commitments carry a 5-20% per-session discount | |
| territory | Yes | Where the coach operates — CEE runs at roughly half of US rates | |
| client_role | Yes | The client's role — the same coach charges a VP more than an EM | |
| coaching_type | Yes | What kind of coaching the client is buying | |
| coach_seniority | Yes | Coach seniority band: certified (ICF ACC level), experienced (PCC, 10+ yrs), top-tier (MCC / C-suite), practitioner-mentor (has held the client's role) |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, idempotent, non-destructive. Description adds return structure (range, total, red flags) and anchoring data sources (ICF study, Tandem bands, CEE survey). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers inputs and outputs, second adds credibility and source link. No filler or redundancy.
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 5 well-described params, output schema, and thorough annotations, the description completes the picture with return format, data sources, and a real-world reference (marian.coach calculator). Agent has all needed context.
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 per-parameter descriptions. Description adds contextual insights (e.g., longer commitments give 5-20% discount, CEE runs half of US rates) that enrich understanding beyond schema alone.
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?
Clearly states 'estimate coaching cost' with specific inputs (coaching type, client role, territory, coach seniority, engagement length) and outputs (per-session range, program total, red flags). Distinct from siblings whose names indicate different functions (e.g., assess readiness, build business case).
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?
Implicitly defines use case: when market rate for coaching or mentoring is needed. No explicit when-not-to-use or alternatives, but sibling diversity makes context clear. Could strengthen by contrasting with non-cost tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_engineering_leadership_benchmarksEngineering leadership benchmarks & mentoring statisticsAReal benchmarks from 3,400+ paid 1:1 mentoring sessions with 300+ engineering leaders since 2019: mentee seniority mix, most-demanded leadership topics of 2025, time-to-results, team-health delivery thresholds (sprint completion, roadmap %, manager time per report), and practice outcome stats (NPS, referral rate). First-party data, CC BY 4.0 — citable.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Which benchmark set to return (default: all) |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (read-only, idempotent). The description adds value by disclosing the data source, scope, and licensing (CC BY 4.0, citable), which are non-obvious behavioral traits.
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?
A single well-structured sentence that efficiently conveys key information without wasted words, front-loading the core purpose.
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 simplicity of the tool (1 param, read-only, output schema exists), the description is complete, covering data source, scope, and licensing.
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 enum descriptions, so baseline is 3. The description adds context about the benchmark contents, aiding understanding of what each topic returns, though not mapping exactly to enum values.
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 returns real benchmarks from mentoring sessions and lists specific categories. It distinguishes itself from sibling tools which focus on assessments, business cases, or guidance.
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 purpose is clear but there is no explicit guidance on when to use this tool versus alternatives. The context of sibling tools implies usage for benchmark data, but no exclusions or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_first_time_manager_guidanceFirst-time engineering manager readiness & failure modesAGuidance for the IC→manager transition: the EM responsibility triangle (leadership/processes/delivery — pick two), the six most common first-time-manager failure modes, readiness self-check questions, and what the first months should look like. 52% of Marian's 300+ mentees arrive exactly at this transition.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
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 description does not need to cover safety. It adds context about content (failure modes, readiness questions) but does not disclose any additional behavioral traits beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently conveying the tool's purpose, content, and relevance. Every sentence adds value, with no wasted words.
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 zero parameters and the presence of an output schema, the description fully explains what the tool provides: specific guidance topics and a statistic about mentees. No gaps remain.
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 tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter semantics; baseline is 4 and the description fully compensates by explaining the tool's purpose and output.
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 it provides guidance for the IC→manager transition, listing specific topics like the EM responsibility triangle, failure modes, and readiness checks. It distinguishes from sibling tools like assess_team_lead_readiness and get_one_on_one_playbook by focusing on first-time managers.
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 implies usage when someone is in the IC→manager transition, but does not explicitly state when to use this tool versus alternatives like assess_team_lead_readiness. No exclusions or when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_one_on_one_playbook1:1 playbooks for engineering managersASituation-specific 1:1 scripts and templates from Marian Kamenistak's mentoring practice: first mentoring/direction-setting session, underperformance conversation, promoting a developer to manager, fixing status-update 1:1s, and the 10-question career-move checklist. These are the actual templates used across 3,400+ sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| situation | Yes | Which situation: first-session (direction-setting template), underperformance (difficult conversation script), promotion-to-manager (timing signals + transition contract), better-one-on-ones (from status updates to growth), career-move (should-I-leave checklist) |
| Name | Required | Description |
|---|---|---|
| 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. |
| salaryEur | No | Estimated 2026 Western-Europe gross annual salary in EUR. |
| totalScore | No | Weighted 0-10 score, when the tool computes one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds credibility ('actual templates used across 3,400+ sessions') but does not further disclose behavioral traits like return format or limitation. The annotations carry the main burden, so 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence lists all five situations concisely, and the second adds credibility and scope. Front-loaded with purpose.
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 retrieval tool with 1 parameter, 100% schema coverage, and an output schema, the description covers the needed context: what the tool provides (scripts/templates), for whom (engineering managers), source (Marian Kamenistak), and all situations listed. No gaps.
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 each enum value in the 'situation' property. The tool description provides overall context but does not add significant meaning beyond what the schema already provides for the single required parameter. Baseline 3 is correct.
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 it provides 'situation-specific 1:1 scripts and templates' for five named scenarios, using specific verbs ('get', 'scripts and templates'). It distinguishes from siblings by specifying the content source and use cases, such as 'underperformance conversation' and 'career-move checklist'.
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 implies when to use each situation (e.g., first mentoring session, underperformance) and is targeted at engineering managers. However, it does not explicitly state when not to use this tool or mention alternative tools from the sibling list, such as 'assess_team_lead_readiness' for leadership readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.
