Find llms.txt, docs, MCP servers, skills and CLIs for a tech stack, for coding agents.
Scored across 3 tools
Each tool targets a distinct access pattern: get_topic retrieves one entry by id, list_topics enumerates the catalog, and search does full-text lookup. The list_topics vs. search boundary is the only mild overlap, and descriptions clarify it (list for candidates, search for matching text).
get_topic and list_topics follow a clean verb_noun pattern on the same noun, which is predictable. 'search' is a bare verb without a noun, a minor deviation but still immediately readable.
Three tools is on the thin side but well-matched to a read-only cataloging domain: one lookup, one enumeration, one search. No surface feels padded or redundant.
The core read paths (browse, lookup, search) are covered, but there is no direct way to fetch or inspect an individual source/llms.txt by id, nor any role- or region-filtered listing. Agents must go through topic retrieval or keyword search to reach source-level content, which is a workable but notable gap.
All sources (llms.txt, docs, MCP servers, skills, rules), detection signals and the role of one tool, by id such as vercel, nextjs or drizzle.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Topic id, as returned by search or list_topics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully enumerates the categories of data returned, which matters since there is no output schema, but says nothing about behavior on an unknown id, response size, or whether full content versus summaries are returned.
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 compact sentence with no filler. It is slightly front-loaded on return contents rather than the action, and 'the role of one tool' is an awkward phrase, but nothing is wasted.
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 lookup with no output schema, the description does the minimum-plus job of listing what comes back. It leaves open what a topic actually represents and what happens when the id is not found, which an agent may need to know before calling.
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; the description earns above that by supplying example id values (`vercel`, `nextjs`, `drizzle`), which reveal the expected lowercase slug convention better than the schema's generic 'Topic id' text.
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 the resource (a topic, identified by id) and enumerates what the response contains: sources such as llms.txt, docs, MCP servers, skills and rules, plus detection signals. Concrete example ids (`vercel`, `nextjs`, `drizzle`) make the resource type tangible. It falls short of 5 because it never contrasts with siblings list_topics/search, and the phrase 'the role of one tool' is ambiguous about whether a topic is a tool or a technology.
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: the requirement that an id be supplied suggests the lookup pattern (find an id via search or list_topics, then fetch details here), but the description itself states no when-to-use rule and names no alternative. An agent must infer the search-then-get workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool in the catalog with its id, name, role and region, without sources. Use it to find candidates per role, then get_topic and their llms.txt sources to compare them.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Only this region id, e.g. cloud, frameworks, standards or clis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuinely useful payload trait beyond the annotations: results exclude sources, which explains why a follow-up get_topic call is needed. It omits any note on result size, pagination, 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 tight sentences with no waste; the return shape comes first and the workflow guidance second. Every clause earns its place.
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, the description usefully names the returned fields and the excluded 'sources' field, which is exactly what an agent needs to plan the next call. Absence of pagination/size guidance is the only remaining gap for a read-only list tool.
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 the single region parameter is documented in-schema with examples, so the baseline applies. The description never mentions the region filter, so it adds no semantic value on parameters.
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 (list) and resource (topics) and enumerates the returned fields (id, name, role, region), which lets an agent distinguish it from get_topic. The phrase 'every tool in the catalog' is slightly confusing given the tool is named list_topics, creating minor ambiguity about whether topics and tools are the same entity.
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?
'Use it to find candidates per role, then get_topic ... to compare them' gives a clear usage scenario and names the natural follow-up sibling. It does not explicitly state when not to use it versus search, the other sibling, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over tools (topics) and their sources. Matches names, roles, regions, detection signals (files, dependencies, env vars), source titles and URLs. Every word must match, as a prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only return sources of this kind | |
| limit | No | Maximum number of topics, default 10 | |
| query | Yes | Words to search for, e.g. "database", "vercel mcp" or "turbo.json" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the description doesn't need to re-state safety. It does add non-obvious matching semantics: every word must match and matching is prefix-based, which materially changes how an agent forms a query and is not visible from the schema.
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 tightly packed sentences with no filler. The core action is front-loaded, and the matching rules follow immediately in a single sentence that every clause earns.
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?
No output schema exists, but the tool is a simple read-only search with three fully documented parameters, and the description covers matching semantics. Return shape is not described, but that is a minor gap for a read-only search over three params.
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. The description goes beyond the schema by explaining what the query string is matched against (names, roles, regions, detection signals, source titles and URLs) and the AND/prefix matching rule, which is the key semantic an agent needs to construct a valid query.
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 opens with a specific verb and resource: 'Full-text search over tools (topics) and their sources', then enumerates the searchable fields. It is clear what the tool does and how it differs in spirit from get_topic/list_topics, though it never names those siblings 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?
The matching fields imply when to reach for search rather than list_topic or get_topic, but no sentence states the condition or names an alternative. An agent must infer from the sibling names that search is for full-text lookup versus enumeration or direct fetch.
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_topiclist_topicssearchRecommends open-license agent skills (SKILL.md) for a project from its stack and task tags.
Find MCP servers, skills, plugins, agents, prompts and rules for any task.
Search and fetch AI agent skills, rules files and MCP servers indexed from GitHub.
Search AI agent tools, APIs, MCP servers and Agent Skills in the Swarmnest directory.
Add one secure layer between your agents and this server.