Skip to main content
Glama

Jobiba Hiring: Post Jobs, Screen Applicants & Source Talent

Screen applicants with AI

screen_applicants
Read-onlyIdempotent

Rank a job's active applicants by evidence-based fit (skills, experience, recency, logistics) with reasons, gaps and a shortlist/review/hold recommendation. Read-only: nobody is moved or emailed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "jobId": "<jobId>"
    },
    "name": "screen_applicants"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobIdYesJobiba job ID (the id field from search_jobs or list_my_jobs).
limitNoMax 50.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered; the description nonetheless adds concrete reassurance that nobody is moved or emailed, i.e. no applicant status mutation or messaging side effect. It also discloses the shape of the returned judgment (reasons, gaps, recommendation buckets), which is valuable given there is no output schema. It omits any note on cost, latency, or how many applicants the AI actually evaluates.

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?

Two tight sentences: the ranking behavior and its evidence dimensions come first, the no-side-effect guarantee second. Every clause carries information and nothing is redundant padding.

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 usefully characterizes what comes back (per-applicant reasons, gaps, and a recommendation category) plus the read-only guarantee. What is missing is scope information such as whether all active applicants are screened or how the limit interacts with ranking, and any indication of processing cost.

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% for both parameters, including the source of jobId (search_jobs or list_my_jobs) and the limit bounds, so the schema carries the parameter meaning. The description adds nothing parameter-specific, which is acceptable at full coverage but earns only the baseline.

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?

States a specific verb and resource ('Rank a job's active applicants') and names the scoring dimensions and output form (reasons, gaps, shortlist/review/hold). It is clearly a screening/ranking operation rather than a raw listing, but it never names siblings like list_applicants or compare_candidates to draw the boundary explicitly.

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 when-to-use guidance, no prerequisites, and no named alternative. The agent can infer that this is for evaluating applicants on a job, but the description does not say when to prefer it over list_applicants or compare_candidates, nor when it would be inappropriate.

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.