AIXBT

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context about the content returned (evidence grade, sources, timestamps, audience clusters, configurable activity rows). It does not contradict the annotations and adds value beyond the structured hints.

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

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

The description is a single, well-structured sentence that front-loads the verb and resource, then lists the included details. Every word contributes meaning, with no redundancy or filler.

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

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

For a simple get-by-ID tool with only 2 parameters, an output schema, and read-only annotations, the description provides enough contextual detail. It mentions the key return components, and the output schema covers return structures, so nothing essential is missing.

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

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

The input schema provides full descriptions for both parameters (id and activity), so the schema coverage is 100%. The description only reframes 'activity' as 'configurable activity rows' without adding new semantics, so it adds no meaningful beyond-schema information. Baseline 3 is appropriate.

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 states the tool retrieves a single Intel item by ID ('Get one Intel item by ID'), distinguishing it from sibling tools like list_intel. It also enumerates key return fields (evidence grade, Project, sources, timestamps, audience clusters, activity rows), making the purpose specific and 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?

The phrase 'by ID' implies the tool should be used when you have a specific Intel ID and need full details, which is a clear usage context. However, it does not explicitly mention alternatives like list_intel for browsing or multiple items, so it stops short of providing explicit when-not-to-use 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 the tool read-only and non-destructive, so the safety profile is covered. The description adds valuable behavioral nuance: data availability ('when available') and the caveat that related Projects are based on co-mentions, not partnerships/endorsements, preventing misinterpretation. It does not contradict 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 concise sentences carry substantial information. The first sentence lists all key return fields in a compact list, and the second adds a clarifying caveat. There is zero redundancy or filler, earning the highest score.

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's moderate complexity, annotations, full parameter coverage, and presence of an output schema, the description is complete. It covers identification method, returned fields, data availability caveat, and the semantic basis of related Projects. No critical gaps remain for an agent to select and invoke this 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?

The input schema fully describes the single parameter 'idOrSlug' with 'Project ID or slug; slug aliases resolve', achieving 100% schema coverage. The description's mention of 'by ID or slug' slightly reinforces, but adds no new syntactic or format details beyond what the schema already provides. Baseline of 3 is appropriate.

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: 'Get a Project by ID or slug'. It clearly enumerates the returned data (trend, rank, recent Intel, related Projects, 24-hour trend change), making the tool's function unmistakable. The mention of related Projects based on co-mentions further distinguishes this from sibling tools like get_project_series or get_topic.

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 clear context by listing the exact data returned, implying this tool is for retrieving individual project detail with associated metrics and related items. It does not explicitly name alternatives or exclusion scenarios, but the specificity of the resource and fields gives a strong sense of when it should be used.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: trend returns hourly points, rank returns recorded rank changes and null while unranked. This goes beyond the annotations and helps the agent anticipate 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?

Two concise sentences. The first sentence states the core action and scope, the second explains the two measure modes and optionality. No wasted words, front-loaded with the key verb and resource.

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's moderate complexity, an output schema exists, and annotations cover safety, the description is complete enough. It covers the main selection criteria (trend vs. rank, project identifier, time window) without needing to restate schema details or return formats.

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. The description adds subtle meaning beyond the schema by explicitly stating 'null while unranked' for rank and 'hourly points' for trend, which enriches the semantic understanding of the measure parameter beyond its enum descriptions.

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: 'Get trend or rank history for a Project by ID or slug.' It clearly distinguishes this from sibling tools like get_topic_series by targeting Project history specifically and by detailing the two measurement modes (trend and rank).

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 implies when to use it by explaining what trend vs. rank returns and that a time window is optional. It does not explicitly name alternatives or state exclusions, but the context is clear enough for an agent to select this tool over similar series 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 cover read-only/non-destructive behavior; the description adds important behavioral context: the entitlement requirement and the possibility of superseded reports that may not be current. This conveys the auth and data-freshness caveats not present in 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, front-loaded with the primary action, then the prerequisite and alternative. Every clause adds value without repetition or excessive 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?

The tool is simple (one parameter), has a rich output schema (not needing return description), and the description covers the essential context: purpose, entitlement, and supersession. No gaps remain for effective 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 schema covers 100% of the parameter with a description of 'Report ID', and the tool description adds little beyond that. The description implicitly ties the ID to published reports, but doesn't explain where to find it or its format, so the baseline of 3 is appropriate for high schema coverage.

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

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

The description clearly states 'Get a published report by ID' with a specific verb and resource, and lists what's included (full text, sources, publication evidence). It also distinguishes from siblings by mentioning the superseded case and pointing to list_reports, making its scope 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?

