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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — that host-configured MyDramaList authentication is required — but says nothing about pagination, result limits, or what the activity stream contains.

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 no filler, and the resource is front-loaded. It is efficient, though the brevity borders on under-specification rather than true conciseness.

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 and no parameters, the description carries the burden of explaining what an 'activity' result is, and it does not. The auth prerequisite partially compensates, but an agent still cannot predict the shape or meaning of the return data.

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 has nothing to document and the baseline is 4. There is no parameter ambiguity to resolve in the description.

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 verb (get) and resource (activities) scoped to the account, but 'activities' is undefined — it could mean feed events, watch history, or comments. It does not distinguish itself from siblings like mdl_watchlist_get_last_activities or mdl_custom_lists_recent_activity.

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 guidance on when to choose this tool over the many activity-related siblings. The only usage-adjacent statement is the authentication prerequisite, not an invocation condition.

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 idempotentHint=true, so safety is largely covered. The description adds the specific endpoint and return field (profile.read.feeds) with failure code -2 and notes the authentication requirement, which is useful behavioral context beyond annotations, but doesn't elaborate on error handling beyond the one code 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?

One compact sentence front-loads the purpose, endpoint, return field, failure indicator, and auth requirement. Every element earns its place with no waste.

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 read-only endpoint with no parameters and full annotation coverage, the description supplies essential endpoint and return details. However, it doesn't explain what 'profile.read.feeds' represents semantically or how the tool fits with related account tools, leaving some contextual 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?

With zero parameters, the baseline is 4. The description doesn't need to add parameter meaning, and appropriately doesn't.

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: 'Account: get privacy', mapping to the GET /users/settings/privacy endpoint. It's clear what the tool retrieves and distinct from siblings like mdl_account_update_privacy, though it could explicitly differentiate from related account endpoints.

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 mention that it requires host-configured authentication implies a usage context, but there's no explicit when-to-use or when-not-to-use guidance versus related tools such as mdl_account_get_profile or mdl_account_get_activities.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful auth requirement (host-configured MyDramaList authentication), but says nothing about what data is returned, rate limits, or failure behavior.

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 the operation front-loaded and no filler. The second sentence about authentication is relevant; the double space is trivial. Efficient and appropriately sized for a no-parameter read tool.

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 authenticated read with no parameters, the definition is nearly adequate, but with no output schema the description should say what profile fields are returned. That gap leaves the agent unsure what to expect from the call.

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 per the rubric the baseline is 4. There are no parameters whose meaning needs explaining, and the description correctly implies a no-argument 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?

States a specific verb (get) and resource (account profile), which is clear enough to distinguish from siblings like mdl_account_get_privacy and mdl_account_get_activities. However, it does not clarify how it differs from mdl_users_get_user_info or whose profile is returned, so full sibling differentiation is absent.

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 only guidance is the authentication prerequisite; there is no statement of when to use this tool versus alternatives such as mdl_users_get_user_info for another user's profile or mdl_account_update_profile_info for mutations. Usage must be inferred entirely from the name.

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 annotations already disclose this is a non-destructive, non-idempotent, open-world write. The description adds the crucial missing context: it requires host-configured authentication and mutates account state, so it must not be used speculatively. That's meaningful extra behavioral guidance beyond the annotations.

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, all front-loaded and zero-waste. Purpose, dependency, auth, and caution each get exactly one clause.

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 tool, this covers the purpose, dependency, auth requirement, and usage warning. Only the return behavior is absent, and there's no output schema to lean on, but that's a minor 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?

Schema coverage is 0% and there are no annotations, but the description compensates by naming the actual source of the value ('the filename returned by mdl_upload_image'). It doesn't explain the format or validity of that filename, so it adds partial but not full meaning.

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 ('map profile picture') and resource ('Account'), and its dependency (filename from mdl_upload_image) distinguishes it from every 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?

Explicitly warns to use only for an explicit user request and that host-configured MyDramaList auth is required. It doesn't say what to do if the user hasn't uploaded an image yet, but the constraint 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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the write/open-world nature is covered. The description usefully adds that host-configured MyDramaList authentication is required, but says nothing about what the update actually changes or whether it is reversible.

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 action leads and constraints follow. Minor formatting issues (double spacing) but structurally sound.

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 tool with no output schema and a completely undocumented parameter, the description leaves the most important questions unanswered: what 'profile_feed' means, what the update sets, and what is returned. The auth note is a partial mitigation but the definition is not complete enough to invoke confidently.

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 single parameter 'profile_feed' is opaque (integer, no description). The description contributes zero parameter information, 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 and resource ('update privacy') scoped to the account, which distinguishes it from the read sibling mdl_account_get_privacy and from mdl_account_update_profile_info. The purpose is clear, though 'privacy' is not further qualified (what settings are toggled).

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?

'Use only for an explicit user request' gives a real when-to-use constraint and implies when-not (speculative/unprompted calls). It does not name an alternative tool or describe preconditions, so it falls short of the 5 bar.

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 the write/non-idempotent/non-destructive profile, but the description adds real value: patch semantics ('only non-null fields supplied are sent; omitted fields are preserved') and an explicit auth prerequisite ('host-configured MyDramaList authentication'). It stops short of describing failure modes or reversibility of overwritten fields.

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 compact sentences, front-loaded with the action, then patch semantics, auth, and a safety caveat. No filler, though the terse 'Account:' prefix style is slightly fragmentary.

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 with no output schema, the description covers patch behavior, auth requirement, and use-restriction, which is most of what an agent needs. It omits field-level constraints and any note on return/error behavior, leaving minor 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?

Schema coverage is 0% across 5 parameters, so the description carries the burden. It supplies the cross-cutting non-null/preserve rule, which is the key semantic for all five fields, but does not clarify individual fields such as dob format, gender values, or what dob_privacy toggles beyond what their names suggest.

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 ('update profile info') under a clear 'Account:' namespace, distinguishing it from sibling reads like mdl_account_get_profile and from the separate mdl_account_update_privacy. It never names the closest sibling (privacy update) explicitly, so sibling 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 clear gating condition ('use only for an explicit user request') that tells the agent when not to call it, which is valuable for a mutation. However, it does not route the agent to alternatives (e.g., mdl_account_update_privacy for privacy fields) or describe preconditions beyond authentication.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds nothing beyond that – no ordering, pagination behavior, or freshness of 'featured' content.

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?

Very short, but this is under-specification rather than conciseness. Nothing is front-loaded because nothing substantive is stated at all.

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 paged list endpoint with no output schema, the description should at minimum indicate what a page contains and how results are ordered. Nothing beyond the name is conveyed, leaving the agent to guess.

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?

One parameter (page) with 0% schema description coverage, and the description says nothing about it. The agent must infer that page is a pagination index with no stated page size, bounds behavior, or ordering.

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 is a noun phrase fragment, 'Articles: featured.', with no verb to indicate the operation. It implies a listing of featured articles and faintly distinguishes from the sibling mdl_articles_get, but an agent cannot confirm whether this fetches, lists, or filters.

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 guidance on when to use this tool versus mdl_articles_get or any of the many other listing tools. No prerequisites, no exclusions, no alternative named.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing on top of that — no note on what an article fetch returns, whether missing IDs error, or any auth/rate-limit context.

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 words is short, but this is under-specification rather than conciseness — there is no front-loaded purpose, scope, or usage signal for the agent to act on.

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, so the description bears the burden of explaining what a 'get' returns, and it fails to do so. For a simple fetch-by-ID tool this is the one place a sentence of content would have been cheap and valuable.

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 article_id has 0% schema description coverage and accepts either a positive integer or a constrained string, yet the description says nothing about the accepted ID forms or which to prefer. With one undocumented param, the description needed to compensate and does not.

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 "Articles: get" only restates the tool name (mdl_articles_get) as a fragment, giving a bare verb+resource with no scope, return content, or distinction from siblings like mdl_articles_featured or mdl_articles_like. An agent cannot tell what 'get' actually returns or how it differs from the featured-articles tool.

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 alternatives, and no prerequisites. The sibling set contains multiple article-related tools (mdl_articles_featured, mdl_articles_like) and the description does nothing to route between them.

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 and destructiveHint=false, so the mutation profile is covered. The description adds genuinely new context by disclosing that host-configured authentication is required and that the write should only follow an explicit user request. It omits the non-idempotent toggle nature implied by the 'liked' default, so it does not go beyond a 3.

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 clauses, front-loaded with the resource/action before the constraints. Nothing is padded, though the extreme terseness is part of why parameter meaning is missing.

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 small two-parameter mutation with no output schema, the auth requirement and explicit-request caution cover the operational essentials. But with zero parameter documentation and no mention of the like/unlike toggle, an agent can still call it incorrectly, so it is only minimally adequate.

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 says nothing about either parameter. Critically, it never explains that 'liked' defaults to true and can be set false to unlike, nor what article_id accepts (integer or slug-like string). For a tool whose core behavior hinges on that boolean, this is a real 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?

