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 at all, the description must carry the behavioral burden, and it partially does: it discloses the corpus size (1040+) and that results include 'full structured metadata'. It says nothing about pagination/result-cap behavior, whether the total match count is returned, or ordering of results — gaps that matter for a search tool with an 8-parameter filter surface.

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, zero waste. The capabilities list comes first and the return-value statement second, so an agent gets the actionable information 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 filter-heavy, read-only search tool with no output schema, the description covers what is searched and what comes back ('matching tools with full structured metadata'), and the schema fully documents all 8 optional parameters. It falls short only on result-set mechanics — result ordering, whether a total count is included, and how to page beyond limit.

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 each parameter already carries a rich description, including enum vocabularies and the subtle 'unknown excluded either way' semantics for api/opensource. The description's facet enumeration mirrors those parameter names without adding semantics beyond the schema, 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 states a specific verb and resource ('Search the BroFindAI directory of 1040+ AI tools') and enumerates every filter facet: keyword, category, pricing, platform, tags, API availability, open-source. That makes it clearly distinguishable from list_tags/list_categories/get_tool_details by name alone, though it never explicitly names those siblings as alternatives.

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

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

Usage is implied by the facet list — an agent can infer this is the entry point for discovering tools matching criteria. However, there is no explicit when-to-use/when-not statement, no mention of when to prefer get_tool_details over this tool, and no mention that list_tags should be called first to get tag vocabulary (that hint lives 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.