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

Beyond the idempotent/non-destructive annotations, it discloses real runtime traits: a 'degraded' field that is null vs non-zero, positioning writes that can be queued for LLM writeback, 7-day freshness / 10-minute windows, evidence deduplication, and a side-effect contrast with get_my_dispatch. The poll warning is exactly the kind of behavioral advice annotations cannot carry. The phrasing is so compressed ('degraded=null非0') that the exact meaning of degraded remains ambiguous.

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?

It is short, but it is packed into two semicolon-delimited run-on fragments with no front-loaded purpose sentence and heavy domain jargon, so density comes at the cost of parseability. Several clauses (degraded semantics, writeback queue, freshness windows) are not ordered by importance.

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?

There is no output schema, so the description carries the burden of describing return values — it lists the buckets but never explains their shape, units, or how the degraded field actually changes the response. Auth ('登录') and cache lifetime are hinted at but not spelled out. For a zero-arg aggregate read tool this is workable but leaves the agent guessing about the payload.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline for 0 params is 4. The freshness/quota remarks in the description concern returned data rather than inputs, which is still useful orientation.

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?

No sentence ever states what the tool returns; the description opens with a bare token ('登录;') and then only enumerates the metric buckets it surfaces (unread, 7-day visitors, chat quota, unreported sessions, stage items, pending review, unplaced chain positions, pending cooperation). The enumeration plus the title '我的今日全景' implies a daily overview/digest, and the closing clause distinguishes it from get_my_positioning / get_my_work / get_my_dispatch, but the agent has to infer the verb and the output form.

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?

Explicit routing guidance is present: full positioning goes to get_my_positioning, work items to get_my_work, and it warns against using get_my_dispatch because reading it marks things as seen in the background. It also says not to poll without a purpose ('勿无目的轮询') and that manually selected stage takes priority. What is missing is a positive statement of the situation that should trigger this tool (e.g. 'call once at session start for a snapshot').

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