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

Annotations already cover read-only, open-world, and non-destructive behavior. The description adds meaningful behavioral context by specifying that each entry is checked against the live API dump and what criteria are verified, going beyond what the annotations alone provide.

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

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

Two sentences carry a dense but complete message: what it does, what input looks like, what checks are performed, and when to use it. There is no filler, and the key action is front-loaded.

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 non-destructive batch-checking tool, the description covers purpose, input format, verification criteria, and usage context. The lack of an output schema could be helped by describing the result shape, but the gaps are minor and annotations cover the safety profile.

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 description adds useful meaning for the 'members' parameter through examples like 'Humanoid.MoveTo' and 'BodyVelocity', including naming conventions. However, schema description coverage is 50%, and the description does not explain 'max_tokens' behavior or why an agent might adjust it.

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 action ('Batch-check Roblox APIs'), a clear resource (the live API dump), and the exact dimensions checked: existence, deprecation, security restrictions, and yielding. This makes it easy to distinguish from sibling tools like get_engine_api or search_creator_docs.

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 trigger: 'Use this whenever you are about to write or review Roblox code' and explains why stale APIs appear in models. It does not discuss when not to use it or name alternatives, but the usage context is clear enough.

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 establish read-only and non-destructive behavior. The description adds meaningful context beyond those annotations: the source is a live, authoritative dump, and the lookup exposes security level, deprecation, and thread safety. No contradictory behavioral claims are made.

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

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

Two sentences with no filler: the first defines the tool's resource and output detail, the second provides concrete usage guidance. Key information is front-loaded and every phrase 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?

Given no output schema, the description compensates well by summarizing both the lookup scope and the returned information categories. It is adequate for an agent to select and call the tool correctly, though an explicit mention of return shape or error behavior would make it fully complete.

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

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

Schema description coverage is high (80%), so parameters are already documented in the input schema. The description adds only broad context about member kinds ('properties, methods, events and callbacks') but does not meaningfully explain filter, max_tokens, or include_inherited beyond what the schema provides.

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: 'Authoritative signature lookup from the live Roblox API dump', enumerating precisely what is returned (properties, methods, events, callbacks, parameter types, security, deprecation, thread safety). This clearly differentiates it from forum search, bug search, and creator-doc siblings.

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 use cases: 'confirm a method exists', check deprecation or server-only status, and 'find the right member name before writing Luau'. It does not mention when not to use it or explicitly name alternatives, so it stops short of a full 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 cover the read-only, non-destructive, open-world nature of the call. The description adds useful behavioral context by specifying 'post order' and pagination intent, but it does not disclose details like response shape, rate limits, or how pagination behaves at the end of the thread. This is adequate but not rich.

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

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

Two sentences, front-loaded with the core action and resource, followed by a targeted usage condition. No filler or redundant restatement of 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 simple read-only paginated tool, the description covers what the tool fetches, how it orders replies, and when to use it relative to get_thread. With no output schema, a note on return shape could have been valuable, but the description is otherwise complete for the intended use case.

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 60%, with page, topic, and topic_id already described. The description adds no new meaning for these parameters and does not compensate for the undocumented limit and max_tokens parameters, which remain unclear without further inference.

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 ('Fetch'), a precise resource ('a page of replies from a DevForum topic'), and ordering ('in post order'). It clearly distinguishes itself from get_thread by framing this tool as the paginated follow-up that retrieves replies rather than the thread itself.

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 directs when to use this tool: 'Use after get_thread when the answer is buried further down a long thread.' It names the relevant sibling tool and provides a concrete condition for selection, leaving little 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 signal readOnly and non-destructive behavior. The description adds important behavioral detail beyond annotations: Markdown output, original post plus selected replies, accepted answer hoisting, and preservation of code blocks. This is meaningful context for an agent deciding what the tool returns and how it selects 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?

The description is three sentences with no filler. The core purpose is front-loaded, the output format and key behaviors are stated, and the sibling guidance is appended without redundancy.

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 tool with safety annotations and no output schema, the description gives enough operational context: what is returned, how the result is ordered, how URLs are accepted, and how to get the rest. It lacks mention of rate limits or auth, but those are not essential for selecting and invoking a safe read tool.

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

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

