list_sprouts
Fetches monthly sprout reports for the current user, enabling review of growth activity by month.
Instructions
按月份读取当前用户发芽报告;发芽不是标记数据。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| month | Yes | YYYY-MM | |
| since_id | No | 上一页返回的游标,原样传递 |
Fetches monthly sprout reports for the current user, enabling review of growth activity by month.
按月份读取当前用户发芽报告;发芽不是标记数据。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| month | Yes | YYYY-MM | |
| since_id | No | 上一页返回的游标,原样传递 |
Changes observed during successful MCP inspections.
v1.10.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys that this is a read (读取) and that results are scoped to the current user, but says nothing about pagination (implied by limit/since_id), what the report contains, ordering, or whether results are capped at 20 per page.
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 short clauses, front-loaded with the core action and resource. The second clause is terse to the point of being cryptic, but it earns its place as a disambiguation hint; nothing is padded.
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?
No output schema and no annotations, so the description must cover return shape and paging behavior — it covers neither. An agent calling this cannot tell what a 'sprout report' record looks like or how to page through results without inspecting the schema.
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 67% and the schema already documents month as YYYY-MM and since_id as the previous page's cursor. The description reinforces month-based selection but adds nothing about limit's page-size role or the pagination flow implied by since_id, so it sits at the baseline.
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 concrete verb and resource — read (读取) the current user's monthly sprout report — and scopes it to the current user and a month. The trailing clause '发芽不是标记数据' hints at disambiguation from mark-related siblings like get_note_marks, but it never names get_sprout or explains the relationship.
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 month-scoped, current-user framing implies when this tool applies, but there is no explicit when-to-use versus when-not-to-use, and no mention of the closely named sibling get_sprout. Usage must be inferred from the description's scope alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.