Skip to main content
Glama

Suggest who should lead

suggest_lead
Read-onlyIdempotent

Discuss leadership considerations for 2-12 people and voluntary work (execution, people, innovation or analysis), showing available results and gaps without ranking people. Decision-support only. Read-only; costs 1 unit.

Input Schema

NameRequiredDescriptionDefault
kindNoKind of leadership the work needs.execution
membersNoProfile ids or full names of the people in the group (2-12). Omit when using department.
projectNoOptional project description echoed in the ranking.
departmentNoUse everyone tagged with this department instead of naming members. Exact match first; refuses and asks for names if more than 12 people match or the name spans several departments.

Output Schema

NameRequiredDescriptionDefault
kindNoType of work being led.
considerationsNoPeople to consider and why (not a ranking).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "considerations": {
      +      "description": "People to consider and why (not a ranking).",
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "kind": {
      +      "description": "Type of work being led.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed9 schema fields changed
    • addedInput schema / properties / department / description
      Added value: +"Use everyone tagged with this department instead of naming members. Exact match first; refuses and asks for names if more than 12 people match or the name spans several departments."
    • addedInput schema / properties / department / maxLength
      Added value: +100
    • addedInput schema / properties / kind / default
      Added value: +"execution"
    • addedInput schema / properties / kind / description
      Added value: +"Kind of leadership the work needs."
    • addedInput schema / properties / members / description
      Added value: +"Profile ids or full names of the people in the group (2-12). Omit when using department."
    • addedInput schema / properties / members / maxItems
      Added value: +12
    • addedInput schema / properties / members / minItems
      Added value: +2
    • addedInput schema / properties / project / description
      Added value: +"Optional project description echoed in the ranking."
    • addedInput schema / properties / project / maxLength
      Added value: +300
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world traits. The description adds useful non-annotation context: it costs 1 unit, is decision-support only, and notably does not rank people — an important behavioral trait for a tool named suggest_lead.

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?

Three short sentences with no wasted words. The core scope and the key non-ranking constraint are front-loaded, though the first sentence is somewhat dense.

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

Completeness4/5

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

An output schema already explains return values, and annotations cover safety. The description adds cost, decision-support framing, and the non-ranking behavior, leaving little missing for an agent to invoke it correctly.

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 all four parameters thoroughly. The description restates the 2-12 member limit and the four work kinds, adding minimal meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: discussing leadership considerations for a group of 2-12 people, with optional voluntary work kinds, and explicitly notes it does not rank people. This distinguishes it from scoring siblings like score_team or score_compatibility, though no sibling is named.

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

Usage Guidelines3/5

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

It says 'Decision-support only' and implies the tool is for exploring leadership considerations rather than making final decisions, but it never explicitly states when to use this tool versus alternatives such as score_team or score_compatibility. Usage is implied rather than directed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources