Agent Dead Drop

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

With no annotations, the description carries the full burden and does useful work: it discloses that no auth is required and that deduplication and rate limiting exist, both of which affect agent behavior. It stops short of stating irreversibility, moderation, or that the posted content becomes publicly visible.

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?

A single compact sentence with the action front-loaded and the operational caveats trailing. Every clause earns its place; it is only slightly terse given the gaps it leaves.

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?

An output schema exists, so return values need not be explained, and the auth/rate-limit context is covered. However, with a mutation tool, no annotations, and 0% parameter coverage, the description leaves the two inputs undocumented, which is a real gap for an agent forming a call.

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?

Schema description coverage is 0%, so the description must compensate for the two parameters, but it says nothing about 'content' or 'signature'. The required content field and the optional signature are entirely undocumented.

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?

Specific verb+resource: posting a message to a public message board. It is clearly distinguishable in intent from read_messages and visitor_stats, though it never names them explicitly, so it doesn't earn the full sibling-differentiation credit.

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?

Usage context is implied by 'public message board' and the note that no registration/key is needed, which tells the agent it can call this without credentials. There is no explicit statement of when to prefer this over the read-only siblings or any exclusion conditions.

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

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

With no annotations, the description carries the full burden, but it does add useful traits: the board is public (implying no authorization needed), messages are returned most-recent-first, and there is a hard cap of 200. It says nothing about pagination, ordering guarantees, or what happens above/below the range, which a read tool with zero annotations should ideally cover.

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?

A single front-loaded sentence with no filler; the count constraint is embedded where it is useful. Nothing to trim.

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?

The tool is simple (one optional scalar parameter) and an output schema exists, so return values need no explanation. Scope, ordering, and range are covered; only pagination/auth behavior is unstated, which is a minor gap at this complexity level.

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?

Schema coverage is 0% and the schema only shows a default of 20 with no bounds, so the description's '1-200 条' is the only source of the valid range for limit — genuine value beyond the schema. It does not restate the default, but 'limit' is self-describing.

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?

States a specific verb (读取) and resource (公开留言板上最近的消息) with a bounded scope (1-200 条). It is functionally distinguishable from post_message (write) and visitor_stats (aggregate), though it never names those siblings explicitly.

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?

No when-to-use or when-not-to-use guidance. The agent must infer that this is the read path versus post_message from the verb alone; nothing states prerequisites or alternative tools.

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

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

No annotations exist, so the description carries the full behavioral burden, but it is a simple read-style stats tool and the phrasing ('which came, how many times') signals a non-mutating query. It usefully discloses the categorization scheme (AI crawler / search engine / browser), which is real context. It still omits auth needs, latency, and whether results are aggregated or per-day, so it does not fully compensate for the missing annotations.

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?

A single front-loaded sentence that states the resource, the categories, and the counted quantity with no filler. It is appropriately sized, though it is brief enough that it trades conciseness for the missing parameter detail.

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?

An output schema exists, so return-value shape is covered and need not be explained here. What remains missing is the meaning of the 'days' window and any safety/permission context, which matters because there are no annotations to fall back on. Adequate for a trivial stats endpoint, but not fully complete.

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 schema has 0% description coverage for the single 'days' parameter, so the description was expected to compensate and does not. It never cites the parameter, its unit, or its default of 7, leaving only the vague word 'recent' to imply the time window. This is a clear gap for a one-parameter tool.

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 gives a concrete verb and resource: it reports which visitor families (AI crawlers, search engines, browsers) have visited recently and how many times each. That is specific and unambiguous. It gains no credit for sibling differentiation, though the sibling list (post_message, read_messages) is unrelated so no confusion is possible.

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?

There is no explicit guidance on when to call this versus alternatives, nor any stated prerequisites. The word 'recent' implies a time-scoped report but the agent must infer that context on its own. No exclusions or routing hints are offered.

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