The 'Articles: like' format states a specific verb (like) and resource (Articles), which separates it from siblings such as mdl_comments_like, mdl_feeds_like, and mdl_custom_lists_like. It stops short of explicitly naming those siblings, but the resource is 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?

'Changes data on MyDramaList; use only for an explicit user request' gives a real usage constraint that implies this should not be invoked speculatively. However, it names no alternative (e.g., how to unlike, or which sibling handles other likeable resources) and gives no prerequisites beyond the auth note.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no mention of whether results are paginated, user-scoped, cached, or how large the result set may be. With annotations doing all the work, the description contributes no incremental behavioral context.

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?

At two words it is certainly short, but this is under-specification rather than conciseness — the fragment earns its place only by naming the resource. There is no front-loaded statement of purpose or scope to structure around.

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 list tool with no output schema, the description should at minimum say what an "award" is in this domain (e.g., per-title awards, user achievements) and whether the full list is returned. None of that is present, leaving the agent unable to predict the response shape.

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 for the description to disambiguate; the baseline of 4 applies. The description does not mislead about inputs (it correctly implies no filtering arguments are accepted).

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?

"Awards: list." is essentially a restatement of the tool name mdl_awards_list split into a noun and a verb. It does identify the resource (awards) and the operation (list), but adds no distinguishing detail — no indication of whose awards, what kind, or scope. This is tautological rather than descriptive.

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 guidance on when to use this tool, what preconditions exist, or how it relates to any alternative. The sibling list contains many list-style tools (mdl_comments_list, mdl_custom_lists_get_user_lists, mdl_notifications_fetch), and nothing here helps an agent choose among them.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds a genuinely useful prerequisite (host-configured MyDramaList auth), but says nothing about scope, pagination, or what the episode listing contains.

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?

It is short and front-loaded with no filler, but brevity here shades into under-specification: two fragments leave the core noun "episodes" undefined. There is no wasted sentence, yet there is also almost no substance.

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 and no parameters, the description carries the burden of explaining what comes back, and it does not. It also fails to separate this tool from its closest sibling, mdl_calendar_quarter, leaving the agent without enough to choose correctly.

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 for the description to disambiguate. Schema coverage is 100% on an empty object, which matches the baseline 4 for a parameterless tool.

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?

"Calendar: episodes" is essentially a restatement of the tool name rather than a statement of what the tool does. It gives no verb and no indication of what episodes are returned, and it does not distinguish itself from the sibling mdl_calendar_quarter.

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, when-not-to-use, or alternative routing guidance. The only added sentence is an authentication prerequisite, which is context rather than usage direction, and the agent is left to guess between this and mdl_calendar_quarter.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds nothing behavioral on top of that. It does not disclose what the response contains, whether it needs authentication, or how upstream quarter semantics differ from other calendar calls.

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, front-loaded sentences with no filler, so it is structurally clean. However, the brevity reflects missing substance rather than disciplined editing — the size is not proportionate to a two-required-parameter tool with zero schema documentation.

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, 0% parameter coverage, and no annotations-level explanation of the return shape, the description leaves an agent unable to call the tool correctly — the format of the required quarter value is the core blocker and it is deferred to external documentation. It is not misleading, but it is materially incomplete.

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 schema documents neither year nor quarter (quarter has no even a type). The description notes that quarter is "the upstream quarter identifier" and points to "documented API values," which is a partial hint but leaves the accepted format (Q1? 1? 2024-Q1?) undefined for both 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?

"Calendar: quarter" essentially restates the tool name and never states a verb or what the tool actually does (fetch? list? compute period boundaries?). It hints at a calendar resource, and the pairing with the sibling mdl_calendar_episodes suggests a period-based calendar view, but the agent must guess the operation.

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?

"use documented API values" gestures at input conventions but gives no condition for choosing this tool over mdl_calendar_episodes or any other calendar sibling, and no prerequisites are stated. The only guidance is about values, not about when to call 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that the response includes authentication requirements and package limitations, which is useful context, but it says nothing about the shape, depth, or format of the listing returned.

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 enumerated contents front-loaded and no filler whatsoever.

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 parameterless, read-only introspection tool with no output schema, this covers the essential purpose adequately. The only gap is that it does not hint at how the capability/auth/limitation data is structured.

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, so per the rubric the baseline is 4; there is no parameter surface 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?

States a specific verb ('List') plus three concrete resources (operations, auth requirements, package limitations), so the agent knows this is a meta/discovery tool. It is clearly distinct from all the domain siblings (titles, users, lists, feeds), though it never explicitly names itself as the discovery entry point.

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 name and the phrase 'package limitations' – an agent can infer it should call this to learn the API surface before invoking others. However, there is no explicit when-to-use statement or reference to alternative tools.

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, idempotentHint=false, and openWorldHint=true, so the mutation risk is covered structurally. The description adds genuinely new context: host-configured MyDramaList authentication is required, and the operation changes remote data. It does not say whether only one's own comments can be deleted or what a failure returns.

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 operation and followed by the auth and usage constraint. No filler, though the 'Comments: delete.' phrasing is slightly terse and the spacing is sloppy.

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 destructive single-parameter tool whose annotations already flag the risk profile, the description covers the essentials: auth requirement and mutation warning. It omits the one thing the schema cannot express — the identity/ownership semantics of comment_id and the result of deletion — leaving a moderate 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?

There is exactly one parameter, comment_id, with 0% schema description coverage; the schema only supplies a union type and a pattern. The description adds no meaning about the ID format, ownership constraints, or how to obtain the value, so it 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?

The description states a specific verb and resource ('Comments: delete'), which is unambiguous and clearly separable from siblings like mdl_comments_update, mdl_comments_post, and mdl_comments_list. It stops short of explicitly naming those alternatives, but the purpose is clear.

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?

'use only for an explicit user request' gives a clear condition for invocation, and the auth prerequisite is stated. It does not name the sibling alternatives (update vs. delete) or state what to do instead, so it falls just short of the top band.

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 declare a non-read-only, non-idempotent, non-destructive, open-world write; the description adds two things the annotations do not: it requires host-configured MyDramaList authentication and it mutates remote data, warranting an explicit user request. No mention of return state or reversibility, but this is valuable beyond the structured fields.

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?

Very short and front-loaded: the action leads, then auth requirement, then the mutation caution. Some awkward internal spacing but no wasted sentences.

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 tool with no output schema and zero parameter documentation, the description covers authentication and mutation risk but leaves the parameters and the like/unlike semantics unexplained. Reasonably complete on behavior, incomplete where the schema is silent.

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 either parameter. It doesn't explain that comment_id accepts an integer or string form, nor that 'liked' defaults to true and setting it false unlikes. With two undocumented parameters, the description fails to compensate.

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 action+resource (liking a comment) compactly, which distinguishes it from siblings like mdl_comments_list, mdl_comments_post, and mdl_comments_delete. It is clear but gives no scope detail and doesn't surface that toggling 'liked' to false performs the inverse.

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?

Provides a real usage constraint ('use only for an explicit user request') and flags the auth prerequisite, but offers no guidance on alternatives or the unlike case, which is implied only by the 'liked' parameter. Adequate but with a clear gap.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing on top of that — no pagination behavior, no auth requirements, no ordering. The "upstream parameters" phrasing is opaque rather than informative.

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?

It is short, but short by omission rather than by efficiency. The one substantive sentence ("params is a JSON object of upstream parameters") is vague and pushes an undocumented escape hatch instead of specifying real inputs.

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 4-parameter tool with 0% schema coverage, two required params, no output schema and no enum hints, the description supplies nothing an agent needs to invoke it correctly. It is materially underspecified.

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 compensates for none of the four parameters. The required ptype (enum-less string, no stated allowed values) and pid (integer-or-slug union) are entirely unexplained, so an agent cannot know what ptype should contain or whether pid is a title ID or a slug.

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?

"Comments: list" essentially restates the tool name (mdl_comments_list) without naming the resource domain it operates on (title? episode? user?) or its scope. It never distinguishes itself from mdl_custom_lists_list_comments, which lists comments in a different context. This is close to tautology.

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 prerequisites, and no mention of alternatives such as mdl_custom_lists_list_comments or mdl_titles_get_comment_count. An agent has nothing to route on beyond the name.

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, openWorldHint=true, idempotentHint=false. The description adds meaningful context beyond that: it requires host-configured authentication and warns that it changes MyDramaList data and should be reserved for explicit user requests.

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, front-loaded sentences with no filler; the auth and caution notes appear early. The leading "Comments: post." fragment is redundant with the tool name/title and slightly wastes space.

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 tool with no output schema and 5 parameters (3 required), the description covers auth, the change warning, and one key parameter, but omits meaning for `pid`, `spoiler`, and `reply_to` and says nothing about the response. Adequate but with clear 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?

