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

With no annotations, the description carries the full burden and delivers key traits: the action is queued/asynchronous rather than immediate, it is gated on human approval, it deliberately does not publish, and it returns a queue id. Remaining gaps (rate limits, what happens on rejection, whether the queue id is consumed by rednote_queue_status) are narrower but real.

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?

Three short sentences, zero filler, and the most decision-relevant facts (draft, not posted) are front-loaded before the return-value note. Every sentence earns its place.

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 exists, and the description compensates by naming the return value ("a queue id"). It covers the action, the approval gate, the non-publishing guarantee and the return, which is most of what an agent needs; only the downstream relationship to rednote_queue_status and failure behavior are unstated.

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 80%, with body, images, topics and aiGenerated all documented in the schema itself, so the schema does the heavy lifting. The description adds no parameter-level information (nothing about title length, image ordering, or the aiGenerated flag), so the baseline 3 applies.

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 ("Queue a photo note to be saved as a draft") plus an explicit negative scope statement ("Does NOT post") that separates it from the sibling rednote_create_post / rednote_create_video_post. The agent can pick this tool from the name alone without opening the schema.

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?

"after human approval" states the precondition for calling, and "Does NOT post" implicitly excludes it from the direct-publish path. It stops short of naming the alternative (rednote_create_post) or explaining what to do when approval is denied, so it is clear context rather than explicit when/when-not routing.

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 and does useful work: it explicitly counteracts the 'create_post' name by saying it only queues and 'Does NOT post', and it discloses the return value ('queue id'). It omits auth/permission requirements, what the human approval step involves, and any failure behavior, which keeps it short of a 5.

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?

Three short sentences, each earning its place: what it does, the critical non-action, and the return value. The most decision-relevant fact ('Does NOT post') is front-loaded and impossible to miss.

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?

Without an output schema the description correctly states the return value, and the 80%-covered input schema handles the parameters, so nothing essential is missing for invocation. It stops short of connecting to the surrounding workflow siblings (rednote_open_approval_page, rednote_queue_status), which would have made the definition fully self-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 description coverage is 80%, so the schema already documents body, images, topics and aiGenerated in detail. The description adds no parameter-level meaning beyond that, so the baseline 3 for high-coverage schemas applies.

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 ('Queue a photo note') plus the key qualifier that it is for human approval. The 'photo' qualifier implicitly distinguishes it from rednote_create_video_post and rednote_create_draft, but no sibling is named explicitly, so an agent must infer the boundary from the media-type wording.

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?

'Queue ... for human approval' and 'Does NOT post' imply the tool belongs in an approval workflow rather than direct publishing, which is useful. However, it never states when to pick this over rednote_create_draft or rednote_create_video_post, nor when a note should go straight to approval versus being drafted first; the routing is left to inference.

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 and does well: it discloses the approval-queue behavior, explicitly that nothing is posted, the single-file constraint, accepted formats (MP4/MOV), the 500 MB ceiling, and that RedNote processes the video asynchronously for minutes. It omits auth requirements and what happens after approval is granted.

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?

Four short sentences, zero filler, with the most consequential fact (queues, does not post) front-loaded ahead of file constraints. Every clause carries operational value.

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 mutation-style tool with no annotations and no output schema, the description covers the critical behaviors: no immediate posting, async processing, file limits. It could go further by indicating what the caller receives (a queue/approval reference) or pointing at rednote_open_approval_page, but nothing essential is missing.

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 80%, so the schema already documents title, body, topics, and aiGenerated well; the description's contribution is limited to the video parameter's format and size limits, which partly duplicate the schema description. It adds no meaning for topics or the aiGenerated flag.

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 ('Queue a video note') plus the scope ('for human approval'), which cleanly separates it from rednote_create_post, rednote_create_draft, and the other note-reading siblings. An agent can identify the operation without opening the schema.

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?

'Queue ... for human approval. Does NOT post.' gives clear workflow context for when this tool applies rather than firing a publish action. It does not name sibling alternatives (e.g. rednote_create_post, rednote_create_draft) or spell out exclusions, so it stops short of a 5.

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 provided, the description carries the full burden and does meaningful work: 'Read only' declares the safety profile, 'first page' discloses a pagination/scope limit, and the field list (id, author, text) previews the return shape in the absence of an output schema. It omits auth requirements and whether deeper pages are reachable at all, so it is not complete.

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?

