Skip to main content
Glama

aiworkhub_manager_workforce_rank

Read-only

MANAGER READ: explainable cheapest-capable routing from current evidence.

Instructions

MANAGER READ: explainable cheapest-capable routing from current evidence.

detail="summary" (default) keeps every top-level selection field (selected_*, economic_advisory, etc.) exact; the selected compatible candidate and the next two keep their full row, every other compatible candidate is reduced to worker_id/adapter_id/model/score; excluded candidates are reduced to a count per exclusion reason plus the first 10 as worker_id/adapter_id/model. detail="evidence" behaves like "full": both return today's payload exactly.

Input Schema

NameRequiredDescriptionDefault
riskNomedium
kindsYes
detailNosummary
task_idYes
tool_needsNo
quality_floorNo
context_tokensNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered, and the description adds real behavioral value: it specifies that summary keeps top-level selection fields exact, retains full rows for the selected candidate plus the next two, truncates remaining compatible candidates to id fields, and collapses excluded candidates into per-reason counts plus the first 10. That truncation behavior is exactly the kind of thing an agent needs to know before trusting the payload. It stops short of explaining what "current evidence" means or whether the ranking is advisory only.

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

Conciseness3/5

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

The one-line purpose is properly front-loaded, but the remaining paragraph is a dense, hard-to-parse run-on that spends its entire budget on a single parameter while omitting the six that actually gate the call. The clause describing `detail="evidence"` ("behaves like `full`: both return today's payload exactly") is ambiguous about what "today's payload" refers to. Not bloated, but misallocated.

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

Completeness2/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 re-explained — yet most of the description is spent on return-shape detail, leaving the input contract unexplained. Missing prerequisites (does the task need existing evidence?), the meaning of the required `task_id`/`kinds`, and whether the result is advisory or authoritative. For a 7-parameter routing tool this is under-specified.

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

Parameters2/5

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and it largely does not. It documents only the `detail` parameter's output shape, while `task_id`, `kinds`, `risk`, `tool_needs`, `quality_floor`, and `context_tokens` are never mentioned — the agent gets no guidance on what a "kind", a risk level, or a quality floor means here. One of seven params covered is well below what a zero-coverage schema demands.

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

Purpose3/5

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

"MANAGER READ: explainable cheapest-capable routing from current evidence" conveys that the tool produces a ranked/routing recommendation, but it does so in dense internal jargon rather than naming the resource plainly (e.g., "rank worker candidates for a task"). It never explicitly contrasts with the sibling aiworkhub_manager_workforce_catalog, so the agent has to infer the boundary. The sentence is closer to vague-but-directional than to a crisp verb+object statement.

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

Usage Guidelines2/5

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

There is no when-to-use statement: nothing says to call this before launching a task, after evidence changes, or instead of the workforce catalog. The only choice offered is which detail level to request, which is a response-shaping decision rather than a routing decision. An agent cannot determine from this text when this tool is the right one.

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