kaiten_get_space_activity

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

With no annotations, the description carries the transparency burden. It discloses non-obvious behavior: combining five specific actions yields complete card location history, and offset pagination is required for a full result set. It also notes the efficiency advantage, though it does not cover auth, rate limits, or response shape.

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?

Two sentences, no filler, and the core purpose comes first. The bulk-alternative guidance is dense but every element earns its place: the action list, the pagination tip, and the efficiency comparison all help an agent decide and invoke correctly.

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?

For a 9-parameter feed tool with no output schema or annotations, the description provides the main decision-relevant context: what the feed does, how to get complete history, and when it is the efficient choice. Exact response fields and auth requirements are not covered, but the schema already documents all parameters thoroughly.

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 baseline is 3. The description adds real value by recommending a specific `actions` value, connecting `offset` to the complete-history pagination strategy, and explaining why this tool is more efficient than the per-card sibling. This goes beyond simply restating field definitions.

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 opens with a specific verb and resource: 'Get activity feed for a Kaiten space.' It then adds a concrete bulk-use pattern and explicitly contrasts the tool with kaiten_get_card_location_history, making it easy for an agent to distinguish this tool from a key sibling.

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 uppercase 'EFFICIENT BULK ALTERNATIVE' tells the agent exactly when to choose this tool: to retrieve location history for all cards in a space without per-card calls. It also prescribes the actions filter and offset pagination, giving actionable selection and invocation guidance.

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