Three tight clauses with the primary action front-loaded and the follow-on tool hint last. No filler, though it is clipped enough that the reader must infer some details.

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 2-parameter read tool with no output schema, the description covers the essential minimum: what is read, the scope limit, and the returned fields. It leaves gaps around the limit parameter, authentication context (relevant given the rednote_login_status sibling), and whether more than one page is retrievable.

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, yet it never mentions the 'limit' parameter (max 50) nor explains its default or whether it interacts with the 'first page' behavior. 'On a note' only loosely implies the required url parameter, leaving the second parameter entirely undocumented anywhere the agent can see.

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 ('Read the first page of comments on a note') plus the exact payload it returns (id, author, text). An agent can immediately distinguish this from rednote_get_note or rednote_reply_comment without opening any schema.

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?

Explicitly names the downstream consumer: 'Use these values for rednote_reply_comment,' which gives a concrete reason to call it (harvest comment ids before replying). It does not state when NOT to use it or contrast it with sibling read tools like rednote_get_note, so it stops short of full routing guidance.

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 provided, the description carries the full burden. It does disclose the read-only nature ('Read only'), which is genuinely useful, but adds nothing about auth requirements, rate limits, error behavior, or whether the URL must be public.

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 compact sentences with zero waste, front-loading the verb and the returned fields. Nothing extraneous.

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 one-parameter read tool with no output schema this is nearly adequate, and the field list substitutes for a return description. However, the undocumented url parameter and absence of annotations leave the definition short of fully callable guidance.

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 single required parameter has 0% schema description coverage and no annotation help. The description never explains that 'url' must be a note URL or its expected format, so it fails to compensate for the schema gap.

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+resource (read one note) and enumerates the fields returned (title, body, author, tags, counts). The singular 'one note' implicitly distinguishes it from the sibling rednote_search, but no sibling is named 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 guidance on when to use this versus alternatives such as rednote_search or rednote_get_comments. There are no prerequisites, conditions, or exclusions stated, so the agent must infer usage from the name alone.

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 provided, the description carries the full behavioral burden, and it does disclose the most important trait: the tool is side-effect free with respect to the target service ('Never touches RedNote'). It also previews the return content (tool/prompt inventory, current mode, remaining budget). It stops short of stating it is read-only/unauthenticated or whether the budget figure is a shared/quota resource, but the safety profile is clear.

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 what the tool reports, followed by the distinguishing constraint. Every word earns its place and 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?

For a zero-parameter, low-risk help tool with no output schema, the description covers what the agent needs: what it returns and that it does not affect RedNote. Only minor gaps remain (whether the budget is per-session or per-account, and that it is a safe read), which are small relative to the tool's simplicity.

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 the baseline of 4 applies. The description correctly adds nothing about arguments, and the empty schema is consistent with a parameterless introspection call.

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 states a specific function: enumerating every tool and prompt, the current mode, and the remaining daily budget. It also explicitly distances itself from the sibling set ('Never touches RedNote'), so an agent can tell it is the meta/help tool rather than a RedNote operation. The phrasing 'What rednote-gate can do' is indirect as an opener but the enumerated outputs make the purpose unambiguous.

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 is only implied: an agent would infer it should call this when it needs a capability overview or budget check. There is no explicit 'call this when...' guidance, nor any note about when it is unnecessary (e.g. when you already know the toolset). Adequate but not directive.

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 and does well: it discloses that the like is deferred pending human approval, that it is not applied immediately, and that a daily cap (10 by default) applies. It omits what happens after approval, whether duplicate requests are deduped, and any auth requirements.

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?

