我的今日全景
get_my_brief【需要登录】未读/7日访客/开聊额度/未报场次/阶段事项/待审/未归位链位/待回合作。degraded=null非0;定位可排队LLM写回,7日新鲜/10分钟/证据去重,勿无目的轮询,手选阶段优先,经营与融资独立。完整定位get_my_positioning,工作get_my_work;勿后台读会标已看的get_my_dispatch。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
get_my_brief【需要登录】未读/7日访客/开聊额度/未报场次/阶段事项/待审/未归位链位/待回合作。degraded=null非0;定位可排队LLM写回,7日新鲜/10分钟/证据去重,勿无目的轮询,手选阶段优先,经营与融资独立。完整定位get_my_positioning,工作get_my_work;勿后台读会标已看的get_my_dispatch。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: 'degraded=null非0' indicates a degraded state field and that null should be treated as non-zero, '定位可排队LLM写回' suggests positioning can be queued for LLM write-back, and '7日新鲜/10分钟/证据去重' gives freshness and deduplication constraints, plus '勿无目的轮询' warns about polling. These are useful behavioral traits not in annotations. However, it does not explain why readOnlyHint is false for a read tool (possibly because it triggers LLM write-back or updates state), leaving a gap given the non-readOnly annotation. Overall, it adds value but is terse and leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but dense and somewhat cryptic due to shorthand and Chinese-only text. It is not front-loaded with a clear purpose; instead it begins with '【需要登录】' (requires login) then a list of data categories. Every sentence may earn its place, but the structure is not ideal for quick comprehension. It could be improved with a clearer opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and annotations provided, the description needs to convey what the tool returns and when to use it. It lists many data categories, which helps, but does not explain the output format or structure. It references other tools for alternatives, which is good. However, it lacks a complete picture: for instance, what does 'degraded=null非0' mean in practice? The agent is left to infer. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it doesn't. No penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the data categories returned (unread, 7-day visitors, chat quota, unreported sessions, stage items, pending review, unpositioned chain slots, pending cooperation) but never states a clear verb+resource like 'retrieve your daily dashboard overview'. A list of content domains is not a purpose statement; the agent must infer that this is a personalized daily summary. Sibling tools like get_my_positioning and get_my_work are referenced, providing some differentiation, but purpose remains implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does provide routing guidance: '完整定位get_my_positioning,工作get_my_work' (full positioning goes to get_my_positioning, work to get_my_work) and '勿后台读会标已看的get_my_dispatch' (don't use get_my_dispatch in background as it marks as read). It also says '勿无目的轮询' (don't poll without purpose). This gives explicit exclusions and alternatives for some siblings. However, it does not state when to call THIS tool versus, say, list_recent_attention or get_my_card, so usage guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.