Explicitly states the required entitlement, and provides a clear alternative for superseded reports ('use list_reports to find the current ID'). This gives the agent both a prerequisite and a fallback, exceeding basic 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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable context: it returns stance history, requires no credential, and returns 'not_current' for stale IDs. This is exactly the kind of behavior disclosure that helps an agent select and invoke the tool correctly.

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 carrying necessary information: action, auth, and edge case/alternative. The description is front-loaded with the verb 'Get' and avoids irrelevant details, making it efficient and to the point.

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's simplicity (one parameter, output schema exists) and the sibling context, the description fully covers what the agent needs to know: scope, auth, and what happens for non-current topics. The output schema handles return structure, so no further explanation is needed.

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 schema coverage is 100%, with the parameter description already stating 'Topic ID from list_topics.' The tool description adds no new information about the parameter beyond what the schema provides, so baseline 3 is appropriate.

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 states the tool's function: 'Get one current Topic by ID, including its stance history.' This specifies a unique resource (Topic) and differentiates it from siblings like get_topic_series or list_topics by emphasizing 'current' and 'by ID'.

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 explicit guidance: 'Available without a credential' and 'A Topic that has left the leaderboard returns not_current; use list_topics for current IDs.' This tells the agent when to use list_topics instead, which is a clear alternative.

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 annotation, the description discloses specific behaviors: trend returns hourly points, rank returns null when unranked, and the time window is optional. It also states authentication requirements (OAuth or AIXBT API key), which adds significant transparency for the agent.

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 concise, comprising three short sentences that front-load the core purpose and immediately follow with actionable details. Every sentence adds value; there is no fluff or repetition of schema 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?

Given the presence of an output schema and the tool's moderate complexity (4 parameters, 2 required), the description sufficiently covers the tool's purpose, behavior, auth requirements, and optional parameters. It does not need to explain return values because the output schema exists, and it provides enough context for the agent to select and 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?

While the schema descriptions already cover all parameters, the description adds extra meaning by explaining the 'null while unranked' behavior for rank and explicitly noting that the time window is optional. This goes beyond the schema's literal field descriptions, providing helpful semantic context.

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 states the tool's function: 'Get measurement history for a Topic.' It specifies the resource (Topic) and the action (get history), distinguishing it from siblings like get_topic (current topic info) and get_project_series (project history). The additional detail about trend versus rank further clarifies scope.

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 clear context for when to use the tool (when measurement history for a topic is needed) and how to choose measures ('Trend returns hourly points; rank returns recorded rank changes'). It does not explicitly discuss alternatives to exclude, but the context of the tool being for topic history among siblings makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar for adding context is lower. The description adds that the values are 'current' and lists the categories, but it does not disclose return format, pagination, or any other behavioral traits. This is adequate but not rich, so a score of 3 is appropriate.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and the scope of its output, making every word 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?

The tool is simple with no parameters, has an output schema, and is marked as read-only. The description clearly states what the tool returns (allowed filter values across specific categories). With the output schema available to detail return structure, the description is complete for the tool's purpose.

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

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

The tool has zero parameters and schema coverage is trivially 100%. Per the baseline for 0 parameters, a score of 4 is appropriate. The description adds no parameter details, but none are needed since there are no 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 clearly states the tool's function: retrieving current allowed values for AIXBT filters, with a specific verb ('Get') and resource ('filter vocabulary'). It enumerates the filter categories (grades, sentiments, etc.), which distinguishes it from sibling tools that retrieve intel, projects, reports, or topics.

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 implies the tool is used for obtaining filter vocabulary but does not explicitly state when to use it versus alternatives or when not to use it. Since no sibling tool serves this purpose, the context is implied but not explicitly articulated.

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 destructiveHint=false, so the safety profile is covered. The description adds context about what the clusters represent (community groups used by AIXBT) but does not disclose behavioral details such as pagination, sorting, or output structure. It adds value but leaves gaps.

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

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

The description is a single, front-loaded sentence that starts with the verb 'List' and clearly conveys both the core function and the optional filter. There is no unnecessary detail or 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 simple read-only tool with one optional parameter, an output schema, and annotations, the description adequately covers the purpose and filter. The only notable omission is explicit guidance on when to choose this over sibling tools, but the tool's simplicity makes the description sufficient.

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

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

The schema fully documents the universe parameter with an enum and default value, achieving 100% coverage. The description only repeats that filtering is optional, which adds no new meaning beyond the schema. Baseline 3 is appropriate.

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 states the tool's function with a specific verb ('List') and resource ('community groups'), and defines its purpose ('to show which audiences are driving attention across Topics and Intel'). It is distinct from sibling list tools like list_topics, list_intel, and list_projects by focusing on audience clusters.

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 implies a use case (understanding audience attention across Topics and Intel) but does not explicitly state when to use this tool versus the many list_* siblings, nor does it mention any alternatives or exclusions. The context is present but not directly actionable for tool selection.

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral disclosures: results explain why they matched, and meta.searchCoverage/meta.executedSearch indicate when responsiveness bounds a search. This gives agents important operational knowledge about limitations not visible in the 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?

Two sentences, front-loaded with the core function, and efficiently packs search capabilities, filter categories, result behavior, and limitation metadata without redundancy. Every clause earns its place.

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

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

