Search and download licensed stock images, SVG illustrations and packs, brand logos, sound effects, low-poly 3D game models and videos from ImgSearch. Sign in with a free ImgSearch account over OAuth; searching is free and downloads use your plan's allowance.
Scored across 4 tools
The tools form clear search/download pairs, and the descriptions explicitly separate photographs (search_images/download_images) from other assets such as SVGs, packs, logos, sounds, 3D models, and videos (search_assets/download_asset). There is still some conceptual overlap between 'images' and 'assets', so an agent could briefly hesitate over which search or download tool applies.
All four tools follow a consistent verb_noun pattern: search_images, search_assets, download_images, download_asset. The singular/plural distinction reflects the actual semantics of downloading one selected asset versus multiple images, rather than an inconsistent convention.
Four tools are tightly scoped to the server's search-and-download purpose. Each tool has a distinct role, and there are no redundant or obviously unnecessary tools.
The surface covers the core lifecycle of searching and downloading both image and non-image assets, including handling packs, brands, 3D models, and videos. Minor gaps exist around explicit account/quota inspection or a dedicated asset-detail tool, but these are largely handled within the search and download responses.
Prepare one selected SVG, SVG pack, brand logo, sound effect, 3D model or video from search_assets using its exact type and id. Free at call time; allowance is charged when the file is fetched. Re-downloads are free. SVGs, WAVs and 3D models share the image allowance; videos have a separate allowance; pack ZIPs require a paid plan, which charges each new member, or the pack bought on its own, which charges nothing. Brands arrive as ZIPs with required license notices and sources. A 3D model arrives as one ZIP with GLB, FBX and OBJ versions and its licence. Local agents fetch resource_url, follow redirects and save using file_name. Web chat clients receive only download_url for a user browser click: never fetch that link yourself. Never claim the file is owned or saved merely because its link is ready. Previews are not licensed downloads.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact id returned by search_assets. | |
| type | Yes | ||
| background | No | SVG/pack only. Defaults to a reviewed transparent version when available. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the full cost model: free at call time, allowance charged at fetch, free re-downloads, shared allowance for SVGs/WAVs/3D models, a separate video allowance, and pack ZIP rules tied to plan status. It also describes what each asset type delivers (brand and 3D model ZIPs with licences and sources) and explicitly forbids claiming ownership or saving just because a link is ready.
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?
The purpose and source constraint are front-loaded, and nearly every sentence carries operational information. It is dense and long for a three-parameter tool, but little of it is filler.
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 carries the return-value burden and does so: resource_url for agents, download_url for browser clicks, file_name for saving, and per-type archive contents. An agent has everything needed to call the tool and interpret the response correctly.
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 67%, and the description adds real meaning to the type enum by explaining what each value yields, including the ZIP-based pack, brand and 3D model outputs. The background parameter is left entirely to its schema description, so it is not fully compensated.
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 (prepare a download for one selected asset), lists the supported asset types, and names search_assets as the required source of the type/id pair. It does not explicitly distinguish itself from the download_images sibling, so an agent must infer the single-versus-batch 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?
It says the type and id must come from search_assets, and it tells the agent not to treat previews as licensed downloads. It also branches on caller type: local agents fetch resource_url, while web chat clients must hand download_url to the user and never fetch it. The missing piece is an explicit pointer to download_images for multi-image cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare the ImgSearch images you selected from search_images for download. Pass only the slugs you actually need. Nothing is charged by this call itself: images the user already owns are always free to fetch, and new images are only counted the moment each one is actually fetched or saved, up to quota.max_new_downloads. This call proceeds even if the full selection does not fit the remaining allowance — fetch in priority order and expect a blocked response on an individual file once the allowance for new images runs out; already-owned files always succeed. It only returns nothing when the account cannot fetch a single file right now (unverified email, or zero allowance and nothing already owned). On success every image returns a final file resource. Fetch it in the same turn and save it under its file_name. Never expose a per-file resource_url in chat. Every resource_url and download_url stays valid for 30 minutes. If a fetch fails because a link has expired, call download_images again with the same slugs for a fresh one — do not ask the user why, just regenerate it.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | One to 30 unique image slugs from search_images. Include only images you will actually use. |
| Name | Required | Description |
|---|---|---|
| quota | No | |
| images | No | |
| status | Yes | |
| message | No | |
| new_slugs | No | |
| upgrade_url | No | |
| download_url | No | |
| user_message | No | |
| retry_required | No | |
| requested_slugs | No | |
| already_owned_slugs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: billing only occurs at fetch time, partial success with per-file blocked responses in priority order, the exact single condition under which nothing is returned (unverified email or zero allowance with nothing owned), and a 30-minute TTL with a defined retry path. This is consistent with readOnlyHint=true and idempotentHint=true rather than contradicting them.
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 and the cost model are front-loaded, then failure modes, then the retrieval/expiry contract. Four dense blocks with little padding, though the reset-warning at the end is slightly repetitive of the earlier fetch-and-save instruction.
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 quota-sensitive tool with an output schema, the description covers the prerequisites, the partial-failure contract, and the TTL/regeneration loop an agent must handle — everything needed to call it correctly and recover from failures is present.
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 slug field already states 'One to 30 unique image slugs from search_images. Include only images you will actually use.' The description restates that selection guidance ('pass only the slugs you actually need') without adding format or ordering semantics beyond the schema.
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?
Names a concrete verb+resource ('prepare the ImgSearch images ... for download') and anchors it to the producing sibling, search_images. It doesn't differentiate itself from download_asset, the other fetching sibling, so an agent must infer which download path applies.
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?
Explicit operating instructions: pass only needed slugs, fetch and save in the same turn under file_name, never surface resource_url in chat, and re-call with the same slugs on expiry rather than asking the user. It lacks an explicit 'use X instead' exclusion versus download_asset, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find published SVG illustrations, coordinated SVG packs, brand logos, sound effects, low-poly 3D game models or videos. Use search_images for photographs. Search uses no download allowance. Omit query to browse. SVG, sound and 3D model semantic searches may return pending: wait retry_after_seconds and call again with the same arguments; do not change the query while waiting. Use descriptions and technical metadata to select; do not claim to have viewed or listened to a preview unless you actually did. Previews grant no usage rights. Call download_asset for each chosen id; brands have their own license conditions, 3D models follow the game asset licence at license_url, and packs require an eligible paid plan.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| limit | No | ||
| query | No | English description of the subject, scene, sound, object or brand. Omit to browse published items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only, idempotent, non-destructive and closed-world; the description adds material behavior they cannot express: searches consume no download allowance, some semantic searches return `pending` with a required retry loop, previews convey no usage rights, and licensing differs per asset type (brand licenses, game asset license at license_url, packs needing a paid plan). It also sets an epistemic guard ('do not claim to have viewed or listened to a preview unless you actually did'), which is unusual and directly useful.
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?
Front-loaded with what is searchable and the sibling exclusion, then moves to cost, retry behavior, and licensing in a logical order. It is a single dense paragraph with several distinct concerns (routing, pagination, retry, licensing) that would read better split, but every sentence 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?
With no output schema, the description still conveys what comes back (ids, descriptions, technical metadata, license_url, a pending state with retry_after_seconds) and what happens next (download_asset per id). Combined with the license caveats, an agent has enough to search, wait, select and hand off correctly.
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 only 33% (only `query` is documented in-schema). The description compensates by mapping prose asset names onto the `type` enum values and stating the omit-query browse behavior, but it never explains `limit` (default 8, max 24), leaving one of three parameters undocumented in both places.
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?
Opens with a specific verb plus an exhaustive enumeration of the resource types the search covers (SVG illustrations, packs, brand logos, sound effects, 3D models, videos), matching the `type` enum. It explicitly distinguishes itself from the sibling `search_images` for photographs, so an agent can pick the right tool without opening 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?
Gives concrete when-to-use routing ('Use search_images for photographs'), a browse mode ('Omit query to browse'), and the follow-on action ('Call download_asset for each chosen id'). The async retry protocol ('wait retry_after_seconds and call again with the same arguments; do not change the query while waiting') is an explicit, actionable instruction with an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public, moderated ImgSearch catalog. Pass one named query group per distinct image need: a single group for one image, or up to ten groups for a multi-section blog post, article, presentation, or campaign. The section field labels what that query is for so you can keep results straight. Searching is free and uses no download allowance. Nothing is downloaded until you call download_images, so ask for more candidates per topic than you intend to use. Every candidate's description is a vision-model description of what is actually visible in that image, so it is your primary signal when choosing. Read it together with tags, orientation, and aspect_ratio to judge whether the image fits the placement. Do not rely on the title alone and do not claim you viewed the image. Results are ranked by relevance, but the top result is not always the best fit: a semantically relevant image can still be wrong for the composition, orientation, or emphasis the user needs. Compare the descriptions and pick deliberately.
| Name | Required | Description | Default |
|---|---|---|---|
| searches | Yes | One to ten distinct query groups. Each item runs one search; section labels what the results are for. | |
| limit_per_search | No | Candidates returned per query group. All groups together may return at most 60 unique images, so with many groups this is lowered automatically to fit. |
| Name | Required | Description |
|---|---|---|
| quota | No | |
| status | Yes | |
| message | No | |
| searches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds material context beyond them: no download quota consumed, ranking caveats ('the top result is not always the best fit'), and the instruction to rely on vision-model descriptions rather than titles. It also warns against claiming to have viewed the image, which is a meaningful behavioral constraint.
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?
Front-loads purpose, then usage, then selection guidance in a logical order. Most sentences earn their place, though the section-field sentence mildly duplicates the schema description and the final paragraph repeats the title-warning theme. Slightly longer than necessary but well-structured.
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?
Given an output schema exists, the description needn't explain return values. It covers the remaining agent-critical context: search scope, free/no-download behavior, multi-query strategy, and how to evaluate candidates. Nothing needed 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?
Schema coverage is 100%, so the schema already documents query, section, and limit_per_search well. The description adds strategic meaning beyond the schema—one group per distinct need, up to ten for multi-section work, and the rationale for requesting extra candidates—but does not need to restate parameter syntax.
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 ('Search the public, moderated ImgSearch catalog') and immediately distinguishes itself from download_images by clarifying nothing is downloaded. The multi-group/one-group framing makes the scope concrete without needing 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?
Explicitly tells the agent when to pass one group vs. up to ten, explains that searching is free and consumes no download allowance, and directs over-fetching of candidates because nothing is committed until download_images. No alternatives or exclusions are 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.
download_assetdownload_imagessearch_assetssearch_images
Add one secure layer between your agents and this server.