Schema description coverage is 75%, so the schema already documents topic, topic_id, and max_posts. The description adds that topic accepts a full URL as well as an id, which is useful. However, max_tokens has no description in the schema and is not explained in the description either, leaving one parameter 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 specific verb ('Read'), a specific resource ('DevForum topic'), and the output format ('as Markdown'). It differentiates itself from the sibling get_replies by clarifying that it returns the original post plus the most useful replies with the accepted answer hoisted.

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 routing guidance: 'Use get_replies to page through the rest.' This tells an agent when to switch to the sibling tool. It does not enumerate exclusions like search scenarios, but the context is clear enough for the common read-vs-paginate choice.

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, and destructiveHint, covering the safety profile. The description adds useful behavioral context: recaps are published every Friday, week steps backward through the archive, and list returns an archive index – details beyond the structured 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 sentences, all substantive: scope, parameter modes, and a recommended workflow. The most identifying information is front-loaded, and there is no filler or repetition of schema details.

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

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

With no output schema and five optional parameters, the description gives enough context to select and invoke the tool correctly. Minor gaps exist – max_tokens is undocumented and the response shape is not described – but these are secondary for a straightforward read-only recap tool.

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

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

Schema coverage is 80%, setting a baseline of 3. The description adds meaningful parameter semantics by explaining week offsets with examples ('0 = newest, 1 = the week before'), clarifying before as a jump to a past date, and defining list as the archive index. This goes beyond what the schema alone provides.

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?

Description opens with 'Read any Roblox Weekly Recap, current or historical' – a specific verb and resource. It also summarizes the recap contents (betas, engine updates, Marketplace and Studio changes), which clearly distinguishes it from sibling search and list 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?

It provides a concrete workflow: 'To find when a specific feature or regression landed, list the archive and read the recaps around that date.' It also explains when to use week, before, and list. It doesn't explicitly name alternatives or state exclusions, so it just misses the bar for 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 establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral detail by stating that the tool returns the latest Weekly Recap body plus all other published items within the time window, and it lists the content sources. This goes beyond annotations by clarifying the output composition, though it does not address potential truncation or section grouping.

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 three sentences with each earning its place: definition, use cases, and return content. It is front-loaded with the digest concept and avoids redundant or promotional language. The structure makes it easy for an agent to quickly grasp what the tool does and when to invoke it.

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 tool with four optional parameters and no output schema, the description explains the main return content and the time-window behavior, which is sufficient for initial selection. It could be more complete by mentioning that results are organized into sections and that max_tokens controls the recap body length, but the description combined with the schema gives enough context for correct invocation in most scenarios.

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 input schema documents three of four parameters with descriptions, leaving max_tokens undocumented. The tool description adds little parameter-level meaning beyond the schema, mostly echoing the time-window concept already described in the days parameter. Because schema coverage is 75% and the description does not compensate for the undocumented max_tokens, this is adequate but not exceptional.

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

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

The description clearly defines the tool as a digest of recent Roblox platform changes, explicitly naming the Weekly Recap, engine Release Notes, and Announcements. It distinguishes itself from the sibling get_weekly_recap by noting it returns the latest recap body plus everything else published in the time window. The title 'What Roblox shipped recently' reinforces the resource being accessed.

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 provides explicit use cases: when a game regressed for no obvious reason, when checking whether an update explains new behavior, or when the user asks what is new. It gives clear context for when the tool is appropriate, though it does not explicitly mention when not to use it or name alternative sibling 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the output being a category tree and most-used tags, but it does not disclose return format, pagination, or any other behavioral trait 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?

The description is two sentences with no filler: the first sentence states what the tool lists, and the second immediately gives actionable usage guidance. Every sentence earns its place.

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

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

For a low-complexity listing tool, the description covers purpose and usage well enough to be minimally viable. However, with no output schema and zero parameter documentation, it leaves the agent without details about return shape or how tag_limit/include_tags affect the 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 description coverage is 0%, and the description provides no information about tag_limit or include_tags. An agent must infer their meaning solely from parameter names and defaults, which is insufficient for a tool with no output 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 uses a specific verb ('List') with a precise resource: the DevForum category tree and most-used tags. It also names the sibling tools that consume category/tag slugs, which clearly distinguishes this tool from search, get, and health-check siblings.

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 explicitly tells the agent when to call the tool: 'when you are unsure which category or tag slug to pass to search_devforum, search_bugs, or list_recent.' It names the relevant sibling tools, though it does not explicitly state when not to use the tool or mention alternatives like check_api_health.

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, and non-destructive behavior, so safety is covered. The description adds practical context for browse use cases but does not disclose operational traits such as default sorting, period behavior, returned fields, or limits beyond what the schema already shows.

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 focused sentences with no filler. The core scope is front-loaded, and the second sentence provides high-value usage examples that help an agent decide why and how to call the 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?

The description is adequate for a first list call, especially with sensible defaults and enum constraints in the schema. But with no output schema and several optional parameters left semantically vague, an agent must infer the return format and how 'top' vs 'latest' and period are meant to behave.

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

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

