Bro Find AI

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

With no annotations available, the description bears the transparency burden. It does disclose the return contents ('Returns name, description, URL, category, pricing, votes, and metadata'), which is helpful, but it does not mention behavior for invalid or missing slugs, authentication, rate limits, or whether the operation is read-only.

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, efficient sentence that immediately states the action, identifier, examples, and return fields. There is no redundant wording 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?

There is no output schema, so the description's explicit listing of return fields fills that gap well. Combined with the fully documented slug parameterchers, the description provides enough context to invoke the tool correctly, though it omits error or edge-case behavior.

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 already documents the slug parameter with 100% coverage, including the format 'lowercase, hyphenated'. The description adds value with concrete examples like 'chatgpt' and 'midjourney' and clarifies that the slug identifies a specific tool, but it does not significantly extend the schema's meaning.

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

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

The description states a specific verb ('Get'), resource ('full details of a specific AI tool'), and identifier ('slug identifier') with concrete examples. It clearly communicates the operation and scope, though it does not explicitly contrast it with sibling tools like search_ai_tools or list_categories.

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 the tool: when you already have a slug and need full details for that specific tool. It does not explicitly mention alternatives or when not to use it, so guidance is adequate but left to inference.

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

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

With no annotations, the description must carry the behavioral burden. It does so by stating this is a non-mutating listing operation and specifying the returned information (categories plus per-category tool counts). Sorting or pagination details are omitted, but those are minor for a zero-parameter directory listing.

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

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

A single, front-loaded sentence that names the action, scope, and output with no filler.

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

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

For a parameterless list tool without an output schema, the description covers the essential purpose and return content. It could add ordering or inclusion criteria, but the core information an agent needs to select and invoke it is present.

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

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

The tool has zero parameters, so there is no schema to compensate. The baseline of 4 applies, and the description correctly avoids inventing parameter-like 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 uses a specific verb ('List') and identifies the exact resource ('AI tool categories in the BroFindAI directory') plus the distinguishing output ('number of tools in each category'). This clearly separates it from siblings such as get_tool_details and list_tags.

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: when a full taxonomy of categories with tool counts is needed. It does not explicitly contrast with list_tags or search_ai_tools, so I cannot give full credit, but the purpose 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?

No annotations are provided, so the description carries the full burden. 'Browse' implies a read-only listing, but the description does not disclose pagination behavior, return shape, authentication needs, or other behavioral details. It is not misleading, but it is minimal.

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 concise, front-loaded sentences with no filler. Every phrase adds useful information about what the tool does and how it can be narrowed.

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?

It is adequate for a simple optional-parameter listing, but it leaves gaps around output/return expectations and sibling routing. Modern annotations and output schema are absent, so the description alone is only minimally complete.

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

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

The input schema already documents all three parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond restating category and keyword filtering, and it does not clarify formatting or defaults.

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 ('Browse') and a specific resource ('BroFindAI MCP servers directory'), and names the two main filtering modes. It is clear and distinct from sibling categories tools, though it does not explicitly distinguish itself from search_ai_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 offers no guidance on when to prefer this tool over siblings like search_ai_tools or list_categories, and no exclusions are given. The filtering phrases imply usage, but the description does not say when this tool is the right choice versus alternatives.

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?

No annotations are provided, so the description carries the full burden. The verb 'List' implies a read-only operation, and the description specifies the output content (tags, platforms, counts, API/open-source status). However, it does not explicitly state that it is non-destructive, nor does it mention any limitations like pagination or performance. For a simple list operation this is acceptable but not fully explicit.

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 wasted words. The primary purpose is front-loaded, and the usage note is added efficiently. It is concise and well-structured.

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 no parameters, no output schema, and no annotations, the description fully covers what it returns (tags, platforms, counts, API/open-source status) and why to use it (discover filter values for search_ai_tools). Nothing essential is missing for an agent to call it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information, which is appropriate since there are no parameters to document.

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 clear resource ('every tag and platform in use across the directory') and additional detail ('tool counts, plus how many tools have a known/unknown API and open-source status'). It clearly distinguishes itself from siblings like list_categories and list_mcp_servers by focusing on tags/platforms and their counts.

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 states when to call this tool: 'Call this to discover valid filter values for search_ai_tools.' This provides a clear use case, though it does not explicitly mention alternatives or when not to use it. It gives enough context to guide an agent toward the right tool for discovering filter values.

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?

With no annotations, the description must carry the behavioral burden. It states that matching tools are returned with 'full structured metadata', but it does not disclose filter combination logic, default/max limits, or response shape. It is not misleading, but it adds only a general return statement.

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 resource and search dimensions, followed by the return behavior. No filler or repetition; appropriately sized for 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?

For an 8-parameter search tool with no output schema and no annotations, the description is a bit thin: it does not explain what 'full structured metadata' includes, how multiple filters combine, or the default limit. The schema covers parameter semantics, so the tool is callable, but the description alone would leave an agent guessing about output and edge-case behavior.

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's list of search dimensions (keyword, category, pricing, platform, tags, API availability, open-source) mirrors the schema parameters but adds no new semantic detail beyond what the schema already documents.

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 ('Search'), a concrete resource ('BroFindAI directory of 700+ AI tools'), and enumerates the filter dimensions. This clearly separates it from sibling tools like list_tags or get_tool_details, which are list/detail operations.

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

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

No explicit when-to-use or alternative routing is given. The description implies a search use case but does not say when to prefer search_ai_tools over list_categories or get_tool_details, nor does it mention list_tags for vocabulary (that hint appears only in the schema).

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