Free, source-checked directory of AI agent tools, MCP servers and skills, with read-only search.
Scored across 5 tools
Each tool has a recognizable role: id-based fetch (get_gear), ranked lookup (search_gear), category counts (list_categories), skill install listing (list_skills), and cross-group shortlist (recommend_stack). The only soft overlap is search_gear vs recommend_stack, both of which match query words against entry text, but the descriptions differentiate ranked search from a spread-across-groups shortlist with quotes.
All five names follow a clean verb_noun snake_case pattern (get_gear, search_gear, list_categories, list_skills, recommend_stack). Verbs also map sensibly to semantics: get for single fetch, list for enumeration, search/recommend for discovery.
Five tools is well within the 3-15 sweet spot for a read-only catalog server. Each tool covers a distinct access pattern (single fetch, search, category summary, skills listing, curated recommendation) with no filler.
The read-only catalog lifecycle is mostly covered: discovery via search_gear/recommend_stack, detail via get_gear, and browse via list_categories/list_skills. A gap remains because list_categories only returns counts, with no tool to enumerate entries within a specific category, forcing agents to round-trip through search_gear.
Get one Gearlist entry by its id, as returned by search_gear, with what was checked and when. Entries are documentation-checked only. Nothing was installed or audited.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id, for example 'playwright-mcp'. |
| Name | Required | Description |
|---|---|---|
| entry | Yes | |
| notice | Yes | |
| checked | Yes | What Gearlist checked for this entry, copied from its own fields. A field the entry does not have is left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add something else — and it does, by disclosing that entries are documentation-checked only and nothing was installed or audited. That trust caveat materially affects how an agent should present the result and is not derivable from structured fields.
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 tight sentences, front-loaded with the verb and resource, with no filler. The second sentence's two clauses are near-restatements of each other ('documentation-checked only' / 'nothing installed or audited'), a small redundancy that reinforces rather than wastes space.
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 one-parameter read tool with an output schema, full annotation coverage, and a stated data-trust caveat, almost nothing an agent needs is missing. The only gap is behavior on a missing or invalid id, which the description does not address.
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 id's format example lives in the schema, so the description adds little parameter-level detail. Its only contribution is provenance ('as returned by search_gear'), which is useful but minor; 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?
States a specific verb and resource ('Get one Gearlist entry by its id') and scopes it to a single record, which cleanly separates it from the plural, query-based sibling search_gear. It also ties the id back to search_gear's output, so the agent knows exactly which tool produces the input.
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 'as returned by search_gear' implicitly prescribes the workflow: search first, then fetch details by id. It does not explicitly say to avoid this tool for bulk retrieval or what to do if the id is unknown, but the routing context is clear enough for a single-record getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Gearlist categories with the number of entries in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| categories | Yes | |
| total_entries | Yes | |
| catalog_updated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral detail is that counts accompany each category, which is return-shape information that the output schema already supplies, so it adds limited value beyond structured data.
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?
One short sentence, front-loaded with the action and resource, with the returned field named at the end. No filler, no 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?
A parameterless, read-only, closed-world listing tool backed by a full annotation set and an output schema. Nothing an agent needs in order to call it correctly 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 tool takes zero parameters (additionalProperties: false, empty object), so there is nothing for the description to disambiguate. Baseline 4 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?
"List the Gearlist categories" gives a specific verb and resource, and adds that each item carries an entry count. The purpose is unambiguous against siblings like get_gear, search_gear and recommend_stack, though the description never explicitly contrasts itself with list_skills, the nearest structural analogue.
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 statement of when to call this versus get_gear or search_gear; the implied usage (enumerate the taxonomy, presumably before filtering or browsing) must be inferred. For a zero-argument enumeration tool this is adequate but not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the agent skills published in the Gearlist repository, with the command that installs each one. Ask the human before running any install command.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| skills | Yes | |
| repository | Yes | |
| install_all | Yes | Installs the skills you pick from this repository. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the disclosure that results contain runnable install commands and the explicit instruction to seek human approval before executing them. That is meaningful behavior beyond structured fields, though it says nothing about result size or ordering.
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 short sentences, front-loaded with what is listed and what each entry contains, then the safety caveat. No redundant restatement of the title or annotations, and every clause carries 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?
For a zero-parameter, read-only listing tool with an output schema documenting return values, the description supplies exactly what the schema cannot: that entries pair a skill with an install command and that execution requires human sign-off. Nothing an agent needs to call this correctly 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param schema applies. The description correctly avoids inventing filtering options that the schema does not support.
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 gives a specific verb and resource ('List the agent skills published in the Gearlist repository') plus the payload detail that each entry includes its install command. This clearly separates it from the gear-oriented siblings (get_gear, search_gear, recommend_stack) without needing to open the 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?
Usage is implied by the listing nature of the tool, and the closing sentence establishes a guardrail for the embedded install commands. However, it never states when to reach for this versus a sibling, nor any preconditions for calling it — an agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a short set of Gearlist entries whose own text shares the most words with a job you describe, spread across groups, quoting where each match appears. Matches are on words, so check each entry suits the job before suggesting it.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | The job in plain words, for example 'test my web app in a real browser'. Common words such as 'my' or 'the' are ignored. | |
| limit | No | How many entries to return, from 1 to 10. Default 6. |
| Name | Required | Description |
|---|---|---|
| job | Yes | |
| count | Yes | Items returned. |
| items | Yes | |
| match | Yes | found: each item has at least half of the job's words, and at least two when the job has two or more, in its name, id, group, description or audience. none: no entry does. |
| words | Yes | The job's words that were looked for, after common words were dropped and word endings trimmed. |
| notice | Yes | |
| next_step | Yes | What to do with the result. |
| total_matches | Yes | Entries that fit the job, before the limit. |
| catalog_updated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, closed-world), so the description correctly spends its words elsewhere: it discloses that matching is lexical not semantic, that results are diversified across groups, and that match locations are quoted. The lexical-matching caveat is exactly the kind of behavioral detail an agent needs and cannot get from 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, no filler, and the mechanism is front-loaded. The second sentence is a useful caveat rather than padding, keeping the whole definition tight.
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 two-parameter read-only lookup with a full input schema and an output schema, the description covers mechanism, result shaping, and the interpretive risk. An agent has everything needed to call it and to sanity-check what it gets back.
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 both parameters fully documented including the stop-word behavior and the 1-10 limit range. The description only hints at sizing via 'a short set' and adds nothing about format or phrasing beyond the schema, so the baseline 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?
The description states a specific verb and resource (find Gearlist entries) plus the actual matching mechanism: word overlap, spread across groups, with quoted match locations. That mechanism meaningfully separates it from siblings like search_gear, though it never names or contrasts an alternative explicitly.
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 rather than stated: you describe a job and get suggestions. The closing caveat ('check each entry suits the job before suggesting it') is genuine guidance about result quality, but there is no explicit when-to-use versus search_gear or get_gear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Gearlist catalog of source-checked AI agent tools, MCP servers and skills. Matches words in the name, category, description, audience and access notes, best match first. Each result includes its access notes, which you should show the human. Entries are documentation-checked only, not installed or audited.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many entries to return, from 1 to 50. Default 10. | |
| query | Yes | Words to look for, for example 'browser automation' or 'send email'. Entries that match every word come first, then entries that match some of them. Common words such as 'the' or 'tool' are ignored. Use an empty string with a category to list that category. | |
| category | No | Optional. Limit results to one category. list_categories gives the names and counts. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Results returned. |
| match | Yes | all: every result matches every word. partial: some results match only some words, listed after the full matches. none: nothing matched. |
| query | Yes | |
| notice | Yes | |
| results | Yes | |
| category | No | |
| full_matches | Yes | Entries that match every word. |
| total_matches | Yes | Entries that match at least one word. |
| catalog_updated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add genuinely new context: which fields are matched, that results are ordered best-match-first, and the important provenance caveat that entries are "documentation-checked only, not installed or audited." That caveat is real behavioral information an agent needs before recommending a tool.
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?
Four short sentences, front-loaded with purpose, then matching behavior, then the output instruction and caveat. Every sentence carries information; there is no filler, though the sentence about showing access notes to the human is more of a policy reminder than tool description.
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, the description need not explain return shapes, and it correctly focuses on matching semantics, ranking, and the trust caveat. The remaining gap is sibling differentiation — nothing tells the agent when to prefer get_gear or recommend_stack over a free-text search.
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, but the description adds meaning the schema does not: the specific fields searched (name, category, description, audience, access notes), which tells the agent how to phrase a query. The ranking rule and empty-string-plus-category pattern are duplicated from the schema rather than extended.
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 and resource ("Search the Gearlist catalog of source-checked AI agent tools, MCP servers and skills") and describes the matching scope. It is clear what the tool does, but it never distinguishes itself from siblings like get_gear, list_skills or recommend_stack, so an agent must infer the boundary.
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 keyword-search framing, and the description adds an output-handling instruction ("show the human" the access notes). However, it gives no explicit when-to-use versus get_gear or recommend_stack, and the useful routing hint for listing a whole category lives in the schema, not the description.
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.
get_gearlist_categorieslist_skillsrecommend_stacksearch_gearRead-only search over 2,065+ AI agent tools and 276 MCP servers. Free, no sign-up needed.
Search MCP servers, agent skills and open-source AI projects, plus AI tools. Read-only.
Search a curated directory of 800+ AI agents, MCP servers, and agentic tools.
Search and inspect source-pinned agent skills, plugins and tools through a free public MCP.
Add one secure layer between your agents and this server.
