Skip to main content
Glama

boss_shortlist_remove

Removes a job from the candidate shortlist in BOSS Zhipin using its security ID and job ID, keeping the candidate pool current.

Instructions

从候选池移除职位 [可用性: roles=candidate; candidate_platforms=zhipin; recruiter_platforms=-]

Input Schema

NameRequiredDescriptionDefault
job_idYes加密职位 ID
security_idYes职位安全 ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.1
  2. Removedv1.18.0
  3. Addedv1.17.0
  4. Removedv1.16.0
  5. First observedv1.11.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden. It says the job is removed but not whether removal is reversible, whether it errors when the job is absent from the pool, or what permissions are needed. The availability constraint is useful but does not cover the mutation's behavioral profile.

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?

A single front-loaded sentence with the operation stated first and the availability qualifier bracketed afterwards. No wasted wording, though the bracketed metadata is terse to the point of needing decoding.

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 destructive mutation tool with no annotations and no output schema, the description should disclose at minimum reversibility and the effect of removing a job that is not in the pool. Combined with zero return-value information, this leaves meaningful gaps.

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% — both job_id (加密职位 ID) and security_id (职位安全 ID) are documented in the schema. The description adds no meaning about how these IDs are obtained or how they relate, so baseline 3 applies.

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?

The description states a specific verb+resource pair: removing a job from the candidate shortlist pool (从候选池移除职位). This clearly contrasts with the sibling boss_shortlist_add, though it does not name that sibling explicitly.

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

Usage Guidelines3/5

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

The bracketed availability clause gives real usage context — only valid for roles=candidate, on the zhipin candidate platform, and not for recruiter platforms — which implies when the tool applies. However, it offers no explicit when-not guidance or pointer to alternatives such as boss_shortlist_list or boss_shortlist_annotate.

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