Skip to main content
Glama

Applicants for the employer's jobs

list_applicants
Read-onlyIdempotent

Applicants for the employer's jobs. Scored by one fixed formula for everyone (skills 45, role 20, experience 15, education 10, place 10), with strengths and gaps. It rates fit with the advert, never the person; people decide. A ready-to-read summary is in say.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort: score (default) or newest.
stageNo
post_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world safety. The description adds substantial behavioral context beyond that: the exact scoring formula with weights, the presence of strengths and gaps, an ethical stance ("rates fit with the advert, never the person"), and the existence of a ready-to-read `say` summary. It lacks pagination or rate-limit details, so not a 5.

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?

The description is concise, with the purpose front-loaded and no filler. The ethical note and output field mention are relevant. It could be slightly better structured by omitting the redundant title restatement.

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?

For a listing tool with three optional parameters, no output schema, and low schema coverage, the description is incomplete. It explains scoring and a summary field but omits parameter meanings, default filtering behavior, and the structure of the returned list.

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

Parameters1/5

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

Schema coverage is only 33% — only `sort` has a description, while `stage` and `post_id` are undocumented. The description adds no parameter information at all, failing to compensate for the low schema coverage.

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?

The description restates the title ("Applicants for the employer's jobs") and then details scoring, but never states a verb like "list". The name provides the verb, but the description itself does not clearly distinguish this listing tool from siblings like get_applicant or list_applications. It is minimally adequate but vague.

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 explicit guidance on when to use this tool versus alternatives such as get_applicant or search_candidates. The only usage-adjacent sentence is about the output summary (`say`), which does not help selection.

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.