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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully discloses the returned fields, but says nothing about auth requirements, rate limits, or whether the bot must be an admin of the account.

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 efficient sentence, front-loaded with the subject (the LINE Official Account) followed by the concrete return fields. 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 zero-param, read-only lookup with no output schema, listing the returned fields is exactly the right level of detail. Only a brief note on auth/scope would make it 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?

Zero parameters, which is the baseline-4 case. Nothing in the description conflicts with or needs to compensate for the empty 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 specific resource (the LINE Official Account the bot runs on) and enumerates what is returned: display name, basic ID, chat mode. It is clearly distinguishable from sibling line_get_profile (user profile) in substance, though it does not explicitly name the alternative.

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, and no routing to alternatives such as line_get_profile or line_message_quota. The only hint is the implicit framing that this is an account-identity lookup, which an agent must infer.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so safety is partly covered, yet the description adds real value: quota consumption is one message per recipient, and the action is irreversible. It still omits rate limits or any failure behavior, but the quota and irreversibility disclosure goes meaningfully beyond the structured data.

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 tightly packed sentences, with the broadcast scope and the cost/irreversibility warning both front-loaded. Nothing could be cut without losing information.

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 write tool whose annotations carry the destructive/open-world profile, the description covers scope, quota cost, and irreversibility. It does not need to explain return values since there is no output schema, though the lack of any precondition detail leaves a small gap.

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?

Only one parameter with 0% schema description coverage; the schema supplies type and length bounds but no meaning. The description says 'text message', which is a bare restatement of the name rather than adding format or content guidance.

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 (Send) and resource (text message) plus the exact scope (EVERY friend of the account), which cleanly distinguishes it from line_push_text's targeted delivery. An agent can pick between the two 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?

The 'EVERY friend' scoping implies when to use this over a targeted push, but the description never names line_push_text or any alternative, nor states prerequisites such as channel access. Usage is implied rather than guided.

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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful content context by saying it returns error, event type, and message text from the most recent failed jobs, but it does not disclose pagination, ordering behavior beyond 'most recent', authentication needs, or rate limits.

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 compact sentence that front-loads the core resource and result fields. It contains no filler or redundant restatement of the tool name.

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 read-only listing tool with one parameter and no output schema, the description gives a reasonable high-level account of the returned fields. However, it omits usage context and leaves the limit parameter entirely undocumented, so it is only minimally 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 single limit parameter has no schema description and is not mentioned in the tool description. Although 'most recent' hints at ordering, the description does not explain what limit controls, its default, or its maximum, so it fails to compensate for 0% schema description coverage.

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 clearly identifies the resource (failed jobs) and the fields returned (error, event type, message text), and 'most recent' scopes it to a recent subset. It does not explicitly name a sibling or say how it differs from line_retry_job, which also concerns failed jobs, so it is clear but lacks direct sibling differentiation.

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 use this tool instead of alternatives such as line_retry_job or line_queue_health. The purpose implies it is for inspecting recent failures, but no when-to-use, when-not-to-use, or prerequisite context is provided.

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?

The only annotation is readOnlyHint=true, which the description neither confirms nor enriches. It adds no behavioral detail beyond the purpose statement — nothing about matching behavior, result ordering, pagination via limit, or what a lookup failure looks like.

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 tight sentence with the verb and resource front-loaded and zero filler. Nothing extraneous, nothing buried.

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 read-only search with no output schema, the description covers the essential 'what', but it omits the return shape and how the limit interacts with total results, and it does not compensate for the 33% parameter coverage. Adequate at minimum, not 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?

Schema coverage is low (33%): only 'name' is documented in the schema. The description partially compensates by clarifying that name and role filters combine ('and/or'), but it leaves role matching semantics (exact vs. substring, allowed values) and limit behavior unexplained, so half the parameters remain under-specified.

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 (Search) and resource (linked users / line_users) plus the filter fields (display name and/or role). No sibling tool overlaps with user lookup, so no differentiation is needed, but the description stops short of full specificity (e.g., what 'linked' means or what the result set contains).

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 by the query semantics ('search ... by display name and/or role'), so an agent can infer this is the tool for looking up LINE users. However, it offers no explicit when-to-use guidance, no prerequisites, and no exclusions relative to any alternative lookup path.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the UTC+9 day boundary and the eventual-availability lag (data only after the day ends), which is exactly the kind of non-obvious trait an agent needs. It says nothing about rate limits or auth, keeping 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?

