Moda

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

Annotations already cover readOnly/openWorld/idempotent/non-destructive, so the bar is lower, and the description still adds real behavior: share links are resolved on Moda's servers, and the result includes a third state 'could_not_check'. It also pre-empts the missing output schema by naming the verdict values, the group name on success, and the pass-along sentence. It doesn't say whether private/restricted groups or post links affect the verdict.

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 leads with the usage condition, then the parameter, then the return contract — a sensible front-loaded order with no filler. The mid-text 'link:' fragment reads as a slight formatting seam rather than a sentence, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return contract and does so adequately: enum-like verdicts, conditional group name, and a human-facing sentence. The only gap is guidance on what an agent should do after a 'could_not_check' result, but for a single-parameter check tool this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by distinguishing accepted link shapes (facebook.com/groups/... versus facebook.com/share/...) and explaining that share links are resolved server-side to find the target group. That is meaning the schema's one-line 'group, post or share link' does not convey.

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 (check) and resource (a Facebook group/post link) and states the exact question answered: whether the group is an official Moda group. That outcome framing separates it cleanly from siblings like find_moda_groups (search) and check_moda_contact (contact validation) without needing to name them.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete trigger — 'Use when someone has a link ... and wants to know whether that group is an official Moda group' — which is enough for an agent to route correctly. It does not state exclusions or explicitly point to alternatives such as find_moda_groups for when no link exists, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: it returns JSON including symbol/spacing-obfuscated words and non-word decline reasons, and it explicitly warns that an empty list is not a guarantee the post goes up — a meaningful caveat absent from 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?

Front-loaded with the usage trigger, then the two parameters, then the return shape. Three tight blocks with no filler; even the caveat about empty results is load-bearing 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?