Schema coverage is 0%, so the description must carry the load. It clarifies only `ptype` ("upstream content type, clist for lists"), leaving `pid`, `spoiler`, and `reply_to` undocumented; `message` is self-evident. Partial compensation for a genuine 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 and resource ("Publishes a comment") and clarifies the tricky `ptype` concept as the upstream content type. An agent can immediately distinguish this write tool from siblings like mdl_comments_list, mdl_comments_update, and mdl_comments_delete.

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 explicit usage restraint ("use only for an explicit user request") and notes the clist special case for lists. It stops short of naming the sibling alternative (e.g., mdl_custom_lists_post_comment) for list comments, so it falls just below a full guidance score.

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 a non-read-only, non-idempotent, open-world mutation. The description usefully adds that host-configured MyDramaList authentication is required and that the operation changes remote data, which is context the annotations do not carry. It stops short of saying what happens to the prior message text or what a failed auth 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?

Three short clauses with no padding, and the authentication prerequisite is front-loaded ahead of the caution.

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 three-parameter mutation with no output schema and zero schema coverage, the description should at minimum identify what fields are editable and what the spoiler flag does. Auth and the explicit-request caution are covered, but the parameter surface is a significant hole.

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 full burden for comment_id, message, and spoiler — and it explains none of them. Only the resource word "Comments" loosely implies comment_id identifies the target comment; the message body, length bounds, and spoiler semantics are left entirely 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?