Two short sentences, front-loaded with the resource and metrics, followed by the temporal constraint. Every clause earns its place with no filler or repetition.

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 compensates by listing the returned metrics and the day semantics. Combined with readOnly annotations and a single, fully documented parameter, an agent has everything needed to call it correctly and interpret when data is valid.

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 100% (the date param documents yyyyMMdd, UTC+9, and the yesterday default), so the schema carries the parameter burden. The description's mention of UTC+9 is consistent with the schema but adds no new syntax or format detail. Baseline 3 is correct when the schema already does the heavy lifting.

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 names a specific resource (follower statistics) and enumerates the exact metrics returned (followers, targeted reaches, blocks) scoped to a single day, which is far more concrete than a tautology. It does not explicitly contrast itself with the many sibling line_* tools, but the resource is distinctive enough that an agent can tell it apart from line_bot_info, line_get_profile, or line_message_quota.

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?

It states a meaningful usage constraint: the data is computed per day in UTC+9 and exists only after the day concludes, which tells the agent when results will and won't be available (e.g., today's data is not yet valid). It does not name alternative tools or exclusions, but for a single-purpose stats endpoint the availability window is the key 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered. The description adds the useful precondition that the user must be a friend of the bot (a real error source), but says nothing about rate limits or failure modes beyond that.

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 returned fields are stated first and the friend precondition closes it. The only minor weakness is the vague verb 'Display', which is softer than 'retrieve' or 'get'.

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 correctly enumerates the fields returned (name, picture, status message), which is the key missing structured information. For a one-parameter read tool with readOnly annotations, the remaining gap is only error/precondition detail.

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 carry the load. It partially does by implying the userId must belong to a bot friend, but it never explains the userId field itself, its 'U'-prefixed format, or how to obtain a valid one.

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 names a specific resource (a user's LINE profile) and enumerates the returned fields: display name, picture and status message. That is more informative than the tool name alone, though it never contrasts itself with sibling lookups such as line_find_users.

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 by the qualifier 'a user who has added the bot as a friend', which tells the agent the target must already be a follower. There is no explicit when-to-use statement, no mention of line_find_users as the way to obtain a userId, and no note on what happens for non-friends.

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?

Annotations already declare it non-read-only, idempotent, non-destructive. The description adds real context beyond that: it is a per-user override rather than a global change, and passing null reverts to the default menu. It does not discuss permissions or error behavior, but the override semantics are the key hidden trait.

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, zero padding, with the primary action front-loaded and the null edge case as the follow-up. 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?

For a 2-required-param mutation with no output schema and no annotations covering the override behavior, the description supplies the essential per-user/default interplay. Return values are correctly omitted since no output schema exists, though permission or failure behavior is unmentioned.

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 carries the burden, and it does explain the non-obvious richMenuId null semantics that the schema only hints at via the nullable type. userId's U-prefix format is left to the schema pattern, so it is not fully compensated.

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 ('Show a specific Rich Menu to one user'), and the scoping to a single user distinguishes it from line_richmenu_list. It never names a sibling explicitly, so differentiation is implied rather than stated.

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 concrete when-to-use context ('e.g. after a role change') and the alternative action for the null case (removing the per-user menu so the default shows). No explicit when-not or named alternative tool, but the trigger condition is clear.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the value is monthly and scoped to push/broadcast usage, but says nothing about reset timing, rate limits, or whether hitting the quota affects other calls. Adequate given the annotation coverage.

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 the resource and its scope stated immediately and zero filler. Every word 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?

With no output schema, the description carries the return-value burden and does state the two things returned (quota and amount used this month). It does not describe the shape of the response or units, but for a zero-param read tool this is nearly 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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description appropriately spends no words on parameter syntax.

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 names a specific resource (monthly push/broadcast message quota) and scope (how much used this month), which is clearly distinct from siblings like line_push_text or line_broadcast. However, it never explicitly contrasts itself with those siblings, so it relies on the reader to infer the difference.

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 when-to-use guidance, no mention of checking quota before pushing/broadcasting, and no named alternatives. The reader must infer the utility from 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/network profile is covered. The description adds genuine value by disclosing that the call consumes the monthly message quota, a cost/limit trait not in the annotations. It does not cover error behavior or delivery semantics.

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, zero filler, with the action and target stated first and the quota caveat second. 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?

For a two-parameter, no-output-schema tool whose annotations already cover the safety profile, the description supplies what the agent needs: target scope and the quota cost. It stops short of noting the 5000-character cap or failure modes, but those are minor for this tool's complexity.

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 50%: 'to' is documented with ID prefixes, while 'message' carries only length constraints. The description adds little beyond calling it a 'text message', which marginally signals text-only content. Baseline 3 is appropriate given the schema already explains the key parameter.

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 (send) plus resource (text message) and scope (one user, group or room), which implicitly distinguishes it from the broadcast sibling. It does not name any sibling explicitly, so the differentiation requires a small inference.

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 phrase 'one user, group or room' implies targeted sending rather than mass broadcast, which is implied guidance. There is no explicit statement of when to use this versus line_broadcast, and no prerequisites or exclusions.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds real value beyond the annotation by disclosing the content of the report (per-status counts, staleness of the oldest pending job, stuck-processing detection), which matters since there is no output schema. It stops short of stating thresholds or 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?

Two sentences with no filler: the first defines the resource and its metrics, the second gives the action trigger. The scope is front-loaded and 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?

For a zero-parameter, read-only diagnostic with no output schema, the description supplies exactly what the agent needs: what the tool reports and when to reach for it. No required parameter or return-value detail 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 (empty object schema), so there is no parameter semantics to convey. Per the rubric, the zero-parameter case earns the baseline 4.

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 resource (the webhook job queue, line_jobs) and enumerates exactly what health means here: status counts, oldest pending job age, and jobs stuck in processing. It separates itself from line_failed_jobs only implicitly through the 'use this first' framing rather than by naming the sibling, so it falls short of full sibling differentiation.

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 trigger condition: 'Use this first when users say the bot is not replying,' which is exactly the diagnostic context an agent needs. It does not state when not to use it or name the follow-up alternatives (e.g., line_failed_jobs, line_retry_job), so the routing guidance is clear but incomplete.

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?

Adds behavior beyond the annotations: the state transition (failed to pending), that pickup happens on the next worker run, and the reply-token expiry caveat with push as fallback. Annotations already cover safety and idempotency, so this supplementary context is what earns credit.

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 with zero filler; the core action is front-loaded and the failure caveat follows as qualification.

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 mutation with no output schema, the description covers the action, the timing of pickup, and the failure mode well. It could still note that jobId is sourced from line_failed_jobs or what a successful retry returns.

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% and the description never mentions jobId. With a single required parameter, a UUID pattern alone does not tell the agent where the value comes from (presumably line_failed_jobs), which is a real gap at this coverage level.

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: putting a failed job back to pending for the next worker run. It is distinguishable from siblings like line_failed_jobs (inspect) and line_push_text (send), 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?

Gives usable context: reply tokens expire soon after the event, so a job that replies may fail again, and push is the fallback. This effectively tells the agent when retry is the wrong choice, but it does not spell out prerequisites or an explicit 'do not use when' clause.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the result includes the per-user default rich menu, which is useful return-behavior context, but it says nothing about pagination, limits, or whether 'every user' is aggregated or enumerated.

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 resource front-loaded and no filler. It is a fragment rather than a complete sentence, which slightly weakens the framing but wastes nothing.

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 carries the burden of describing the return value, and it only partially does so: it says what is returned (all menus plus defaults) but not the shape, ordering, or size limits. Adequate for a zero-param read, but leaves real gaps.

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 schema baseline is 4 and there is nothing further for the description to clarify.

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 names a specific resource (Rich Menus on the channel) and specifies the distinguishing payload ('which one is the default for every user'). An agent can tell this is a read/list operation on rich menus, though it never explicitly names the sibling line_link_richmenu to contrast with.

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, when-not-to-use, or alternative is given. The agent must infer that this is the lookup tool to run before line_link_richmenu, but nothing in the text states that relationship.

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