Skip to main content
Glama
Ahellowyy

鱼泡求职 MCP

by Ahellowyy

yupao_prepare_message

Preview a message draft before sending it for a job on Yupao. Verifies the conversation link for existing chats, or previews a free first contact when start_conversation is true, without sending.

Instructions

预览单条消息;已有会话须核验关联,start_conversation=true 可预览免费首次开聊。准备阶段不发送。

Input Schema

NameRequiredDescriptionDefault
textYes
job_biz_idYes
conversation_idNo
start_conversationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already establish destructiveHint=false and openWorldHint=true, so the bar is lower, and the description usefully adds that nothing is sent at this stage plus a constraint about verifying association for existing threads. It omits what is persisted or returned by the preparation step, and "预览" sits in mild tension with readOnlyHint=false if it does create a prepared record.

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?

Two compact clauses with the core action front-loaded and zero filler. Brevity shades into obscurity in spots, since "须核验关联" is terse to the point of being unclear, but nothing is wasted.

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?

This is a non-read-only tool with no output schema and four undocumented parameters, so the description carries the full burden — yet it never says what the preparation returns (an id? previewed content?) that the agent would need in order to execute it later. For a two-stage prepare/execute flow, that is a substantial gap.

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

Parameters2/5

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

Schema description coverage is 0% — all four parameters carry only titles — so the description must compensate and largely does not. It does explain start_conversation's meaning (free first chat) and gestures at conversation_id via the association-verification clause, but job_biz_id (where it comes from) and text are undocumented anywhere.

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 ("预览单条消息" — preview a single message) and removes the biggest ambiguity by declaring "准备阶段不发送" (preparation does not send). It does not differentiate itself from siblings such as yupao_execute_action, which presumably consumes the prepared message, so an agent cannot fully route between them from this text alone.

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?

Gives conditional guidance for two cases: existing conversations require association verification, and start_conversation=true covers the free first-time chat. However it never names an alternative tool or says when NOT to use this one, and the path from preview to actually sending (yupao_execute_action) is left implicit.

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