"Comments: update" is essentially a restatement of the tool name and adds no specific verb+resource detail. It never states what is being updated (a comment's message text and spoiler flag) or how that differs from mdl_comments_post, mdl_comments_delete, or mdl_custom_lists_update_comment.

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 gives one real constraint — "use only for an explicit user request" — which is genuine when-to-use guidance. However, it offers no routing against the many sibling comment/review mutation tools, so the agent must infer which write tool applies.

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 non-read-only, non-idempotent, non-destructive behavior. The description adds genuinely useful context beyond that: it requires host-configured MyDramaList authentication and mutates remote data, so the agent understands the auth prerequisite and side-effect scope.

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 action, auth requirement, and usage restriction are all immediately visible.

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 tool with no output schema, the description adequately covers auth and side-effect expectations, but with 0% parameter coverage and no return-value guidance, an agent still lacks enough to call it confidently in edge cases.

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 neither parameter has documentation in the schema. The description adds no explanation of list_id or entry_id (e.g., valid formats, where the list id comes from), so it fails to compensate for the coverage gap even though the names are somewhat self-evident.

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 ('Custom Lists: add item'), making it clearly distinguishable from siblings like mdl_custom_lists_remove_item and mdl_custom_lists_sort_item. It is clear but does not explicitly call out the siblings it differs from.

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?

Provides a concrete usage condition: 'use only for an explicit user request,' which tells the agent when this mutation is appropriate. It stops short of naming alternatives (e.g., remove_item) or describing preconditions like the list existing.

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, openWorldHint=true, and idempotentHint=false, so the mutating character is known. The description adds two facts annotations do not: it requires host-configured MyDramaList authentication, and it changes remote data. However it does not explain reversibility, error modes, or what the created list 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?

Two short sentences with the auth prerequisite and usage restriction front-loaded. Efficient, though slightly telegraphic style ('Custom Lists: create.') is a minor readability cost.

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 an 8-parameter mutation tool with no output schema and 0% parameter description coverage, the description is far too sparse. It omits required-parameter guidance and any explanation of the seven optional parameters, leaving the agent under-informed for correct invocation.

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 8 parameters, so the description should compensate but does not. Nothing is said about 'type', 'sort_by', 'list_type', 'vote_limit', 'max_num_items', or 'add_permission' semantics, leaving the agent to infer meaning from terse titles alone.

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 'Custom Lists: create', which identifies a verb and resource, but adds nothing about what a custom list is or how it differs from direct siblings like mdl_custom_lists_edit. The name itself carries most of the clarity.

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?

Provides a real usage constraint ('use only for an explicit user request'), which is meaningful for a mutation tool. But there is no guidance on alternatives or prerequisites beyond that; siblings like mdl_custom_lists_edit are not referenced.

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, openWorldHint=true and non-idempotence, so the safety profile is covered. The description adds meaningful context beyond that: host-configured MyDramaList authentication is required and the call mutates remote data, plus the explicit-request guardrail. It stops short of saying what is destroyed (list plus its items) or whether it is reversible.

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 clauses, front-loaded with the action and followed by auth and safety constraints. Efficient, though the opening 'Custom Lists: delete' is largely redundant with the tool name rather than adding 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 destructive, single-parameter mutation with no output schema and no annotation-level detail about permissions, the description covers auth and user-request guardrails but leaves the parameter meaning and the blast radius of the deletion unexplained. Adequate but with obvious holes.

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?

There is one required parameter (list_id) with 0% schema description coverage, yet the description says nothing about it — not the accepted integer/string forms, not the alphanumeric pattern, not what a valid list id looks like. Since the description must compensate for the complete lack of parameter documentation, this is a clear 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 verb (delete) and a resource (Custom Lists), but functionally restates the tool name rather than explaining what deleting a custom list entails. It does not distinguish this from close siblings like mdl_custom_lists_remove_item or mdl_custom_lists_edit, which an agent could easily confuse with 'delete a list'.

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?

'use only for an explicit user request' gives a real usage constraint, which is more than most siblings offer. However, it provides no guidance against alternatives (e.g., edit vs remove_item vs delete) or any prerequisite flow, so routing between the custom-list mutation tools remains inferential.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the bar is lower, and the description still adds two useful facts beyond structured data: host-configured MyDramaList authentication is required, and 'fields' behaves as an upstream patch object (partial update). It stops short of describing error behavior or what happens to omitted fields.

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?

Front-loaded with the purpose, good. But it spends two sentences restating the same idea about 'fields' — 'an upstream patch object' and 'a JSON object of upstream parameters' — which is redundancy rather than added 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 two-parameter mutation with no output schema and 0% schema coverage, the essentials (auth, explicit-request guardrail, partial-patch semantics) are present. Missing are the required list_id semantics, the full set of editable fields, and any failure/response behavior, so an agent could still call it incorrectly.

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 has to carry the load. It explains 'fields' as an upstream patch object with name/description examples, but 'list_id' (the only required parameter) is never characterized, and 'upstream parameters' remains vague about the accepted keys.

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 ('Custom Lists: edit') and names the payload shape and example fields (name, description). It is clearly distinguishable from sibling mutations like mdl_custom_lists_create or mdl_custom_lists_delete, though it never explicitly contrasts with 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?

Gives one real guardrail: 'use only for an explicit user request,' which tells the agent not to fire this autonomously. However, it names no alternatives (create/delete/add_item/set_votes) and gives no prerequisite or precondition beyond the auth note, so the routing guidance is only implied.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no return shape, pagination behavior, ordering of "featured" results, or scope.

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?

Very short, but this is under-specification rather than earned conciseness — three words that convey almost no actionable information. Brevity here comes at the cost of usefulness, not from trimming waste.

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 read-only, paginated list endpoint with no output schema and 0% parameter documentation, the description should at minimum clarify what "featured" means and how page/limit work. As written, an agent has to guess the ordering and semantics.

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 supplies no meaning for the two pagination parameters (page, limit). The agent gets only names, types, defaults, and bounds, with nothing explaining what they control or how pagination interacts with the featured feed.

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?

"Custom Lists: featured" is a fragment that essentially restates the tool name rather than stating a verb+resource action. It hints at retrieving featured custom lists but offers no verb and no differentiation from siblings like mdl_custom_lists_popular, mdl_custom_lists_trending, or mdl_articles_featured.

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 guidance, no mention of alternatives among the many sibling custom-list endpoints (popular, trending, recent_activity, get_user_lists), 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?

The annotations already declare the safe, read-only, idempotent, open-world profile, so the safety burden is carried. The description does add one genuinely useful behavioral fact beyond the annotations: it requires host-configured MyDramaList authentication. It says nothing about pagination behavior, scoping to the requesting user's friends, or result 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?

It is brief and front-loaded, with no filler sentences, which is good. But it is brief because it omits substance rather than because it is economical; the auth note is the only payload. The stray double spaces are a minor formatting blemish.

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 read-only, no-output-schema, paginated browse endpoint, the description should at minimum say what the call returns (custom lists voted on by the user's friends) and how paging works. It supplies the auth requirement but leaves the core 'what do I get back' question unanswered, so an agent cannot confidently distinguish it from mdl_custom_lists_i_voted.

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 does not mention page or limit at all. Although these are conventional pagination parameters with documented defaults and bounds in the schema, the description contributes zero meaning about their semantics (e.g., max 100 per page, page numbering) 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?

The description essentially restates the tool name: 'Custom Lists: friends voted.' maps one-to-one onto mdl_custom_lists_friends_voted. There is no verb describing what actually happens (list? fetch? browse?) and no differentiation from the near-identical sibling mdl_custom_lists_i_voted.

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 guidance is given. The obvious alternative (mdl_custom_lists_i_voted) is never named, nor is there any statement of the context in which 'friends voted' lists are the right choice. The only condition mentioned is authentication, which is a prerequisite rather than usage 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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on whether a missing/invalid list yields an error, whether private lists are accessible, or what the response contains. With annotations present the bar is lower, but zero added context is still a gap.

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?

It is a single short, front-loaded fragment with zero padding. Brevity here reflects under-specification rather than disciplined conciseness, but the structure itself is clean.

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 lookup tool with no output schema, the description should at minimum say what 'detail' returns (list metadata, items, votes, owner) and how list_id is sourced. Neither is present, so an agent cannot predict the result shape or confidently select this tool over the sibling list endpoints.

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%: the single required parameter list_id has only structural constraints (positive integer or 1-128 char slug) and no explanation of what identifier it expects or where to obtain it. The description does not compensate at all, leaving the only argument semantically 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?

The description names a resource (Custom Lists) and an action (get detail), so it is not pure noise. However, 'get detail' is essentially a restatement of the tool name and gives no scope for what 'detail' contains, so an agent cannot distinguish it from siblings like mdl_custom_lists_get_user_lists or mdl_custom_lists_popular without reading 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?

There is no guidance on when to use this tool versus the many other custom-list retrieval tools (user_lists, popular, trending, featured, recent_activity, get_votes). The agent must infer usage entirely from the name.

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, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the title-level restatement—no mention of pagination behavior, whether it returns only public lists, or whose visibility scope applies.

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?

It is short, but only because it is under-specified—a tautological single phrase that adds no information. Brevity here is a deficit, not efficiency.

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 list-fetching tool with 3 params, 0% schema coverage, no output schema, and numerous confusingly similar siblings, the description should at minimum clarify whose lists, visibility, and pagination. None of that is present, making the definition inadequate for correct invocation.

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 supplies no parameter meaning at all. The three parameters (user_id required, page, limit) are undocumented in both the schema and description, and no format, semantics, or defaults are explained in prose.

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 'Custom Lists: get user lists' essentially restates the tool name (mdl_custom_lists_get_user_lists) without adding distinguishing detail. It confirms the resource is user-created custom lists, but gives no scope about whose lists or what content is returned, leaving it indistinguishable from siblings like mdl_custom_lists_i_voted or mdl_custom_lists_friends_voted.

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 guidance, no alternatives named, no prerequisites. With many sibling list tools (get_detail, get_votes, friends_voted, i_voted, popular, trending), the agent gets no help choosing this one.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that—no mention of scope, aggregation, or visibility of the returned votes—so it contributes no behavioral context of its own.

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?

It is short, but that brevity reflects under-specification rather than efficient communication. There is no front-loaded statement of action or result, just a label-like fragment.

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 single-parameter read tool with no output schema, the description should at least explain what 'votes' means and what the caller gets back. It supplies neither, leaving the agent unable to reason about the return value or the exact input semantics.

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 there is a single required parameter (list_id) that the description never explains. It does not clarify the accepted identifier forms (integer vs. the pattern-constrained string) or which list is targeted, so 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?

The text 'Custom Lists: get votes' essentially restates the tool name (mdl_custom_lists_get_votes) with no added specificity. It nominally contains a verb and resource, but gives no indication of what the votes represent (vote counts? voter identities? the current user's vote?) or how they relate to a custom list.

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 guidance on when to use this tool versus the obvious siblings mdl_custom_lists_i_voted, mdl_custom_lists_friends_voted, mdl_custom_lists_set_votes, or mdl_custom_lists_get_detail. No conditions, prerequisites, or alternatives are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — it doesn't say what is returned, whether the status is per-user or per-list, or whether the list 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?

It is short, but the brevity is under-specification rather than efficiency; one sentence that conveys no information beyond the tool name does not earn 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 and no parameter documentation, the description is the only place meaning could be supplied, and it supplies none. An agent knows it reads something about a list's watch status but not what that status is or what it will get back.

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% for the single required list_id, and the description does not compensate at all — no hint about accepted identifier form or that it accepts either an integer or a slug-like string. The agent must infer everything from the anyOf schema alone.

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 essentially restates the tool name: 'Custom Lists: get watch status' maps one-to-one onto mdl_custom_lists_get_watch_status. It gives a namespace and a verb but never explains what 'watch status' actually means for a custom list, so it cannot be distinguished from siblings like get_detail or get_votes on the basis of the text.

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 guidance on when to call this versus the other custom-list read tools (get_detail, get_votes, get_user_lists). No prerequisites, no mention of whose watch status, no 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful non-obvious fact — that it requires host-configured MyDramaList authentication — but says nothing about pagination behavior or what the result set contains.

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 with no waste, and the identifying scope ('i voted') comes first. The auth requirement is placed last, which is acceptable for a prerequisite.

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 read-only, paginated list tool with full annotation coverage, the essentials are nearly there: identity, scope, and auth requirement. It still omits pagination guidance and does not clarify that the results are the authenticated user's own votes, which is the main ambiguity against the 'friends_voted' sibling.

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 provides no information about the two parameters. Page and limit are conventional names, so an agent can guess their meaning, but nothing confirms pagination semantics, defaults, or bounds beyond what the raw schema shows.

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 the resource ('Custom Lists') and the scope ('i voted'), which lets an agent distinguish it from the similarly named mdl_custom_lists_friends_voted. However, it is phrased as a label rather than a verb+resource statement, so it never explicitly says it retrieves or lists anything, leaving the operation type implied.

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 mdl_custom_lists_get_votes, mdl_custom_lists_friends_voted, or mdl_custom_lists_get_user_lists. The only conditional information given is the authentication prerequisite, which is a constraint rather than usage 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=false, destructiveHint=false and openWorldHint=true, so the mutating/external nature is partly covered. The description usefully adds the authentication requirement and the explicit-user-request caution, but does not disclose the toggle/unlike capability implied by the liked=false parameter or the fact that the operation is not idempotent.

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 clauses with no filler; the auth and safety constraints are stated succinctly. Slight redundancy in restating the name, but efficient overall.

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 mutating, authenticated, non-idempotent tool with 0% schema coverage and no output schema, key facts are absent: how to obtain/format list_id, that the operation toggles like/unlike, and what the agent should expect on success or failure.

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% for both parameters. The verb 'like' loosely hints at the liked boolean, but the description never explains that liked=false performs an unlike, nor gives any guidance on the list_id format (integer or alphanumeric string). With no schema text to lean on, this compensation is inadequate.

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?

"Custom Lists: like" names a verb and resource, but it essentially restates the tool name (mdl_custom_lists_like) rather than explaining what liking a custom list means. It also fails to differentiate from the many sibling 'like' tools (mdl_comments_like, mdl_feeds_like, mdl_articles_like, mdl_users_like_person) or to mention that the tool can also unlike via liked=false.

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 gives an explicit precondition (host-configured MyDramaList authentication) and a use constraint ("use only for an explicit user request"). What's missing is any routing to alternatives such as mdl_custom_lists_set_votes or the other like-tools, so the agent still must infer which action family to pick.

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, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is clear without the description. The description adds almost nothing beyond that; it does not describe pagination behavior despite a 'page' parameter, nor comment ordering or return shape. With annotations doing the heavy lifting, a low score reflects the lack of added behavioral context.

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 short but not front-loaded with meaningful information. The first clause is a title echo and the second sentence about 'params' is cryptic and poorly integrated. It is under-specified rather than concise, and the structure does not earn 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?

Given no output schema, three parameters at 0% schema coverage, and a read-only list operation, the description is completely inadequate. It fails to explain what comments are returned, how to paginate with 'page', or what 'params' actually accepts. An agent cannot call this tool correctly without guessing.

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 undocumented parameters. It only obliquely addresses 'params' ('params is a JSON object of upstream parameters'), which is vague and does not explain what upstream parameters are allowed. The required 'list_id' and optional 'page' parameters get no semantic detail in the description or 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?

The description 'Custom Lists: list comments' restates the tool name rather than stating what the tool actually does. It conveys a resource (Custom Lists) and an action (list comments), but the phrasing is essentially a tautology of the name. An agent gains little beyond what 'mdl_custom_lists_list_comments' already implies, and there is no differentiation from siblings like mdl_comments_list or mdl_custom_lists_get_detail.

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 or when-not-to-use guidance. The agent must guess if this is for retrieving comments on a specific custom list versus general comments (mdl_comments_list) or other custom-list subresources. No alternatives or exclusions are mentioned.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond those annotations, such as pagination behavior, ordering criteria, or what 'popular' means in practice.

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 extremely short, but it is under-specified rather than concise: every sentence should earn its place, and this one carries almost no retrievable information. It is front-loaded only in the sense that the identifier appears immediately, not in terms of useful content.

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 paginated list endpoint with no output schema, the description says nothing useful about return shape, ordering, or when 'popular' applies. It does not help the agent invoke the tool correctly beyond identifying the resource name, leaving the definition essentially incomplete.

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 does not mention the page or limit parameters at all. With no compensation from the description, the agent gets no semantic guidance on how to control pagination or result size beyond the raw type/default/min/max in 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?

The description 'Custom Lists: popular.' is a tautological restatement of the tool name, adding no verb or scope beyond what the name already conveys. It also fails to distinguish this tool from close siblings like mdl_custom_lists_trending or mdl_custom_lists_featured, so an agent cannot reliably tell which list variant it returns.

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 guidance on when to use this tool versus alternatives such as trending, featured, or recent activity lists. The description provides no context, prerequisites, or exclusions to help an agent choose correctly among the many custom-list siblings.

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 description adds valuable behavioral context by indicating authentication needs and that the tool changes data on the external site, which complements the annotations. However, it does not detail what happens on success or failure, rate limits, or confirm whether the action is idempotent, leaving some behavioral aspects unclarified.

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 extremely concise, consisting of two short sentences that are front-loaded with the core action and key constraints. Every sentence is relevant and there is no wasted verbiage.

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?

Given the moderate complexity (4 parameters, required fields, no output schema) and the absence of schema descriptions, the description is incomplete. It covers authentication and the mutation nature but omits crucial details about parameters, return behavior, and potential errors, leaving significant gaps for an agent to invoke the tool correctly.

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?

With schema description coverage at 0%, the description fails to compensate by providing any information about the four parameters (list_id, message, spoiler, reply_to). It does not explain their meaning, expected format, constraints, or how to use them, leaving the agent with no guidance beyond the raw 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?

The description states a specific verb+resource combination ('post comment') along with the scope ('Custom Lists'), making the action clear. However, it does not explicitly differentiate itself from the sibling tool mdl_comments_post, which likely posts comments on other entities, leaving some ambiguity about which tool to use for custom list comments.

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 provides implied guidance by stating 'use only for an explicit user request' and mentions authentication requirements, which gives some context. But it lacks explicit when-to-use vs alternatives information (e.g., no mention of when to use mdl_comments_post instead) and does not outline prerequisites or exclusions beyond the authentication note.

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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond the annotations; it does not disclose pagination behavior, ordering, rate limits, or what 'recent activity' actually contains. With annotations present the bar is lower, but the description still provides no extra behavioral context.

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?

It is very short, but this is under-specification masquerading as conciseness. The single fragment lacks a subject and verb, so it does not effectively front-load useful information. It is neither wasteful nor helpful.

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?

Given the tool has two undocumented parameters, no output schema, and no annotations conflicting, the description is completely inadequate. It provides no information about what data is returned, how it is ordered, or how pagination works, leaving an agent unable to invoke the tool correctly with confidence.

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%, meaning the two parameters (page, limit) have no documentation in either description or schema. The description does not mention pagination or any parameter semantics, so it fails to compensate for the coverage gap. Baseline would be 3 if schema were rich, but here the description must carry the burden and does not.

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 'Custom Lists: recent activity.' essentially restates the tool name (mdl_custom_lists_recent_activity). It does provide a vague hint that it concerns recent activity in custom lists, but it lacks a specific action verb (fetch? list? summarize?). Among siblings like mdl_custom_lists_get_user_lists or mdl_custom_lists_popular, it fails to distinguish what 'activity' means or what resource is returned.

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 guidance is provided. An agent has no way to decide between this tool and siblings such as mdl_custom_lists_trending or mdl_custom_lists_featured, nor any 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?

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is known. The description adds non-redundant context: the auth requirement and an explicit caution that it mutates remote MyDramaList data. It stops short of saying whether removal is reversible or what happens if the item isn't present.

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, front-loaded with the operation, then auth, then caution. No wasted words, though the leading label style ('Custom Lists: remove item') is slightly redundant with 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?

No output schema, so the description needn't explain returns, and annotations plus the auth/destructive notes cover the behavioral essentials. However, for a two-parameter destructive mutation with 0% parameter documentation, the complete absence of parameter guidance leaves a real 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?

Schema description coverage is 0% and neither parameter has any prose. The description never clarifies that list_id identifies the target list and item_id the entry to remove, nor does it address the int-or-string anyOf ambiguity. With no schema documentation, the description should have compensated and does not.

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?

Names a specific verb and resource ('Custom Lists: remove item'), which clearly separates it from sibling mutations like mdl_custom_lists_add_item and mdl_custom_lists_sort_item. It is clear but not exceptionally descriptive — it doesn't say what an 'item' is or which list field identifies the target.

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 states the precondition (host-configured MyDramaList authentication) and a usage constraint ('use only for an explicit user request'). This routes the agent away from speculative calls, though it doesn't contrast against add_item/edit as the alternative operation.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description still adds useful non-schema context: it requires host-configured MyDramaList authentication and warns that it changes remote data and should only follow an explicit user request. It does not say whether existing votes are replaced or merged, which would have pushed this higher.

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, front-loaded with the action and then the auth and confirmation constraints; no filler. The only inefficiency is the redundant 'Custom Lists: set votes' header, which repeats 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 non-idempotent mutation with no output schema and zero parameter documentation, the description covers authentication and confirmation gating but leaves the agent unable to construct a valid call or predict the effect. The core gaps are the meaning/format of 'votes' and the effect on pre-existing votes.

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% for both required parameters, so the description carries the full burden and fails to meet it. Nothing explains the format of 'votes' (a scalar, a serialized mapping, a list of IDs?) or the accepted shape of 'list_id' (numeric vs. the slug pattern the schema allows).

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 the domain (Custom Lists) and the action (set votes), so an agent can place it, but 'set votes' is close to a restatement of the tool name and never says whose votes, on what items, or what the operation does to existing vote data. It does not distinguish itself from siblings like mdl_custom_lists_get_votes or mdl_custom_lists_i_voted beyond the verb.

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 'use only for an explicit user request' is a real usage constraint that gates invocation, which is more than most siblings offer. However, no alternatives are named (get_votes, i_voted, friends_voted) and there is no statement of preconditions beyond authentication.

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, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds genuinely new context: host-configured authentication is required, and the operation mutates remote state and should be reserved for explicit user requests. It still says nothing about error behavior or what happens to other items' order values.

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 followed by the auth/mutation caveat. Slightly terse for what is left unexplained, but no wasted text.

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?

Annotations cover the safety profile and there is no output schema to explain, so the description does not need to restate those. But for a mutation tool with three wholly undocumented parameters, the description leaves the agent without enough to call it confidently.

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 all three required parameters (list_id, item_id, order) are undocumented in the schema. The description adds no meaning for any of them, notably 'order' (numeric position, fractional? reindexing?), so the agent gets no help beyond types and patterns.

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 verb (sort) and resource (item in Custom Lists), so an agent can distinguish it from siblings like add_item, remove_item, or set_votes. However, it does not clarify what 'sort' actually means operationally (reorder an item within a list by position?), which leaves a small ambiguity.

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 gives a cautionary usage condition ('use only for an explicit user request') and notes it changes data, which implies when to be careful. It does not name alternatives such as add_item/remove_item or explain when reordering is preferable to other list mutations, so usage is only partially 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond that: no pagination behavior, no result shape, no rate or scope context. It contributes no behavioral value over the structured fields.

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?

It is short, but this is under-specification rather than effective conciseness — two words that repeat the name without front-loading any actionable information. Nothing in the fragment 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 paginated list endpoint with two undocumented parameters and no output schema, the description omits everything an agent needs: what a 'trending' list is, ordering, return contents, and how pagination works. It is not complete enough to call the tool confidently.

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?

Both parameters (page, limit) have 0% schema description coverage, so the description carries the full burden of explaining them and instead says nothing. It neither clarifies pagination semantics nor states defaults or bounds, leaving the agent to guess from the schema titles alone.

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 'Custom Lists: trending.' is essentially a restatement of the tool name (mdl_custom_lists_trending) rather than a stated purpose. It signals a resource area but gives no verb and no indication of what is actually returned or done, so it borders on tautology.

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 guidance about when to call this versus the many sibling list tools (mdl_custom_lists_popular, mdl_custom_lists_featured, mdl_custom_lists_recent_activity). The agent is left to infer that 'trending' is a distinct ordering, with no exclusions or conditions given.

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, idempotentHint=false and openWorldHint=true, so the write profile is known. The description adds genuinely non-structured context: host-configured MyDramaList authentication is required, data on a remote service is mutated, and it should be gated on an explicit user request.

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, with the resource identification front-loaded before the auth and safety caveats. It is efficiently built if a little clipped.

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 tool with no output schema and no annotation coverage of auth, the description correctly covers the operational prerequisites. It is nonetheless incomplete on the input side, giving no guidance on the required message/comment_id pairing or the meaning of the spoiler field.

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 adds no information about comment_id, message, or the unexplained integer 'spoiler' parameter. With three undocumented parameters (including an ambiguous integer flag), the description leaves the agent guessing about what values to supply.

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+resource pair ('update comment') scoped to Custom Lists, which is enough to separate it from read-only siblings like mdl_custom_lists_list_comments. It does not, however, distinguish itself from the near-identical mdl_comments_update or mdl_custom_lists_post_comment, so the agent must infer the boundary.

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?

'use only for an explicit user request' is a real when-to-use constraint plus an implicit auth prerequisite, which is better than nothing. But it never names an alternative (mdl_comments_update vs. this custom-list-scoped variant) or explains when a comment should be created instead of updated.

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 (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already establish that this is a safe, repeatable, open-world read. The description adds only that params is an 'upstream' passthrough, which hints at proxy behavior but says nothing about paging, freshness, or scope; that is modest added value over the annotations.

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 no padding and the purpose front-loaded, so nothing is wasted. However, the brevity reflects under-specification rather than disciplined conciseness.

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 an undocumented free-form params object mean the description must carry the burden of explaining what gets returned and what should go into params; it does neither. For a tool sitting in a dense explore family, this leaves the agent unable to call it confidently.

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 single param is an untyped object (anyOf object/null). The description only says 'params is a JSON object of upstream parameters', which is essentially a restatement of the schema title 'Params' and provides no key names, casing, or expected shape 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?

"Explore: currently watching" largely restates the tool name and never clarifies what the resource actually is — the user's personal watch state, or a global 'most-watched right now' feed. With siblings like mdl_explore_trending, mdl_explore_top_airing and mdl_explore_upcoming, the distinction matters and the description gives the agent no basis to tell them apart.

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 statement of when to use this tool versus the other mdl_explore_* variants, no prerequisites, and no exclusions. The agent is left to infer selection purely from the name.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as what 'recommended' means, what data is returned, or any pagination 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?

The description is short and front-loaded, but it is under-specified rather than genuinely concise. The first fragment repeats the tool name, and the second adds little beyond the schema.

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 read-only explore tool with one passthrough parameter, the description does not explain what 'recommended' returns or how to populate params. With no output schema and no parameter descriptions, an agent lacks enough context to invoke it confidently.

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 the single parameter. It only says 'params is a JSON object of upstream parameters,' which adds marginal meaning over the schema's anyOf object/null type but does not explain what keys or values are expected.

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 'Explore: recommended.' essentially restates the tool name and does not state a specific action or resource. It fails to distinguish this tool from siblings like mdl_titles_get_recommendations or other mdl_explore_* 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?

No guidance is given about when to use this tool versus the many sibling recommendation or explore tools. The agent receives no context about prerequisites, alternatives, or appropriate scenarios.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no indication of result volume, freshness, pagination, 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?

It is short and front-loaded, which is appropriate, but the second sentence about 'upstream parameters' is vague jargon that consumes space without adding usable information. Size is fine; content density is low.

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 and a completely undocumented pass-through parameter, the description should at minimum explain what 'top airing' returns and what params are accepted. Neither is present, leaving the agent unable to invoke the tool meaningfully.

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 single 'params' property is an unconstrained anyOf object with additionalProperties=true. The note that it is 'a JSON object of upstream parameters' names the field but conveys no accepted keys, formats, or examples, so it fails to compensate for the opaque 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?

The description 'Explore: top airing' essentially restates the tool name rather than explaining what it returns or how 'top airing' differs from siblings like mdl_explore_top_movies, mdl_explore_trending, or mdl_explore_upcoming. An agent gets no sense of the ranking source, time window, or result shape.

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 and no named alternative among the many explore_* siblings. The agent must guess whether this is the right discovery endpoint versus mdl_explore_top_movies or mdl_explore_currently_watching.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing on top of that: no indication of scope, pagination, ranking window, or what "top" is measured by, which is the main behavioral question for this tool.

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?

It is short and front-loads the resource, which is good. But the second sentence is filler that adds no actionable information about the opaque params object, so the brevity reflects under-specification rather than efficiency.

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 an open-world, parameter-driven explore endpoint with no output schema and an undocumented free-form `params` object, the description is not sufficient for an agent to call it correctly or predict results. It omits what upstream parameters mean and what the result set represents.

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% for the single `params` parameter, and the description only says it is "a JSON object of upstream parameters" – a hand-wave that conveys no keys, types, or expected fields. 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?

"Explore: top movies" names a resource (top movies) and a generic verb (Explore), which weakly distinguishes it from siblings like mdl_explore_top_airing or mdl_explore_trending by content type. However, the verb is a label rather than a described action, and nothing states what is returned or how "top" is defined.

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 description gives no guidance on when to use this tool versus the many adjacent explore/search siblings (mdl_explore_trending, mdl_explore_recommended, mdl_search_titles, etc.). The agent is left to infer selection purely from the name.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only that params is a JSON object of upstream parameters, which says nothing about return format, pagination, auth, or what 'trending' means in practice.

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 very short and front-loads the purpose, but it is under-specified for the tool's complexity. It is concise without being informative, so it meets only a minimal structural bar.

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 and one completely undocumented parameter, the description should explain what data the tool returns and what the upstream parameters control. It does not, leaving the definition incomplete for correct invocation.

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 parameter has 0% schema description coverage, and the description only says it is a JSON object of upstream parameters. It does not describe expected keys, value types, or examples, 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?

The description states 'Explore: trending,' which gives a verb and a resource category, but it is mostly a restatement of the tool name. It does not explain what kind of trending content is returned or clearly differentiate from siblings like mdl_explore_top_airing, mdl_explore_upcoming, or mdl_explore_top_movies.

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 guidance on when to use this tool versus the other explore tools. The description does not mention prerequisites, contexts, or alternatives, leaving the agent to 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The only added signal is the implication that 'params' is a passthrough of upstream parameters, which hints at a proxy wrapper but does not explain scoping, filtering, or what data is returned.

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 fragments with no waste, but the brevity reflects under-specification rather than tight editing. Nothing useful is front-loaded because nothing substantive is said.

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, 0% parameter documentation, and no meaningful behavioral detail, an agent cannot tell what this tool returns or what to pass in params. Only the generic annotations keep this from being a total void.

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 schema is just an opaque object with additionalProperties=true. The description says only that params is 'a JSON object of upstream parameters', which does not identify a single valid key, format, or expected value, so it 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?

The description 'Explore: upcoming' merely restates the tool name and never says what is being explored or what 'upcoming' refers to (episodes, movies, air dates). It gives no basis for distinguishing this from siblings like mdl_explore_trending, mdl_explore_top_airing, or mdl_explore_currently_watching.

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 guidance on when to use this tool versus the five other mdl_explore_* siblings. No prerequisites, no context, no exclusions are stated anywhere in the description.

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, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description adds genuinely useful context beyond that: the auth requirement and the explicit-request restriction. The 'privacy defaults to public' claim merely repeats the schema default, and nothing is said about reversibility or side effects such as notifications.

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, front-loaded with purpose, then the auth prerequisite, then the usage restriction. 'Feeds: create.' is mildly redundant with the tool name but the remaining content is dense and 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 an 8-parameter write tool with no output schema and zero schema description coverage, the description leaves most of the input surface undocumented. It covers purpose, auth and mutation caution well, but an agent still cannot know what tag_id, group_id, tag_type, spoiler or attachments do.

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?

Eight parameters at 0% schema description coverage, and the description addresses only the privacy default, which is already visible in the schema. Required 'message', plus tag_id, spoiler, embed_id, group_id, tag_type and attachments are left completely unexplained by both schema and description.

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 ('Feeds: create. Publishes an activity post'), which an agent can distinguish from the read siblings mdl_feeds_fetch/mdl_feeds_get and from mdl_feeds_edit/delete. It does not explicitly name those alternatives, so it stops 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 use condition ('use only for an explicit user request') and a prerequisite (host-configured MyDramaList authentication). It does not name an alternative tool for adjacent needs, but the when-to-use gate 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 destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond that: host-configured MyDramaList authentication is required, and the operation mutates remote state. It stops short of stating reversibility or side effects on feed contents.

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; the action comes first and each sentence adds a distinct constraint (auth, mutation, gating). No filler or repetition, though the telegraphic 'Feeds: delete.' fragment is slightly clinical.

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 destructive, non-idempotent tool with no output schema, the description covers the essentials an agent needs before calling (auth requirement, caution, explicit-request gating). It omits what actually gets destroyed, whether the action is reversible, and how to source the feed_id, leaving clear 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?

Schema description coverage is 0% and the description says nothing about feed_id — neither its semantics nor where an agent obtains one or whether a numeric ID and a slug are equivalent. The schema types the value (integer > 0 or a 1-128 char slug pattern) but carries no meaning the description fills in.

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 ('delete') and resource ('Feeds'), which cleanly separates it from siblings like mdl_feeds_create, mdl_feeds_edit and mdl_feeds_hide. It does not explain what a 'feed' is or what deletion implies, so it is clear but thin rather than fully distinguishing.

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 gating condition: 'use only for an explicit user request,' which is real when-to-use guidance for a destructive call. It does not name alternatives such as mdl_feeds_hide for non-destructive removal, so it stops short of a full alternative map.

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, idempotentHint=false and openWorldHint=true, so the write/non-idempotent/networked profile is covered. The description adds genuinely new context: host-configured authentication is required, and the mutation is consequential enough to gate behind an explicit user request.

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, no filler, with the operational warning front-loaded. It is efficient, though the brevity trades away the parameter and scoping detail the tool actually needs.

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 7-parameter mutation tool with no output schema and no annotation coverage of parameters, the description only covers auth and the read/write gate. It says nothing about what an edit overwrites, whether fields are required or replace vs merge, or what the response returns – large gaps 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% and all 7 parameters (feed_id, message, tag_id, tag_type, spoiler, embed_id, attachments) are undocumented in both schema and description. With required params like feed_id and message and opaque free-form fields (embed_id, attachments), the description provides no semantics at all to compensate.

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?

"Feeds: edit" names both a resource (feeds) and a verb (edit), which distinguishes it from the unchanged siblings mdl_feeds_create, mdl_feeds_delete, mdl_feeds_hide and mdl_feeds_like. It stops short of stating what gets edited (message, tags, spoilers, attachments), so the agent knows the operation class but not the editable surface.

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 gives one real runtime rule – 'use only for an explicit user request' – which directly shapes invocation decisions for a mutating tool. It never contrasts against alternatives such as mdl_feeds_fetch/get (read) or mdl_feeds_create (new post), so routing beyond 'only when the user asked' 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds only that params is a pass-through JSON object of upstream parameters, which conveys no additional behavioral context such as scoping, pagination, 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 short fragments with no wasted words, but the first fragment merely echoes the name and the whole is under-specified rather than concise. Brevity here reflects missing content, not efficiency.

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 fetch tool with no output schema, the description never says what a returned feed contains, whose feeds are retrieved, whether results are paginated, or how the opaque params object should be formed. Annotations cover safety only, leaving the functional picture incomplete.

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 says only that params is "a JSON object of upstream parameters" – a hint at pass-through semantics, but no indication of what keys are expected or which upstream endpoint they map to.

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?

"Feeds: fetch" essentially restates the tool name rather than describing what is fetched. It does not distinguish this tool from the closely named sibling mdl_feeds_get, so an agent cannot tell them apart from the description alone.

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, when-not-to-use, or alternative guidance at all. With both mdl_feeds_get and mdl_feeds_fetch present in the sibling list, the absence of any routing guidance is actively unhelpful.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – no return shape, no error behavior for a missing or malformed feed_id, no pagination or auth context.

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 words are technically concise but the text is under-specified rather than economical – there is no meaningful content being front-loaded. Brevity here reflects missing information, not efficiency.

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 single-parameter read tool with full annotation coverage, a complete description would still state what a feed represents and what is retrieved by id. Nothing an agent needs in order to call this confidently is present.

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 says nothing about feed_id, which the schema permits as either a positive integer or a constrained string. With the single required parameter undocumented in prose, 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?

"Feeds: get" restates the tool name (mdl_feeds_get) without adding scope, distinguishing it from siblings such as mdl_feeds_fetch, or saying what a feed is. It is effectively a tautology of the identifier rather than a description of the operation.

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 guidance at all. The presence of mdl_feeds_fetch as a sibling makes the distinction between "get" and "fetch" important, and the description provides no help in choosing between them.

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 and destructiveHint=false, and the description correctly reinforces the mutating nature ('Changes data on MyDramaList'). It adds genuinely useful context beyond the annotations: the host-configured authentication requirement and the explicit-user-request constraint. It does not clarify reversibility of hiding, which is a minor gap.

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 clauses, no filler, and the purpose is front-loaded. Efficient, though the leading fragment 'Feeds: hide.' is telegraphic rather than explanatory.

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 single-parameter mutation with no output schema, the auth and safety guidance is adequate, but the complete silence on the required feed_id leaves the agent without enough to construct a correct call.

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 feed_id parameter has 0% schema description coverage, and the description says nothing about it — not its format, source, or how to obtain it. With one undocumented required parameter, the description 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 ('Feeds: hide'), which an agent can distinguish from siblings like mdl_feeds_delete, mdl_feeds_edit, and mdl_feeds_like. However, it never explains what 'hide' actually means relative to delete/remove, so the boundary is only implicit.

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?

'Use only for an explicit user request' gives a clear gating condition for invocation, but there is no guidance on when to prefer hide over the sibling operations (delete, edit) or any prerequisites beyond auth.

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 the host-configured authentication requirement and the explicit warning that data on MyDramaList is changed, both of which go beyond the annotation set. The annotations already flag non-readonly and non-idempotent behavior, so this is solid supplementary context, though it says nothing about reversibility or how to undo a 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?

Three short clauses, front-loaded with the action, then auth, then the mutation caution. Nothing is padded, though the telegraphic "Feeds: like" header reads more like a label than a sentence.

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 tool with no output schema, it covers the two most important operational facts (auth needed, data changes). However, with 0% schema coverage it leaves the unliking behavior of the 'liked' parameter and the feed_id identifier unexplained, which is a real gap for correct invocation.

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 adds no parameter meaning at all: it never mentions feed_id, nor that the optional boolean 'liked' (default true) is what allows the operation to toggle/unlike. With two parameters entirely undocumented by both schema and prose, 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 action and resource ("Feeds: like"), which cleanly separates it from the similarly-named siblings mdl_comments_like, mdl_articles_like, and mdl_custom_lists_like. It is terse but unambiguous about what operation is performed.

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?

"use only for an explicit user request" gives a clear condition for invoking the tool, which is meaningful guidance for a mutation. It stops short of naming alternatives or the conditions under which an agent should decline, so it is strong but not exhaustive.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the genuine requirement of host-configured MyDramaList authentication, which is useful context beyond structured data, but says nothing about which direction of requests is returned or how the list behaves at scale.

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?

Very short and front-loaded, but the brevity comes from under-specification rather than efficiency; the first fragment earns little and the second carries the only substantive 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 read-only listing endpoint with no output schema, the description never says what is returned (incoming vs outgoing requests, fields, pagination limits) despite the presence of a page parameter. An agent could call it, but not confidently.

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% for the single 'page' parameter, so the description must compensate and does not — pagination, page size, and whether page is 1-indexed are all unaddressed. With only one parameter the omission is survivable but still a real 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?

"Friends: requests" merely restates the tool name in fragment form; there is no verb indicating what happens to the requests (list, accept, send, count). The agent cannot tell from the description whether this reads incoming requests, outgoing requests, or both.

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 guidance, no prerequisites beyond the auth note, and no reference to any alternative tool. The agent is left to infer the trigger condition entirely on its own.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no mention of auth requirements, rate limits, or what happens for a nonexistent group_id.

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 words with no waste, but this is under-specification rather than conciseness. There is nothing to front-load and no information content to justify the brevity.

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 single-parameter read tool with no output schema, the annotations carry the safety story, but the description says nothing about the returned group object or the ID's meaning. An agent has essentially no guidance beyond the tool name.

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% for the single required parameter group_id. The schema constrains its type (positive integer or a pattern-limited string) but never explains what a group ID is or where to obtain one, and the description does not compensate at all.

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 'Groups: get' restates the tool name (mdl_groups_get) without adding scope, fields, or any detail about what a group record contains. It does identify the resource ('groups') and the verb ('get'), so it is not entirely tautological, but it provides no differentiation from the dozens of sibling getter tools beyond the noun.

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 prerequisites, and no reference to alternative tools for group retrieval. The agent is left to infer usage entirely from the name.

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, idempotentHint and destructiveHint=false, so safety is covered, but the description contributes nothing beyond that: no indication of ranking scope, pagination, or result size. With annotations carrying the safety profile, a terse description still leaves the operation's actual behavior opaque.

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 words is short, but this is under-specification rather than conciseness; nothing meaningful is front-loaded because nothing is stated at all.

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, one undocumented parameter, and an ambiguous resource, the description provides none of the context an agent needs to call this correctly.

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% for the single time_period parameter, whose anyOf integer|string union and "alltime" default are unexplained. The description adds no format, accepted values, or default semantics to compensate.

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?

"Leaderboard: get." restates the tool name and title without adding scope. It never says whose leaderboard (users, titles, dramas), what metric is ranked, or how it differs from siblings like mdl_explore_trending or mdl_users_get_user_stats.

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 mentioned. An agent cannot tell from the description when this leaderboard is the right choice over the many explore/list siblings.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutation/destructiveness profile is covered. The description usefully adds the host-configured authentication requirement and a user-consent caution, but does not say what is actually destroyed (the notification becomes gone/unrecoverable) or whether related data is affected.

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, correctly front-loaded with the action and then auth/consent caveats. The lead phrase duplicates the tool name, but nothing is bloated.

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 destructive, unauthenticated-by-default mutation with no output schema, the annotations plus the auth note cover the safety basics. What is missing is the scope distinction against mdl_notifications_clear_all and any explanation of the single required parameter.

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?

One required parameter with 0% schema description coverage, and the description says nothing about it. The agent must infer from the name that notification_id targets a single notification and that the anyOf integer/string union exists; no format, identifier source, or validity guidance is given.

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?

"Notifications: clear" is essentially the tool name restated as a sentence; no verb-object expansion beyond what the identifier already says. Critically, it never distinguishes this single-item clear from the sibling mdl_notifications_clear_all, so an agent cannot tell the two apart from the description alone.

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?

"Use only for an explicit user request" gives a real when-to-use constraint, which is more than most mutation tools offer. However, it never points to mdl_notifications_clear_all as the alternative for bulk clearing, leaving the primary routing decision 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds a genuinely new fact (host-configured MyDramaList authentication is required), but 'Changes data on MyDramaList' largely restates destructiveHint, and it does not say the clear is irreversible or scoped to the whole 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?

Three short clauses, front-loaded with the action, followed by the prerequisite and the caution. No filler, though the 'Notifications:' label-prefix style is slightly mechanical rather than flowing prose.

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 zero parameters, no output schema, and annotations already carrying the destructive/idempotency profile, the description covers the remaining agent-relevant facts (auth prerequisite, explicit-request gating). Only irreversibility and the single-vs-all distinction are left 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?

The tool takes zero parameters, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level information is missing.

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 with an explicit scope: 'clear all' notifications. The 'all' scope implicitly separates it from the sibling mdl_notifications_clear, but the description never names that sibling, so differentiation is left to 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?

Gives a clear usage condition for a destructive operation: 'use only for an explicit user request,' which tells the agent not to fire it autonomously. It stops short of naming the narrower alternative (mdl_notifications_clear) for clearing a single notification.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the genuinely useful constraint that host-configured MyDramaList authentication is required, but says nothing about pagination behavior or result 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 short fragments with no filler and the resource is front-loaded, but the size reflects under-specification rather than discipline. It is concise at the cost of being nearly content-free.

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 paginated list endpoint with zero schema documentation and no output schema, the description should at minimum explain that results are paged and what page/limit control. Annotations cover the safety profile, but the pagination contract is left entirely 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 0% and both parameters (page, limit) are undocumented in the schema, so the description carries the full burden for two params and provides nothing. It does not explain that page/limit drive pagination or what the defaults mean in practice.

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?

"Notifications: fetch" names the resource and the operation, but it is essentially a restatement of the tool name rather than a description of what fetching yields. It does not distinguish this from siblings like mdl_notifications_clear or mdl_notifications_clear_all, so an agent gets the gist but no differentiating detail.

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 guidance on when to use this tool versus its notification siblings, nor any note about pagination limits or typical result set. The only condition given is the authentication prerequisite, which is not usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: it requires host-configured MyDramaList authentication, which is not expressed anywhere in the structured fields.

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?

It is short and front-loaded, but the phrasing is cryptic and malformed ('check already wrote', stray spacing), so brevity comes at the cost of intelligibility rather than earning 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 single-parameter query tool with no output schema, the description omits the parameter's meaning and says nothing about the return value (presumably a boolean or existing-review payload). Only the authentication requirement is covered, leaving key call-time information 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% and the description never mentions title_id or its accepted forms (integer ID or slug-like string). The parameter's meaning is only weakly inferable from the tool name, so 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?

The description 'Reviews: check already wrote' essentially restates the tool name rather than stating a specific verb+resource in readable form. It is barely interpretable as 'check whether the authenticated user already wrote a review,' and it does nothing to distinguish itself from siblings like mdl_reviews_get or mdl_reviews_submit.

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 and no mention of alternatives. The agent is left to infer that this is a pre-check before mdl_reviews_submit, but that relationship is never 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the danger is covered structurally. The description adds valuable non-annotation context (host-configured MyDramaList authentication requirement), but says nothing about irreversibility, what else is lost (votes/comments on the review), or return behavior.

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 clauses, each earning its place, with the warning about data mutation front-loaded. No filler, though the fragmentary style borders on being under-specified rather than concise.

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 destructive, non-idempotent mutation with no output schema and 0% schema coverage, the description covers auth and caution but omits the consequence of deletion and the identity meaning of review_id. Adequate given annotations carry the safety profile, but 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?

The single parameter review_id is completely undocumented in the description, and schema description coverage is 0%. The schema only supplies type/pattern constraints, not meaning (e.g., whether it is the review's own ID or a title-scoped identifier), and the description does not compensate.

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 ("Reviews: delete"), making it distinguishable from siblings like mdl_reviews_get, mdl_reviews_submit, and mdl_reviews_edit. It is terse but unambiguous about what the tool does.

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?

"use only for an explicit user request" provides a genuine when-to-use constraint. However, it names no alternative tools (e.g., mdl_reviews_edit for corrections) and gives no guidance on the condition under which deletion is appropriate versus editing.

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, openWorldHint=true, and idempotentHint=false. The description adds genuinely new context beyond them: host-configured MyDramaList authentication is required, and the operation mutates remote data and should only run on explicit user request. It stops short of describing partial-update or failure behavior.

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?

'Reviews: edit.' is a bare label, and 'fields is an upstream patch object' is restated later as 'fields is a JSON object of upstream parameters', which is duplication. The auth and caution sentences do earn their place, but the parameter discussion 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 non-idempotent external mutation, the description covers auth, mutating nature, and the fields shape, and no output schema is needed. It omits what a patch does to unmentioned fields, error behavior, and any description of review_id, leaving modest gaps for a write operation.

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 burden. It does clarify that 'fields' is an upstream patch object and that rating edits use a nested ratings object, which is useful. But it never explains 'review_id', and the two fields statements are largely redundant ('upstream patch object' vs 'JSON object of upstream 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 ('Reviews: edit'), and 'edit' implicitly separates it from siblings like mdl_reviews_submit, mdl_reviews_delete, and mdl_reviews_get. It does not name an alternative explicitly, but the mutation intent is unmistakable.

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 gives a real constraint ('use only for an explicit user request'), which is useful context. However, it never routes the agent between alternatives such as mdl_reviews_submit for creation or mdl_reviews_delete, so the 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no note on whether the review must exist, authorization needs, or what happens for missing IDs.

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 fragment is short but that brevity reflects under-specification rather than efficient communication. It is front-loaded only in the sense that there is nothing else to say.

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 single-parameter retrieval tool with annotations covering safety and no output schema, the description should at minimum state what is being fetched and by what identifier. Neither is present, leaving the agent to infer everything from the name.

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% for the single required review_id parameter, and the description provides zero compensating detail. It does not clarify that review_id accepts either a positive integer or a 1-128 char alphanumeric string identifier.

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?

"Reviews: get." essentially restates the tool name (mdl_reviews_get) without adding scope, target, or output information. It does not distinguish this retrieval tool from siblings like mdl_titles_get_reviews, mdl_reviews_check_already_wrote, or the review mutation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.