Schema coverage is 50%, with tag, period, and category described in the schema; the description reinforces category/tag as the key selectors with examples. However, listing, limit, and max_tokens are not explained in the description, and the interaction between listing and period is left implicit.

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 action ('Browse') and resource ('a category or tag'), and the phrase 'without a search query' explicitly distinguishes it from the sibling search_devforum. The title adds 'recent or top,' making the tool's scope immediately 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?

It gives concrete usage scenarios: release-notes/announcements for checking regression causes and scripting-support for seeing current breakage. It implies a no-search-query condition but does not explicitly name alternatives like search_devforum or state when not to use the tool.

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, openWorldHint=true, and destructiveHint=false, and the description adds meaningful behavioral details beyond that: search results include category, last-activity date, and solution-marked status, but there is no public triage state. It also tells the agent to read the thread via get_thread to verify staff response, which is valuable operational 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 sentences with no filler. Scope and intended use are front-loaded, followed by a useful caveat and a concrete next-step instruction. Every sentence contributes to helping the agent decide and invoke the tool correctly.

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 search tool without an output schema, the description adequately covers what is searched, what a hit contains, and how to get deeper detail. The limitation about triage state is important and addressed. No critical operational information is missing.

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

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

The input schema already documents query, area, and after in detail, covering the main parameters. The description itself adds no parameter-level meaning and does not clarify limit or max_tokens, though those are inferable from names and defaults. Schema coverage is 60%, so the description provides modest overall value but leaves the minor parameters to inference.

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: 'Search only the DevForum bug-report categories,' explicitly enumerating the categories. It also ties the tool to a concrete use case, distinguishing it from generic DevForum search by framing it as answering 'is this a known Roblox bug or is it my code?'

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 clearly tells the agent when to use this tool: to check whether a symptom is a known Roblox bug. It also warns about a limitation ('Roblox does not tag reports with a public triage state') and directs to get_thread for follow-up. However, it does not explicitly name search_devforum as the alternative for non-bug-category searches.

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 readOnlyHint/openWorldHint annotations, the description discloses a two-phase behavior: query returns matching pages and a path from those results is needed to read a page in full. This is useful operational context not available from the annotations alone.

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 three sentences with no filler. It front-loads the tool's purpose, then gives the workflow, then the use cases and sibling relationship. Every sentence earns its place.

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

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

The description covers purpose, workflow, use cases, and the key sibling alternative, which is enough for an agent to select and invoke it correctly. It does not detail return format or behavior of limit/max_tokens, but this is a minor gap given the otherwise strong guidance and rich schema defaults.

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

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

Schema coverage is 50%, and the description compensates for the key parameters by explaining that 'query' lists matching pages and 'path' reads the full page. However, 'limit' and 'max_tokens' receive no explanation beyond their default/min/max values, leaving some parameter semantics to inference.

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 ('Find and read') and a concrete resource ('Roblox's official creator documentation'), and explicitly contrasts it with search_devforum for production behavior. An agent can clearly distinguish this tool from its siblings.

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 explicit when-to-use guidance ('intended behaviour, limits and quotas, and guide-level explanations') and names the alternative ('pair it with search_devforum for what actually happens in production'). It also provides the exact call sequence: query first, then path.

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

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

The safety profile is already covered by annotations (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: results are re-ranked to favour solved and recent threads, which an agent would not expect given the order=relevance schema default, and it gives the literal-error-string input strategy. No contradiction with 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 sentences, each earning its place: purpose, when-to-use with a concrete example, and a behavioral note plus follow-up. The most decision-relevant information (scope and usage) is front-loaded before the re-ranking detail.

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 search tool with 9 params, 78% schema coverage, and no output schema, the description covers query formulation, result prioritization behaviour, and the natural next step. It does not describe the response shape, but it does hint at it via 'topic_id', and the remaining undocumented params (limit, order) are self-explanatory by name and enum.

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 78%, so the schema already documents most parameters well. The description adds real param-level value beyond the schema by instructing the agent to paste literal error strings (with a concrete example) or symptom descriptions into the query, which is actionable formulation guidance the schema does not provide.

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 first sentence states a specific verb and resource ('Full-text search across the Roblox Developer Forum'), and the second sentence anchors its scope to community context for bugs/errors/engine behaviour. This implicitly differentiates it from siblings like search_bugs and search_creator_docs, which serve official bug-tracker and documentation lookups respectively.

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 when-to-use guidance ('Use this first when a Roblox bug, error message, or engine behaviour needs community context') and a concrete follow-up chain ('Follow up with get_thread on the topic_id you want to read'). It stops short of naming sibling alternatives with explicit when-not-to-use conditions, but the 'community context' discriminator is clear enough for an agent to route correctly.

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