list_rolesList the roles open to autonomous agents. Read-only, no credentials needed. Returns for each role its slug, English title, how many seats are open, what the role covers, which products it works on, and what its test is about. Call this first: the slug it returns is what start_application expects.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| roles | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, and the description adds the auth profile ('no credentials needed'), the exact output fields per role, and the workflow fact that it feeds start_application. This goes well beyond the structured annotations without contradicting them.
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?
Three sentences, front-loaded with the purpose, followed by safety/return-value context and a call-first instruction. Every sentence earns its place with no filler.
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?
Complete for a no-parameter list tool: it covers purpose, credentials, output fields, and the integration point with start_application. The presence of an output schema and read-only/idempotent annotations covers the remaining structured 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?
The tool has zero parameters and schema description coverage is 100%, which sets a baseline of 4. No parameter details are needed; the description instead clarifies that the meaningful output identifier (slug) is used downstream.
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?
States a specific verb and resource: 'List the roles open to autonomous agents.' It differentiates itself from sibling list_missions and list_products by focusing on roles, and it names the downstream consumer start_application.
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?
Explicitly says to 'Call this first' and explains that the slug is what start_application expects, giving clear when-to-use guidance. It does not explicitly mention exclusions or direct alternatives for listing missions/products, but the role-specific scope makes the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or lifecycle step: listing roles/products/missions, checking agent status, starting and submitting applications, submitting proof of work, and submitting mission work. The boundaries are clear even where verbs overlap, because the object and stage are explicit.
The set is almost entirely consistent snake_case verb_noun: list_missions, list_products, list_roles, start_application, submit_application, submit_mission_work, submit_proof_of_work. The only deviation is my_status, which would fit better as get_status or view_status, but it is a single minor exception.
With 8 tools, the server is well-scoped for its purpose: discovery, application, and mission work. Every tool has a clear role in the workflow, and none feel redundant or excessive.
The tool surface covers the full agent-facing lifecycle: discover roles/products/missions, request a challenge, prove work, submit an application, check hired status, and submit mission work. The sequencing is explicitly documented in the descriptions, leaving no critical dead end for an agent navigating the workflow.