With an output schema present and 100% parameter schema coverage, the description need not explain return values or every parameter. It covers the tool's purpose, search/filter capabilities, result explanation behavior, and meta limitations. The only gap is the lack of explicit parameter combination logic (e.g., AND semantics across filter groups), but this is minor given the schema's completeness.

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 the baseline is 3. The description groups parameters (Project, cluster, category, grade, sentiment, time) but does not add deeper semantics beyond the schema's per-parameter descriptions. It usefully summarizes the filter landscape but does not compensate with extra detail.

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 states the action ('Search and filter') and the resource ('evidence-graded crypto developments'), and lists specific searchable fields and filter types. It distinguishes the tool from sibling list tools by focusing on its search/filter nature and self-explaining results, making its purpose obvious.

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 establishes clear context: it is the search-and-filter tool for intel, with a comprehensive list of filter dimensions. However, it does not explicitly name alternatives or exclusion conditions (e.g., use get_intel for a single intel), so the guidance is strong but not fully explicit about when not to use 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 destructiveHint=false. The description adds useful behavioral context beyond this, including default sorting by trend and cursor-based pagination, giving the agent a clearer picture of response 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?

The description is three concise sentences that front-load the purpose, then efficiently list filters and key behaviors. No redundant or extraneous information; every sentence adds value.

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

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

For a filtered-list tool with good annotations, an output schema, and 100% parameter coverage, the description is largely complete. It covers the purpose, filterable fields, default sort, and pagination. Minor gaps like how filters combine (AND/OR) are not addressed, but schema and annotations compensate significantly.

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% with each of the 14 parameters richly described. The description mentions filter fields and the cursor, but these are already covered in the schema. It adds marginal value by highlighting the default sort and next-page cursor, but does not go beyond baseline.

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 states 'Find Projects tracked by AIXBT' and lists multiple filter dimensions, making the tool's purpose unambiguous. It does not explicitly contrast with sibling tools like get_project, but the plural 'Projects' and list-style filtering inherently distinguish it.

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 implies usage for listing/filtering projects but provides no explicit guidance on when to use this tool versus alternatives such as get_project for singular lookups or other list tools like list_intel. The absence of explicit alternatives or exclusions keeps this at baseline.

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 destructiveHint=false, covering the safety profile. The description adds value by disclosing the credential requirement, the ordering behavior (most recent publication/revision), and the limited scope (metadata and previews not full content). This goes 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?

Two sentences, front-loaded with the core purpose, followed by filtering, credential requirement, and alternative tool. Every clause earns its place without redundancy or fluff.

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 output schema exists (and likely documents pagination via cursor/limit), the description covers purpose, ordering, filtering, authentication, and directs to get_report for full content. It doesn't explicitly mention pagination, but the schema does, so the description is sufficiently complete for a list 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 100%, so all five parameters already have descriptive text. The description's mention of 'Filter by Topic or Project' loosely maps to topicId/projectId/projectSlug but adds no new detail beyond the schema. It does not explain cursor/limit semantics beyond what the schema provides, so baseline 3 is appropriate.

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 states a specific verb ('List') and resource ('metadata and previews for AIXBT's latest published report on each Topic'), with explicit details about ordering and filtering. It distinguishes itself from get_report by noting the preview scope and pointing to get_report for full reports.

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 clear context for when to use the tool: for metadata/previews of latest reports, with an explicit alternative ('use get_report for the full report'). It also notes a prerequisite ('Requires a credential'). However, it doesn't explicitly exclude other sibling list tools like list_topics, so it's not 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?

The description adds behavioral context beyond the annotations: it is available without a credential and is refreshed hourly. These details inform the agent about access requirements and data freshness, supplementing the readOnlyHint and destructiveHint.

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 concise and front-loaded, with every sentence adding value: stating the resource, result contents, optional filter, and access requirement. There is no wasted wording.

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 list tool with one optional parameter, the description covers purpose, result contents, filtering, and access. Output schema and annotations handle return values and safety, so nothing critical is missing.

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

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

Schema description coverage is 100% for the single projectId parameter, and the description only rephrases the schema's meaning without adding new details. Since the schema already documents the parameter, the description does not enhance understanding beyond 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 clearly states the tool lists the current crypto Topic leaderboard, specifies the refresh cadence, and mentions result contents. This distinguishes it from sibling tools like get_topic (singular) and other 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?

The description provides clear usage context: no credential is required, and projectId can be provided to filter results. However, it does not explicitly name alternative tools or state when not to use this 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 already declare readOnlyHint=true and destructiveHint=false. The description adds value by enumerating exactly what information is revealed (identity, entitlements, rate limits, history access), going beyond the annotation-only safety profile.

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 output, followed by a concise usage directive. No wasted words.

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

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

For a zero-parameter tool with an output schema, the description fully covers what the tool does and when to use it. The output schema handles return structure, so no further explanation is needed.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty properties). Per the rubric, 0 params gives a baseline of 4. No additional parameter info is needed, and the description adds no irrelevant parameter details.

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 states the tool's purpose: 'Show the current credential's identity, entitlements, rate limits, and history access.' This uses a specific verb ('Show') and resource (current credential), and clearly distinguishes it from sibling tools that retrieve intel, projects, or reports.

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 tells when to use: 'Use this before gated or historical requests.' This provides clear contextual guidance and implicitly distinguishes from sibling get/list tools that are not about access checking.

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