Skip to main content
Glama
EQIQs

@eqiqs/mcp-server

Official
by EQIQs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Suggest who should lead

suggest_lead
Read-onlyIdempotent

Rank 2-12 people by fit for leading execution, people, innovation, or analysis work. Use saved results to answer 'Who should lead this project?' Decision-support only.

Instructions

Rank 2-12 people for leading a kind of work (execution, people, innovation or analysis), showing the saved results behind each ranking and any thin data. Use for 'who should lead this project?'. Decision-support only. Read-only; costs 2 units.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.1
    • 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
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only' and 'Decision-support only'. It adds valuable context beyond annotations: the 2-unit cost, the fact that saved results are shown behind rankings, and that thin data is surfaced.

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?

The description is short, front-loaded with the core action, and every sentence earns its place. It packs the action, output behavior, usage trigger, decision-support caveat, and cost into three compact sentences with no fluff.

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?

With no output schema, the description gives enough about the return content: rankings, saved results, and thin data. Together with a fully described input schema and annotations covering safety, the tool is callable without significant guesswork. A slight gap is that 'thin data' is not defined further, but it does not block correct invocation.

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 kind, members, project, and department. The description lightly re-expresses the 2-12 member limit and the leadership kinds, but it adds little parameter 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.

Purpose5/5

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

The description opens with a specific verb and object: 'Rank 2-12 people for leading a kind of work'. It also names the four leadership kinds and the output contents, so an agent can clearly identify the tool's function. This clearly differentiates it from siblings like score_team by emphasizing ranking individuals for a leadership role.

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

Usage Guidelines4/5

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

The explicit line 'Use for "who should lead this project?"' gives a clear trigger phrase for when to call this tool. It does not mention alternatives or exclusions, but the use-case phrasing is strong enough for routing in most contexts.

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

Deploy Server

Other Tools