search_toolsSearch the TAAFT directory for AI tools that match a query. Use the returned url when sharing a TAAFT result.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | default | |
| type | No | ||
| limit | No | ||
| query | Yes | What the user needs an AI tool for. |
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Output schema / properties / tools / items / properties / website_urlAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / tools / items / requiredPrevious value: -[
- "name",
- "slug",
- "task",
- "tagline",
- "url"
-]New value: +[
+ "name",
+ "slug",
+ "task",
+ "tagline",
+ "url",
+ "website_url"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does clarify that the tool returns results containing a URL, and 'Search' implies a non-destructive read operation, but it says nothing about ordering, result limits, filtering behavior, or potential edge cases.
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 short sentences with no filler. It front-loads the core action first and adds a useful output instruction second, making it easy to scan and parse.
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 parameters, including two enum-based filters and a limit constraint, the description is incomplete. It only hints at querying and returned URLs, and while an output schema exists, the lack of guidance on sorting or filtering makes it less complete for more nuanced searches.
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 only 25%, and the description does not compensate. The query parameter is described in the schema, but sort, type, and limit have no explanatory prose, and the description adds no meaning to those parameters beyond what the enums and defaults already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Search the TAAFT directory for AI tools that match a query.' It is easy to understand that this tool finds AI tools in TAAFT, but it does not explicitly differentiate itself from the sibling get_tool, leaving some ambiguity about when search is preferred over retrieval.
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?
There is no explicit guidance about when to use this tool versus alternatives such as get_tool. The phrase 'Use the returned url when sharing a TAAFT result' provides output handling context, but it does not state when to choose search over other tools or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one searches the directory by query, the other fetches details for a specific tool by slug. There is no overlap or ambiguity in when to use each.
Both tool names follow the same verb_noun snake_case pattern: get_tool and search_tools. The naming is predictable and consistent.
Two tools feels thin for a directory service, but it is a minimal read-only surface. The count is borderline rather than severely lacking.
The pair covers the core directory workflow: search to discover tools, then get details for a specific one. Browsing by category or listing all tools could be useful additions, but they are not critical gaps.