A read-only MCP server for Agent Swipe File, a free directory of creative reference libraries for DTC marketers and their AI agents. Agents can search 136 libraries with documented pricing, integrations and MCP/API access. No account or API key needed.
Scored across 4 tools
Each tool has a clearly distinct purpose: fetch-by-id, list categories/tags, list by recency, and full-text search. Overlap between list_recent and search_resources is minimal and the descriptions make the boundary explicit.
All four tools follow a consistent verb_noun pattern (get_resource, list_categories, list_recent, search_resources) with matching snake_case throughout. No mixed conventions or vague verb names.
Four tools is on the lean side but each covers a distinct access pattern for a read-only catalog. Nothing is redundant and nothing feels padded, though the surface is small enough that it borders on thin.
The core discovery workflows — browse by category, browse by recency, search, and fetch a specific resource — are all covered for a static catalog. Minor gaps exist: no pagination/offset for browsing large result sets and no way to enumerate resources by category without falling back to search.
Fetch one catalog resource by its stable id (the directory slug). Includes the directory page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Resource id, the catalog slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds only one behavioral detail beyond that — that the response includes the directory page URL — and says nothing about not-found behavior or missing resources.
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, no redundancy, with the lookup key and the identifier form front-loaded before the returned-field note.
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 and no output schema, the description covers the key, the identifier type, and one notable return field. It is nearly complete; only error/not-found behavior is absent.
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 already documented as 'Resource id, the catalog slug.' The description reinforces that the id is stable and slug-shaped, which is a mild clarification rather than new semantic content, 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 verb ('Fetch') and resource ('one catalog resource') with the exact lookup key ('stable id ... the directory slug'). It implicitly contrasts with the sibling list/search tools by emphasizing a single record, but never names them.
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 single-record-by-slug framing implies the use case (direct lookup once you know the slug), but there is no explicit statement of when to prefer this over search_resources or list_recent, nor any stated preconditions on finding the id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List primary categories and tags with counts from the bundled catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds that data comes from a 'bundled catalog' (static, local source) and that counts are included, but says nothing about ordering, whether the list is exhaustive, or refresh behavior.
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 with the resource first and the scope qualifier after; no filler and nothing an agent must skip past.
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-argument listing tool with full annotation coverage and no output schema, the description conveys the shape of the result (categories, tags, counts) and the source. Only minor gaps remain, such as return ordering or whether counts reflect all bundled resources.
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 no parameter semantics to explain; the baseline of 4 applies. Nothing in the description misleads about inputs.
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?
Specific verb+resource: 'List primary categories and tags with counts' names exactly what comes back, and 'from the bundled catalog' scopes the source. It is distinguishable from siblings like search_resources or list_recent, though the description never explicitly contrasts them.
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 — an agent can infer this is the enumeration call to make when it needs the set of categories/tags rather than individual resources. There is no explicit 'use this when…' statement and no named alternative among get_resource, list_recent, or search_resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List catalog resources newest by lastChecked. The date is the catalog check date. limit is capped at 25.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results. Values above 25 are capped at 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful clarification that the date refers to the catalog check date rather than creation/update time, but it does not describe result shape or how ordering ties behave, and the limit cap it states is already in 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?
Three short sentences with the ordering rule front-loaded and no filler. Slight waste in restating the 25 cap already present in the schema, which keeps it from a 5.
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, no-required-args read tool with rich annotations and no output schema, the description covers ordering semantics and the cap. Only the return shape/pagination details are absent, which is minor here.
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's description already says 'Values above 25 are capped at 25,' so the description's cap sentence is redundant. It adds no format or default detail beyond the schema, making baseline 3 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 ('List catalog resources') plus the ordering key ('newest by lastChecked'), which lets an agent distinguish it from get_resource and search_resources. The phrasing 'newest by lastChecked' is slightly awkward but the intent is recoverable.
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 guidance and no mention of when to prefer search_resources or get_resource instead. The agent must infer that this is the unfiltered 'browse newest' path with no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the bundled Agent Swipe File catalog by name, description, kind, id, category, or tag. Results include the directory page URL. limit is capped at 25.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results. Values above 25 are capped at 25. | |
| query | Yes | Text to match. Maximum 200 characters. | |
| category | No | Optional primary category id, such as ads or ugc. |
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 bar is met. The description adds genuine behavioral detail not in the annotations: which fields are matched (name, description, kind, id, category, tag) and that results carry the directory page URL. The limit cap is restated but also stated in 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 tight sentences with the searchable scope front-loaded. The final sentence about the limit cap partially duplicates the schema, costing a little, but nothing is buried or 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?
No output schema exists, and the description at least discloses that results include the directory page URL and what fields are matched. It stops short of describing result ordering, pagination, or the remaining result shape, but it is sufficient for a simple three-parameter search 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 description coverage is 100%, so all three parameters are already documented there. The description's only parameter addition is repeating the 25-result cap, which is already in the limit schema description, so it adds little beyond baseline.
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?
A specific verb plus resource ('Search the bundled Agent Swipe File catalog') and an explicit list of the fields matched. It implicitly distinguishes itself from get_resource by being the matching/search operation, though it never names the sibling to contrast with.
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 'search by ...' framing, but there is no explicit when-to-use guidance or statement of when to prefer get_resource / list_categories / list_recent instead. The agent must infer the routing from sibling names alone.
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_resourcelist_categorieslist_recentsearch_resources
Add one secure layer between your agents and this server.