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

Annotations only declare readOnlyHint, so the description carries the behavioral burden and does so: default excludes expired entries, page size 20 with max 50, pinned and soon-closing items prioritized, q scoped to limited fields, and an empty-result recovery hint. The startAtKnown=false note adds output-consumption guidance not present in any structured field.

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 purpose is front-loaded and nothing is pure filler, but the telegraphic style crams workflow routing, defaults, ordering, dedup warnings, and empty-result recovery into a few clauses. Terms like 'kinds随q筛选' and 'slug→get_signup_activity→submit_signup' sacrifice readability for density.

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 must imply the return behavior, and it partially does: ordering rules, the startAtKnown and hint fields, and pagination via cursor. It does not describe the full item shape, but for a read-only feed tool the coverage is close to sufficient.

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 100%, so the schema already documents q, kind, limit, cursor, and includeExpired. The description restates the q search scope and default page size with no added syntax or format detail, and 'kinds随q筛选' is less precise than the schema's singular kind enum. Baseline 3 is appropriate.

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: lists activities with signup configuration, explicitly including COMPETITION, and routes the reader to get_signup_activity/submit_signup and get_signup_gaps for multiple sessions. This clearly separates it from the workflow siblings, though it does not explicitly distinguish it from broader feeds like list_activities or list_my_signups.

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?

Gives an explicit pipeline (slug → get_signup_activity → submit_signup), names the alternative for multi-session cases (get_signup_gaps), and warns not to re-apply when already submitted. An agent knows both when to call this tool and what to do next.

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