Skip to main content
Glama

boss_me

Retrieve the logged-in user's profile data from BOSS Zhipin, including basic info, resume, job expectations, and application records by section.

Instructions

获取当前登录用户信息(基本信息、简历、求职期望、投递记录) [可用性: 可用性: roles=candidate; candidate_platforms=zhipin; recruiter_platforms=-]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sectionNo指定查看的部分

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.1
  2. Removedv1.18.0
  3. First observedv1.11.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. The verb 获取 (get) implies a safe read, and it lists the categories of data returned, but it does not state auth/permission requirements, rate limits, or any mutation-related caveats.

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?

Single front-loaded sentence naming the resource followed by a compact field list and a bracketed constraint tag. No wasted prose, though the doubled '可用性: 可用性:' is a minor structural blemish.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool this is roughly adequate: the sections and the role gating are covered. But with no annotations and no output schema, it stops short of stating read-only semantics or auth requirements an agent might want.

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

Parameters4/5

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

Schema coverage is 100% with a single enum parameter, so baseline is 3. The description earns more by mapping the enum values to concrete Chinese labels (基本信息=info, 简历=resume, 求职期望=expect, 投递记录=deliver), clarifying what each section actually returns beyond the bare enum.

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 (获取/get) and a precise resource (当前登录用户信息 - current logged-in user's info), then enumerates the sub-resources it returns (基本信息、简历、求职期望、投递记录). An agent can tell what it retrieves, though it does not explicitly name which sibling to prefer over it.

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 tag gives role gating (roles=candidate, recruiter_platforms=-), which implies when this tool is and isn't applicable. However there is no prose guidance and no named alternatives among the many boss_* siblings, so the routing signal is indirect.

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