With no output schema, the description supplies the return contract (filtered words, catching groups, obfuscated variants, other decline reasons) and its limits. An agent has everything needed to call it correctly and to interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: text must be the full listing as it will be posted, and omitting group checks against every group's filter — behavior the schema doesn't state. It does not clarify the enum slug-to-group mapping further, but the schema already lists that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (check a listing for words that Moda's automatic filters decline) and frames it around a concrete moment in the user's workflow. It is clearly distinguishable from siblings like fix_my_listing or check_moda_contact.

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 explicit trigger conditions: before posting in a Moda group, or after a post was declined. It doesn't name an alternative tool for the 'post was declined' case (e.g. fix_my_listing), so it falls short of full routing guidance, but the when-to-use context is unambiguous.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: it is Moda's own published check, what verdict values can come back, what gets matched, and that moda_rules contains Moda's published wording on what it never asks for.

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 'Use when' trigger, then value format, then return shape, then exclusion. Dense but well ordered; the only slight redundancy is restating the accepted value types already in 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?

There is no output schema, and the description compensates fully by listing the three verdict values, what match data is returned, a human-readable summary field, and the moda_rules field. For a one-parameter read-only check, nothing an agent needs to call or interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the parameter already enumerates the accepted value types, so the schema carries the load. The description adds only the 'exactly one of' constraint, which is useful but marginal, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (a scam check on a Moda contact) and defines scope precisely: contact via person, number, email, or business. The final sentence explicitly excludes Facebook group and post links, which are covered by the sibling check_facebook_group_link, so the tool is distinguishable without opening the schema.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening clause gives a clear triggering situation ('someone was contacted by...' or 'wants to know if one is real'), and the last sentence gives an explicit exclusion for group/post links. It stops short of naming the sibling tool that should be used instead, so the agent must infer the 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes beyond them by disclosing the return shape (meaning, example, nickname references, glossary link), the corpus size (~276 terms), and the fuzzy fallback of up to three close matches when no exact hit exists — behavior an agent cannot see anywhere else since there is no output schema.

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 sentences: trigger first, then parameter note, then return behavior — well front-loaded with no filler. The inline 'term: the word or phrase as written.' line partially duplicates the schema's parameter description, which is the only wasted element.

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 lookup with no output schema, the description supplies everything needed: when to call it, what to pass, what comes back, and what happens on a miss. Nothing material is missing 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 coverage is 100% and there is only one parameter, so the baseline is already high; the description adds the useful instruction that the term should be passed 'as written' and illustrates the range of inputs (abbreviations, nicknames, jargon) the parameter accepts. This is modest but real value beyond the schema's 'The term, abbreviation or nickname.'

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 and resource ('explain a watch or dealer term, abbreviation or nickname') and enumerates concrete examples (BNIB, LNIB, full set, hesalite, grey market, Hulk, Pepsi) that pin down the domain precisely. None of the sibling tools do glossary lookup, so the tool is easily distinguished from look_up_watch_reference or find_watch_by_name.

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 opening 'Use when someone asks what a ... term ... means' gives an explicit trigger condition, which is stronger than most definitions. It stops short of naming exclusions or the adjacent case (a model/reference number should go to look_up_watch_reference rather than here), so the agent must infer that boundary.

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=false, so the safety profile is covered. The description adds genuinely new behavioral detail: the response is JSON with a fixed field set, and some groups may be flagged as temporarily down with an alternative group to use meanwhile. It does not mention result caps or ordering, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The when-to-use condition is front-loaded and the return summary follows, which is the right order. The parameter sentence at the end largely repeats enum values already in the schema, so a small amount of text does not earn its place, and the opening sentence is a long run-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?

With no output schema, the description carries the burden of explaining return values and does so thoroughly, including edge-case behavior (temporarily unavailable groups). For a two-parameter read tool this is nearly complete; only result volume/ordering is unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it: it glosses the topic enum with 'premium (memberships by application)' and gives concrete query examples ('rolex, golf or sneakers'). That extra semantic detail about what 'premium' actually means and how the query string is used is real added value.

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 pairs a specific verb ('find') with a specific resource ('Moda's official groups for the topic') and even enumerates the return fields (name, purpose, access, member count, group link, Moda page, downtime notice, joining steps). An agent can immediately tell this is a community-discovery tool, distinct from lookup siblings like find_watch_by_name or search_moda_help.

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 opening clause gives a clear triggering condition: the user wants to buy, sell or talk about watches, cars, gold, jewelry or sneakers and asks which Moda community fits or how to join. It also inherits 'Use all when unsure' from the schema. It does not name a sibling to use instead when the question is really a help-content question, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description is freed from the safety story. It still adds real context: the exact shape of the returned JSON, the fields per result, and the notable constraint that no prices are published, which prevents a pointless follow-up expectation.

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 usage condition, then a one-line parameter gloss, then the return shape. Every sentence carries information; nothing is padding.

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 lookup with no output schema, the description covers trigger, input meaning, return fields, and the no-prices caveat. An agent could call it correctly and set expectations for the user without any further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 'name' is already documented in the schema as 'A brand, model or nickname'. The description's gloss ('the brand, model or nickname in plain words') restates that, though the nickname examples do help an agent recognize informal inputs. Baseline 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (find a watch) and adds a scope distinction: it is for named watches rather than reference numbers. That contrast alone differentiates it from the sibling look_up_watch_reference without opening either schema.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger condition ('when someone names a watch rather than giving a reference number') with concrete example inputs (Submariner, Daytona, Batman, Moonwatch). It stops short of naming the alternative tool for reference-number lookups, leaving the routing to be inferred.

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=false, so the safety profile is largely covered. The description does add real behavioral context beyond them: it names the remote service the logic runs on, and describes the response shape including per-change explanations and hard-stop words where no rewrite is offered. It omits whether anything is persisted or posted on the caller's behalf, though the read-only annotation and "to copy" phrasing together imply not.

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 sentences in a sensible order: trigger, parameter notes, return shape. Every sentence carries information and the trigger is front-loaded. The return sentence is long and parenthesis-heavy, and the field labels ("text:", "group:") run into prose rather than being visually separated, which costs a little readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining returns and does so thoroughly: rewritten text, the change log with reasons, and the failure mode where words block the post entirely. Both parameters are accounted for, including the optional-group default. Nothing an agent needs in order to call this correctly and interpret the result appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the group enum is already fully documented with human-readable slugs, so the schema does most of the work. The description still adds meaning the schema lacks: that omitting `group` fixes the listing for every group at once, which is a non-obvious default an agent needs. `text` is merely restated as "the listing as written."

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 recognizable action (rewriting a listing so it passes Moda's filter) and situates it as "the Post Checker's Fix my post, run on Moda's servers." The verb is somewhat buried behind the trigger clause in the first sentence, but the return-value sentence ("the rewritten listing to copy") makes the operation concrete. Sibling differentiation is only implicit – check_listing_words is the obvious counterpart and is never named.

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?

Explicit trigger conditions are given: words the automatic filter declines, or a user asking Moda to fix their post. That is a clear activation context rather than vague implied usage. It stops short of naming an alternative (e.g. check_listing_words for diagnosing only) or stating when not to use it, so it falls short of a 5.

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

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

Annotations already declare this a safe, idempotent, non-destructive read, so the description only needs to add operational context — and it does, by disclosing the default of 5, the 1–10 bound, and the two-part return order (outage notices first, then newest feed posts). It omits anything about freshness or failure behavior when the feed is unreachable, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences ordered as trigger, parameter, return value — nothing is wasted and the most decision-relevant information comes first. It is a run-on block rather than clearly separated lines, which is the only structural weakness.

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 a single optional parameter, no output schema, and safety fully covered by annotations, the description carries the return-value burden and discharges it with a clear enumeration of fields. Only edge behavior (empty feed, stale data) is unaddressed, which is minor for this scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents count with min/max, so the baseline is 3; the description earns the bump by supplying the default value of 5, which the schema does not state and which an agent needs to reason about omitting the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete resource (Moda's news feed at modacommunities.com/updates plus outage notices) and a concrete content set (date, kind, title, summary, link), so an agent can distinguish it from siblings like search_moda_help or find_moda_groups without opening any schema.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger conditions: what is new at Moda, whether a Moda group is down, or a recent launch/event/announcement. It does not name an alternative tool for overlapping questions (e.g. pointing help-article questions at search_moda_help), so it stops short of full when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact return fields and the negative constraint 'Moda publishes no prices,' which prevents the agent from promising price data. It omits failure behavior for unrecognized references.

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 usage trigger, then the parameter note, then the return shape — a sensible ordering with no filler sentences. The middle fragment 'reference: the reference number as written.' is telegraphic but does carry the normalization instruction, so it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly takes on the burden of enumerating return fields, and it flags the price limitation. For a one-parameter lookup it is nearly complete; the only real gap is whether an unknown reference returns an error or an empty result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, so the baseline would be 3. The description earns above baseline by clarifying 'as written,' telling the agent not to normalize or reformat the reference, and by supplying valid-format examples the schema lacks.

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 ('look up a watch reference') and anchors it with concrete example inputs (126610LN, 5711/1A), so the agent knows exactly what class of input triggers it. It implicitly separates itself from find_watch_by_name by requiring a reference number rather than a name, but never names that sibling, so differentiation is inferred 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?

'Use when someone gives a watch reference number' is an explicit trigger condition with worked examples, which is stronger than most definitions. It stops short of exclusions — it doesn't say what to do if the user gives a model name instead (presumably find_watch_by_name) or what happens when the reference is unknown.

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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile needs no restating. The description adds genuinely new behavioral detail: results are capped at three published answers returned verbatim with their links. It does not say what happens when no answer matches, which is the main remaining 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?

The usage guidance is front-loaded in the first sentence and the return behavior is summarized in the last, so the agent reads scope before format. The middle line duplicating the question parameter is the only mildly redundant element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only lookup with no output schema, the description covers scope, input phrasing, and the shape of the return (up to three verbatim answers with links). Only the empty-result case is unspecified, which is a minor omission rather than a blocker.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented as 'the question in plain words'. The description's instruction to pass the question 'in their own words' reinforces phrasing but largely restates the schema rather than adding new constraints such as length or keyword behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('questions about how Moda works') and then enumerates the exact topic domains (joining a group, approval times, payments, refunds, bans). This makes it clearly distinguishable from siblings like check_listing_words or explain_watch_term, which handle different scopes.

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 clear trigger condition: use this for questions about how Moda works, backed by a concrete topic list that tells the agent what falls inside scope. It does not name an alternative tool or state exclusions, so routing decisions for borderline questions still require 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?

Beyond the annotations, the description discloses the downstream effect (a case is created and routed to the right person), the side effects (case number plus confirmation email to the supplied address), the legal consequence of agrees_to_terms including phone/SMS consent with STOP opt-out, and the response shape including failure reasons. That is exactly the consent and consequence context annotations cannot convey.

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 opening sentence and consent sentence are dense and worth their space, and required/optional facts are front-loaded. However, the long recital of issue categories duplicates the category and issue_type enums almost verbatim, which pads the definition without adding routing 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 15-parameter write tool with no output schema, the definition covers required inputs, consent, side effects, and the response (case number or failure reason). What is missing is repeat-submission behavior and any rate/duplicate guidance, which matters given idempotentHint=false.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, and the description's required/optional enumeration largely restates that. It does add a little meaning by tying agrees_to_terms to the actual Terms/Privacy URLs and to phone contact consent, but the rest of the parameters gain nothing beyond the schema's own text.

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 and resource (sends a report or request to Moda's team) and anchors it to a concrete equivalent (the form at modacommunities.com/report). It enumerates the exact classes of issues accepted, which makes it unmistakable against siblings like search_moda_help or check_moda_contact.

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 list of supported report types (scam, deal dispute, conduct, access, declined post, billing, general question) gives a clear picture of what belongs here. It never states when NOT to use it or points to an alternative sibling, so routing to search_moda_help for a simple how-to question 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.