Skip to main content
Glama

tpool 招聘数据 MCP

tpool_search_announcements

搜索校招/国央企招聘公告(来源含国企肩标平台等,每日更新)。免 key。

Args:
    keyword: 关键词,如「国家电网」「银行」「秋招」
    city:    城市过滤;留空=全部
    recruit_type: 类型过滤(可选值先用 tpool_announcement_filters 查,如 校招/实习/社招)
    sort:    排序:deadline(默认,截稿在前)/ created_at / popularity
    page:    页码,从 1 起
    page_size: 每页条数,默认 15

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
pageNo
sortNodeadline
keywordNo
page_sizeNo
recruit_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/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 burden. It discloses useful traits — no API key required and a daily-refreshed source — but says nothing about rate limits, pagination limits, or result ordering behavior beyond the sort parameter definition.

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 purpose sentence is front-loaded, followed by a clean Args block with one line per parameter. Every line carries information; no padding or repetition.

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?

For a six-parameter, no-annotation, no-output-schema search tool, the definition covers purpose, prerequisites, and all parameters well. The main remaining gap is the shape of the response (result fields, page/metadata), which is not described anywhere.

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 description coverage is 0%, so the description must compensate, and it largely does: it documents all six parameters with examples (「国家电网」,「银行」,「秋招」), defaults (page 1, page_size 15), the sort enum values (deadline/created_at/popularity), and points to the filters tool for recruit_type values. It does not clarify that all parameters are optional.

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 and resource (搜索/搜索校招·国央企招聘公告) and adds scope details: source coverage (国企肩标平台等), daily updates, and no-key access. It implicitly separates itself from tpool_search_jobs by naming the resource as announcements, but never explicitly distinguishes the two.

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

Usage Guidelines4/5

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

It gives clear context (no key required, daily-updated source) and routes the agent to a sibling for a needed prerequisite: recruit_type values must be fetched via tpool_announcement_filters first. It offers no explicit when-not-to-use guidance versus tpool_search_jobs.

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.

Resources