Three short sentences with zero filler, and the most decision-critical fact (it does not actually like the note) is front-loaded right after the verb. Nothing repeats the tool name or wastes tokens.

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 low-complexity two-parameter tool with no output schema and no annotations, the description covers the essential behavior an agent needs before calling it. It could be slightly stronger by describing what a successful call returns or how the queued item is later approved, but nothing critical is missing.

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 both parameters. It usefully explains why noteTitle exists ('so the human sees which note'), but the required `url` parameter is never mentioned or characterized (presumably the note's URL), leaving half the surface 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?

States a specific verb (queue a like) and resource (a note), and immediately clarifies the deferred semantics with 'Does NOT like it yet.' This distinguishes it cleanly from sibling write tools like rednote_post_comment or rednote_create_post, which act immediately.

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?

Explains the operating context (queued for human approval, daily cap of 10) so the agent understands this is a request-queueing tool rather than a direct action. It does not explicitly point to rednote_open_approval_page or rednote_queue_status as the follow-up/alternative, so routing to siblings is left to inference.

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 provided, the description carries the burden of behavioral disclosure. It helpfully declares 'Read only,' which tells the agent this is a non-mutating operation, but it does not describe the return format (e.g., boolean or status object) or any rate limits or side effects.

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 description is a single efficient sentence that front-loads the core action and adds a terse 'Read only' qualifier. Every part earns its place with no wasted words.

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 simple zero-parameter read tool with no output schema, the description is nearly complete. It covers what the tool does and that it checks both main and creator sites, though it could mention the expected return type or any authentication context.

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 has 0 parameters, so there is no parameter meaning to convey. The baseline for zero-parameter tools is 4, and the description appropriately avoids discussing non-existent parameters.

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 states a specific verb and resource: 'Check whether the saved RedNote session is logged in.' It also clarifies scope by mentioning both main site and creator site, which distinguishes it from other RedNote tools.

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 is implied: an agent should call this when it needs to verify session state before attempting authenticated actions. However, the description does not explicitly state when to use it or name any alternatives, leaving the agent to infer the context.

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 and largely meets it: it discloses local execution ('on this computer'), the absence of account side effects ('Never touches RedNote'), and the return contract (absolute paths). It omits where files land on disk and whether re-runs overwrite existing images, which matters for a tool that writes files.

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?

Three dense sentences, front-loaded with the action and format, then the safety note, then the return-and-consumer contract plus card structure. Every clause carries information; nothing is filler.

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 exists, and the description appropriately states the return (absolute paths). Combined with the card-composition rules, an agent has enough to invoke it correctly; minor gaps remain around output location and overwrite behavior, and theme selection is left to the enum alone.

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 only 50% (theme is documented, cards is not), so the description must compensate – and it does, adding semantics the schema cannot express: card 1 is the cover, cover holds a short title plus 0–2 lines, later cards up to 8 lines, and '\n' can break a Chinese title. The nested title/footer length limits and theme option meanings are left to the schema.

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 ('Render text-card images') plus the exact output format (1080x1440 PNG, 3:4), so the agent knows precisely what artifact it produces. It is clearly distinguishable from every sibling, none of which generate images, and it names the downstream consumer rednote_create_post.

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 a clear use case ('for notes without photos') and routing ('Returns absolute paths to pass as images to rednote_create_post'), which tells the agent exactly where this fits in a workflow. It stops short of explicit exclusions or alternatives (e.g., when to prefer video vs cards), so it is clear context rather than full when/when-not guidance.

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 present, the description must carry the full behavioral burden. It does disclose the read-only nature ('Read only'), the sort order ('newest first'), and implies an authenticated session ('logged-in account'), which is meaningful. It says nothing about pagination, the limit cap, rate limits, or failure modes for an unauthenticated account, leaving notable gaps.

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 sentences, front-loaded with the core action and result shape, with no filler. Slightly dense in packing four output fields mid-sentence, but nothing is wasted.

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?

With no output schema, the description usefully enumerates the returned fields and ordering, covering the return contract. But it omits any explanation of the 'limit' parameter, its 30 maximum, or pagination behavior, so an agent cannot call the tool optimally from the description alone.

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 explain the single 'limit' parameter (integer, max 30, exclusiveMin 0) — and it never mentions it. The field list it gives (noteId, title, likes, url) describes return values, not the input parameter, so it does not compensate for the coverage gap.

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 ('List') and resource ('the logged-in account's own notes') and enumerates the returned fields (noteId, title, likes, url) with ordering ('newest first'). The 'own notes' scoping naturally distinguishes it from siblings like rednote_search and rednote_get_note without needing to name them.

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 closing sentence gives a concrete downstream hint ('Use the url for comments and replies on your own notes'), which is useful. However, it never says when to use this tool versus rednote_search or rednote_get_note, nor any exclusion or prerequisite beyond the implied login. Guidance is implied rather than explicit.

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 and does disclose two real behavioral traits: the action happens in the user's browser (a client-side side effect rather than a server mutation) and it returns no link. The 'Returns no link' note is valuable because callers might otherwise expect a URL to hand off. It stops short of describing what happens after approval or any auth/session requirements.

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 sentences, front-loaded with the action and its purpose, with zero filler. Every clause earns its place, including the useful 'Returns no link' caveat.

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 zero-parameter tool with no output schema and no annotations, the description covers what it does, where it happens, and what it returns. Minor gaps remain around subsequent behavior and session requirements, but nothing an agent needs to invoke it correctly is missing.

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 to document and the baseline of 4 applies. The description correctly implies no inputs are needed.

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 ('Open the approval page') plus the user-facing intent ('so they can approve or reject queued writes'). It is clearly distinguishable from siblings like rednote_queue_status, though it does not explicitly name them.

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 clause 'so they can approve or reject queued writes' implies the scenario in which this tool applies, giving more than nothing. However, it never states when to prefer this over checking queue status or any other sibling, nor any prerequisites, leaving selection largely to inference.

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 provided, the description carries the full behavioral burden and does well: it explicitly discloses that the tool does NOT post and that it queues for human approval, and it names the return value (a queue id). It stops short of stating auth requirements or whether queuing is idempotent, which would take it to a 5.

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?

Three short clipped sentences, each earning its place: action, the key negative constraint, and the return value. Front-loaded with the verb and resource, no filler.

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 simple two-param queue tool with no annotations and no output schema, the description covers the essentials: what it does, what it does not do, and what it returns. Minor gaps on auth and approval workflow context remain.

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, and it only partially does. The required url and text params are never explained in the description, though the tool's narrow purpose makes their roles obvious from names and formats. Baseline 3 given the trivial two-param surface.

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 (Queue), resource (comment on a note), and a crucial scope qualifier (for human approval, does NOT post). This distinguishes it from the actual posting sibling tools like rednote_reply_comment without the agent needing to open any schema.

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?

Implies usage through 'for human approval. Does NOT post.' but never explicitly says when to choose this over rednote_reply_comment or rednote_open_approval_page. The alternative-path guidance is inferable but not stated.

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, and it does disclose two useful traits: 'Read only' (safe, non-mutating) and 'Never touches the browser' (important for an automation suite that drives a browser). However it omits what 'recent' means, retention/window behavior, ordering, and the shape of outcomes, so it is only partially transparent.

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?

Three short sentences, purpose front-loaded, with zero filler; the two trailing sentences both add behavioral value. It is tight and well-ordered, though it leaves the definition under-specified rather than truly complete.

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 one-optional-parameter tool this is roughly minimum viable: it says what is listed and that it is safe, but with no output schema the description should have described the return shape (statuses per queued write) and the meaning of 'recent'. Those gaps leave the agent guessing at results.

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 description never mentions the single `limit` parameter. The agent gets the constraint (max 50, exclusiveMinimum 0) from the schema, but no explanation of what limit controls, no default value, and no guidance on how it interacts with 'recent' — the description fails to compensate for the coverage gap.

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 (list) and a specific resource (recent queued writes and their outcomes), which is clearly distinct from write siblings like rednote_create_post or state siblings like rednote_login_status. It stops short of naming which tool enqueues writes, so sibling differentiation is inferential rather than explicit.

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 is implied — you would call this to inspect outcomes of previously queued writes — but there is no explicit when-to-use, when-not-to-use, or reference to any alternative tool. 'Read only' hints that it is a safe diagnostic call without stating the condition that selects it.

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 burden and does disclose the key non-obvious trait: the reply is queued for human approval and not posted, so the agent knows nothing is published immediately. It omits secondary behavior such as auth requirements, what happens to the queued item afterwards, or where approval occurs.

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?

Three short sentences, no filler, with the action and the critical 'does NOT post' caveat front-loaded before the parameter instruction. Every clause earns its place.

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 or annotations exist, so the description is the sole source of guidance for a 5-required-param mutation-ish tool. It covers the sourcing of three params but leaves the url/text parameters and the post-queue lifecycle (approval page) unexplained, so an agent can make the call but not fully reason about it.

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% across 5 required params, so the description must compensate. It explains the origin and exact-pass-through semantics of commentId, commentAuthor and commentText, but says nothing about 'url' (presumably the note) or 'text' (the reply body, especially its 500-char limit), leaving two of five params unilluminated.

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 precise verb+resource+outcome: 'Queue a reply to one comment for human approval.' The follow-up 'Does NOT post.' sharply distinguishes it from the sibling rednote_post_comment, which an agent can pick between without opening either schema.

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 concrete workflow context: pass commentId, commentAuthor and commentText exactly as rednote_get_comments returned them, which tells the agent to call rednote_get_comments first and what to feed in. It does not explicitly name rednote_post_comment or rednote_open_approval_page as the alternative/next step, so it stops short of full when/when-not routing.

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; it does declare 'Read only' and describes what comes back (note urls with xsec_token), which is genuinely valuable workflow context. It omits any mention of login/auth requirements (a rednote_login_status sibling exists), rate limits, or result-count behavior, so it is adequate rather than complete.

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?

Three short, front-loaded sentences with no filler. The core purpose leads, and the downstream xsec_token dependency follows immediately.

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 exists, and the description does address the return payload (note urls carrying xsec_token). However, it says nothing about the limit parameter, result ordering, or pagination, which leaves gaps for a search tool.

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, but it only alludes to 'keyword'. The 'limit' parameter, including its max of 30, is never mentioned or explained, leaving one of two parameters undocumented anywhere.

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 ('Search RedNote notes by keyword'), which cleanly separates it from mutation siblings like rednote_create_post and rednote_like_note. It does not explicitly distinguish itself from the closest read sibling, rednote_my_notes, so it falls short of a 5.

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 when-to-use or when-not-to-use statement, and no alternative tool is named. The clause 'that carry the xsec_token other tools need' implies a required first step before calling rednote_get_note, which is useful but left for the agent to infer.

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