Read-only MCP server for StackPick, an editorial directory of AI dev tools ranked by job. List categories, get top picks, compare or search tools, and read recent release notes. No API key.
Scored across 6 tools
Each tool targets a distinct operation: single lookup, category ranking, multi-tool comparison, search, category listing, and release notes. The only borderline pair—get_best_tools and list_categories—is separated by whether scores/ranks or category membership are returned.
Five of six names follow a verb_noun snake_case pattern (compare_tools, get_best_tools, get_tool, list_categories, search_tools). latest_releases is noun-first and breaks the pattern, but overall readability and consistency remain strong.
Six tools is well within the ideal 3-15 range for a read-only directory/ranking API. Each tool covers a distinct workflow—search, lookup, compare, category browsing, and changelog—without filler.
The surface covers the core workflows for a tool-ranking directory: discovering categories, searching/filtering tools, retrieving a tool, getting category leaders, comparing candidates, and checking release notes. No obvious retrieval or lifecycle gap remains for this public-data domain.
Side-by-side scores and ranks for two or more tool slugs. Each rank is within that tool's category. Rankings are never paid.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Two or more tool slugs to compare. Order is preserved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds two genuinely useful semantic facts — ranks are category-relative and "never paid" (provenance/bias disclosure) — but says nothing about result shape, missing-slug handling, or the 8-item ceiling.
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?
Three short sentences, front-loaded with what the tool returns before the qualifying details. Nothing is redundant and nothing is padding.
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 does have to carry return-value semantics, and it partially does (scores, ranks, rank scope). It lacks any hint about the response structure (per-tool objects, unknown-slug behavior), which is the main remaining gap for a single-parameter read 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 already documents minItems 2 / maxItems 8 and order preservation, so the baseline is 3. The description reinforces "two or more" but adds no format guidance for slugs (e.g., where to get them), which would have been the only real value-add.
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 ("Side-by-side scores and ranks") plus the input shape (two or more tool slugs), and clarifies that ranks are category-relative. It never names a sibling (get_tool, get_best_tools, search_tools), so an agent must infer the boundary between comparing several tools and fetching one, but the core purpose is unambiguous.
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 "two or more" phrasing implicitly signals when to reach for this over a single-tool lookup, but there is no explicit when/when-not statement and no named alternative. An agent can guess the routing but is not told, for example, whether this replaces calling get_tool repeatedly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked tools for one category slug, highest score first. Scores and order match the category page. Rankings are never paid.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug from list_categories, such as ai-code-editors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world, so safety is covered. The description adds genuine non-obvious context — that ordering mirrors the category page and rankings are never paid — but says nothing about how many results are returned or whether the list is capped.
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?
Three short sentences, zero filler, with the output ordering rule front-loaded. Every sentence carries information an agent could act on.
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 single-parameter read tool with full annotation coverage and no output schema, this is nearly complete. The only real gap is result-set size/pagination behavior, which an agent would want to know before assuming it received the full ranking.
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?
Only one parameter with 100% schema coverage, including an example slug and minLength, so the schema does the heavy lifting. The description adds nothing about the slug beyond 'one category slug', which is the baseline 3 case.
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 ('ranked tools for one category slug') plus the ordering rule ('highest score first'), so the agent knows exactly what comes back. It does not name a sibling to contrast with, but the scoping to a single category slug naturally separates it from search_tools and compare_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?
Usage is only implied: the agent can infer this is the call for 'best in category X', but the description gives no explicit when-to-use vs search_tools/compare_tools, and no exclusions. The prerequisite chain (slug comes from list_categories) is stated only 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.
One StackPick tool by slug, including its category rank, score, website, and last reviewed date. Rankings are never paid.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, such as cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is fully covered. The description adds a data-integrity note ('Rankings are never paid') and names the returned fields, which is useful context, but says nothing about behavior for an unknown slug or how missing tools are signaled.
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 the resource and key, then the payload contents. The closing trust claim about unpaid rankings is brief and earns its place as editorial context, though it is not strictly needed to invoke the tool.
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 full annotation coverage, the description carries the remaining burden by listing the returned fields in lieu of an output schema. Only the not-found behavior and slug format edge cases remain uncovered, 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 coverage is 100% and the single parameter is documented with an example ('cursor'), leaving nothing for the description to clarify. 'By slug' merely restates the schema, so the baseline of 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 resource (a single StackPick tool) and its key (slug), and enumerates what comes back: category rank, score, website, last reviewed date. That clearly separates it from search_tools or get_best_tools, which return collections. It doesn't explicitly name which sibling to use instead when the slug is unknown, so it stops short of 5.
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 'One StackPick tool by slug' implies a single-record lookup rather than discovery, which is enough to infer it complements search_tools. However, there is no explicit statement of when to use this versus search_tools or get_best_tools, and no mention of what to do when the slug isn't known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Newest StackPick release notes, the same records as the changelog, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many releases to return, newest first. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds the meaningful behavioral detail of reverse-chronological ordering and record-set equivalence, but says nothing about truncation, pagination, or what happens when limit exceeds available releases.
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 with the distinguishing property (newest first) placed last for emphasis and zero filler. Nothing could be removed 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?
The tool is simple and read-only with one optional parameter, so little is required. However, with no output schema, the agent receives no description of what a release record contains, and the description does not say whether results are ever empty or how the equivalent-changelog claim should affect usage.
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 'limit' parameter is fully documented in the schema with bounds (1-50) and default (10). The description adds only the ordering cue 'newest first', which is already implied by the schema text, 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?
Identifies the resource precisely (StackPick release notes) and its ordering (newest first), and disambiguates from siblings like compare_tools/get_best_tools by framing it as a changelog-style feed. It loses a point only because it's a noun phrase with no verb, so the 'list/retrieve' action is inferred rather than stated.
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 when-to-use or when-not-to-use guidance, and none of the sibling tools are named as alternatives. The clause 'the same records as the changelog' hints at equivalence but there is no changelog tool in the sibling list, so it does not route the agent anywhere actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List StackPick jobs and the tool slugs ranked in each one. Order matches the category pages. Rankings are never paid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely new context — result ordering matches the category pages and rankings are never paid — but says nothing about result size, paging, or whether all categories are returned at once.
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?
Three short sentences with no filler, and the content payload (jobs plus ranked slugs) is front-loaded. The 'Rankings are never paid' line is arguably promotional but does convey a real ordering guarantee.
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 must characterize the return value, and it only gestures at it ('jobs and the tool slugs ranked in each one') without stating shape, count, or whether slugs are bare identifiers. For a simple zero-param browse tool this is close to adequate but leaves the agent guessing about response structure.
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 the schema leaves nothing to interpret and the baseline of 4 applies. The description correctly implies a single unfiltered listing operation.
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?
Clearly states a specific verb and resource: listing StackPick jobs (categories) with the tool slugs ranked within each. Terminology is slightly muddy — the title says 'categories' while the description says 'jobs' without explicitly equating them — and it doesn't distinguish the tool from siblings like search_tools or get_best_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?
No when-to-use guidance and no mention of alternatives. An agent must infer from the sibling names that this is a browse/index tool rather than a lookup or comparison tool; nothing tells it when this beats get_best_tools or search_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search StackPick tools by name, former name, tagline, description, category, or tag. Results use the same score order as the site search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return. Defaults to 10. | |
| query | Yes | Matches name, former names, tagline, description, best-for line, category, and tags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds useful context that is not in annotations: results are ranked by the same score order as site search, telling the agent the output is relevance-sorted rather than arbitrary.
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 zero filler; the primary capability is front-loaded and the ranking note follows. 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?
For a simple two-parameter read-only search with full schema coverage and completed annotations, the description covers the essentials. Its only minor gap is not stating the shape of returned results, though the ranking note partly compensates and no output schema exists.
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 both query and limit are already documented with matching detail (query even lists the same fields the description does). The description adds nothing about limit or match semantics beyond restating the fields, so 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?
States a specific verb (search) and resource (StackPick tools) plus the searchable fields, so an agent knows exactly what it retrieves. It doesn't explicitly differentiate itself from siblings like get_tool or list_categories, but the verb makes the distinction fairly obvious.
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 agent is expected to infer that this is the tool for keyword discovery while get_tool or list_categories serve lookup/browse. There is no explicit when-to-use or when-not-to-use statement, and no mention of the alternatives.
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.
compare_toolsget_best_toolsget_toollatest_releaseslist_categoriessearch_tools
Add one secure layer between your agents and this server.