All details of one tool by id: English and Polish links, app store links, descriptions in both languages and every rating with its source and date.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tool id from search_tools, e.g. 'tile-calculator' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses what the response includes (bilingual links, app store links, descriptions, ratings with source and date), which implies a read-only fetch, but it never states read-only semantics, auth requirements, or error behavior for an invalid id.
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 leads with the purpose and then enumerates the payload. The field enumeration is slightly list-heavy but every item conveys distinct return 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?
There is no output schema, so the description reasonably carries the return-value disclosure and does so at a useful level of detail for a one-parameter lookup tool. Only the error/missing-id case is left unaddressed, which is a minor gap.
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% and the schema already documents the id including an example. The description's 'by id' adds no meaning beyond the schema, so the baseline of 3 applies.
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: retrieve all details of one tool by id. It is distinguishable from list_categories and search_tools by being the single-item lookup, though it never names those siblings explicitly to reinforce the split.
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?
'by id' plus the schema note that the id comes from search_tools implies the usage flow (search first, then fetch detail), but there is no explicit when-to-use or when-not-to-use statement or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the categories with a description and the number of tools in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the return content (category descriptions and per-category tool counts), which is genuinely useful, but says nothing about ordering, pagination, or whether the list is exhaustive. For a harmless zero-param read this is acceptable but thin.
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 sentence that leads with the action and resource and then specifies the payload. No filler, no redundancy, nothing that could be cut without losing information.
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, and the description compensates by describing what each entry contains (description + tool count). For a simple, parameterless listing tool this is essentially complete; only return ordering/format remains unspecified.
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 has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's mention of per-category fields is a return-value detail, not a parameter 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 states a specific verb (List) and resource (categories) and even clarifies the payload: a description plus tool count per category. It does not explicitly contrast with siblings get_tool or search_tools, but the resource is distinct enough that confusion is unlikely.
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 only implied: as a zero-parameter enumeration tool it is obviously a discovery/browsing entry point, and an agent can infer that from the name and payload description. No when-to-use versus alternatives (e.g., use this before search_tools to pick a category) is stated, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find free home renovation tools for a task: material or cost calculators (paint, tiles, flooring, concrete, drywall, roofing, insulation, HVAC, electrical, solar), contract and estimate templates, room planners and 3D design, contractor directories and company checks (USA, UK, Poland), measuring and colour-preview apps, forums. Queries may be in English or Polish. rating is a public user rating with its review count (App Store or SourceForge); maintainer_tool marks tools by the list's maintainer. An empty result means nothing in the list fits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 8 | |
| query | No | What the user needs, e.g. 'tile quantity', 'renovation contract', 'floor plan', 'kalkulator farby' | |
| category | No | Limit to one category | |
| language | No | pl: prefer Polish links and descriptions and tools with a Polish version; default en | |
| min_rating | No | Only tools with a user rating at least this (tools without ratings are excluded) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it usefully discloses return-field semantics (`rating` is a public App Store/SourceForge rating with review count, `maintainer_tool` flags list-maintainer tools) and the meaning of an empty result. It stops short of noting rate limits or auth, but for a read-only search this is solid disclosure.
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?
Purpose is front-loaded and the sentence ordering (what it finds, then language, then field semantics, then empty-result behavior) is logical. The long parenthetical enumeration is dense but earns its place by defining searchable scope.
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 zero required parameters, the description does the necessary work of explaining returned fields (`rating`, `maintainer_tool`) and the empty-result outcome. Nothing critical to invoking it correctly is missing, though sibling routing could be more explicit.
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 schema already documents all five parameters including enums and the min_rating exclusion rule. The description adds only the language note (English or Polish queries), which is baseline-level reinforcement rather than new 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?
States a specific verb (search/find) and resource (free home renovation tools) and enumerates the concrete content types the corpus covers (calculators, templates, planners, directories, apps, forums). This clearly distinguishes it from get_tool (fetch one) and list_categories (enumerate taxonomy) without needing either schema.
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 clear context for when to use it — searching by a user task, with query examples and supported languages — and explains the empty-result case. It does not explicitly name the sibling alternatives (get_tool for details, list_categories for browsing), so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_toollist_categoriessearch_toolsScored across 3 tools
Each tool has a clearly distinct function: list_categories enumerates categories, search_tools finds tools by query, and get_tool fetches full detail for a single id. There is no overlap—an agent can unambiguously pick the right tool for browsing versus searching versus drilling into a specific item.
All three names follow a clean verb_noun snake_case pattern (list_categories, search_tools, get_tool), with the domain noun consistently referring to tools/categories. This is a fully predictable convention.
Three tools form a minimal but coherent surface for a read-only directory service: browse categories, search, and fetch details. It is slightly thin—there is no equivalent of a plain 'list all tools'—but each tool clearly earns its place.
For a read-only tool directory, the list/search/get trio covers the essential browse-and-inspect lifecycle, and search_tools even documents edge cases like empty results and bilingual queries. Minor gaps like bulk listing or filter facets exist but are workaround-able via search.
API Tool Calls: Home cost planners, proofreading, QR and barcodes, page to Markdown, SEO checks and recalls. Free agent tools: 20 calls/day per IP, no key.
Search 5000+ software tools with structured, labelled facts. No pay-to-rank.
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
Free search across ~35,000 agent tools (x402 bazaar + MCP registry) by plain-language need.
