Skip to main content
Glama

Pexafy Stock Photos

by com.pexafy
OverviewDiscussionsAdmin

Server Details

Find free-to-use stock photos by words, by image or by similarity; every result names its licence.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
21.6% over 63 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
Pexafy/pexafy-mcp
GitHub Stars
0
Server Listing
Pexafy Stock Photos

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct action-resource pair: text search, visual search, reading the grid selection, fetching a file by id, and account connection. The descriptions explicitly delineate boundaries (e.g. search_photos vs search_photos_by_image, grid selection metadata vs get_photo_file_by_photo_id), leaving little room for misselection.

Naming Consistency4/5

All names use snake_case with a clear verb_noun structure (search_photos, connect_account, get_grid_selected_photos), so the convention is predictable. The only mild deviation is the verbose qualifier in get_photo_file_by_photo_id and search_photos_by_image, which is still consistent with the pattern.

Tool Count4/5

Five tools is a lean but sensible surface for a stock-photo server covering discovery, selection review, file retrieval, and account linking. Nothing feels redundant, though the set is close to thin for the breadth of the described domain.

Completeness4/5

The surface covers the core lifecycle: find photos by text or image, review the liked selection, retrieve the actual file, and connect an account. Missing niceties (e.g. paging/filtering controls or library browsing) are minor and workable around the existing tools.

Available Tools

5 tools
connect_accountConnect a Pexafy accountA
Read-onlyIdempotent
Inspect

Asks the host to offer its own flow for connecting a Pexafy account, when none is attached. Use it when the person asks to connect, link or sign in to a Pexafy account — including from the account button in the Pexafy grid — or wants more searches than the daily allowance available without an account.

When no account is attached, it returns an error result that carries an account-connection request for the host: the error is how that request is delivered, not a failure. A host that supports it shows its own account-connection prompt, which the person completes or dismisses; other hosts show only the result's text. Calling it again returns the same request. When an account is already attached, it says so and starts nothing.

It does not search, and searching does not require calling it. check_only is set by the Pexafy grid to read the state without opening a prompt; leave it unset when the person wants to connect or sign in.

ParametersJSON Schema
NameRequiredDescriptionDefault
check_onlyNoSet by the Pexafy results grid: `true` reports whether an account is connected — and the allowance in force — without opening the connection prompt. Leave it unset when the person wants to connect or sign in.

Output Schema

ParametersJSON Schema
NameRequiredDescription
budgetNoWhat is left of the current allowance, or null when it is not worth saying.
connectedNoWhether an account is attached to this conversation.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses a genuinely non-obvious behavior: with no account attached it returns an error result that *carries* the connection request, and the error is the delivery mechanism, not a failure. It also states idempotency consequences (calling again returns the same request) and the no-op case when an account is already attached, consistent with the readOnly/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and triggers are front-loaded, and the error-as-request paragraph earns its length because it prevents a misread. It runs slightly long and repeats the `check_only` guidance already present in the schema, so it is efficient but not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with an output schema and safety annotations, the definition covers everything an agent needs: the trigger conditions, the no-account error semantics, idempotent repeat behavior, and the set-vs-unset rule for `check_only`. Return-value detail is rightly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so `check_only` is already fully documented in the schema, including its default. The description largely restates that the grid sets it and that it should be left unset otherwise, adding only slight emphasis rather than new semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and resource: it asks the host to run its own Pexafy account-connection flow. It implicitly separates itself from the four search/photo siblings, none of which deal with account state, and clarifies it is not a search tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggers (person asks to connect/link/sign in, or hits the account button, or wants more than the daily allowance) and an explicit exclusion ('It does not search, and searching does not require calling it'). It also spells out when to set versus leave unset `check_only`, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_grid_selected_photosGet the photos the person liked in the gridA
Read-onlyIdempotent
Inspect

Returns the photographs the person liked (hearted) in the Pexafy results grid. Use it when the person refers to that selection rather than asking for new photos — for example “the images I selected”, “the ones I chose”, “my selection”, “the photos I hearted”, “the photos I liked”, “use the ones I picked”, “put my selection in the document”, “download the ones I chose”, or “write the article around my photos”.

The selection is held by the grid and the server, not by the conversation: this tool is how it is read, and search results are not the selection. It takes no arguments and returns every liked photograph with its rank, photo_id, photographer, source library, licence, pixel size, orientation, description, page URL and credit line, and selection_count, the number of them.

To get one of them as an image file, pass its photo_id to get_photo_file_by_photo_id.

rank is the person's order, #1 first: the order the photos were liked in, unless the person rearranged them by dragging in the grid. Where the grid is rendered, that number is drawn on each liked photograph, so it is the number the person sees and names them by (“#2”). The rank of a search result is only its position in that answer and is not drawn on the grid.

An empty selection means nothing is liked in the grid currently on screen; a photograph is liked with the heart on it. A selection expires an hour after its last change, and a new search replaces the grid it belongs to.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYesWhat the count means, in words: a whole selection, one that a later search replaced, or an empty one.
successYes
selected_photosYesThe photographs they liked, in their order — the order they liked them in, unless they rearranged them in the grid. Each carries its `rank` — #1 first — the `photo_id` to pass on, the photographer, the source, the licence, the pixel size, the description, the page it came from and the credit line.
selection_countYesHow many photographs they liked; `selected_photos` lists every one.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/no-destructive, but the description adds real behavioral context beyond them: the selection lives on the grid/server rather than in conversation, it expires an hour after its last change, a new search replaces the owning grid, and an empty result means nothing is currently hearted. These are stateful traits the annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and tightly organized into purpose, routing, return contents, rank semantics, and edge cases. It is on the long side — the long enumeration of user phrasings ('the ones I chose', 'my selection', 'use the ones I picked') is somewhat repetitive — but nearly every sentence carries distinct operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param, read-only tool with an output schema, the description still covers everything an agent needs: what is returned, the lifetime/expiry rule, the empty-selection case, the rank convention, and the handoff to get_photo_file_by_photo_id. No gaps remain that would cause a mis-invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero arguments, so the baseline is 4. The description reinforces this ('It takes no arguments') and explains the semantics of the returned `rank` field versus a search result's rank, which is useful context even though rank is an output rather than an input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('returns the photographs the person liked (hearted) in the Pexafy results grid') and explicitly distinguishes itself from sibling search tools by asserting 'search results are not the selection.' An agent can differentiate it from search_photos/search_photos_by_image without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use condition ('when the person refers to that selection rather than asking for new photos') plus a rich set of trigger phrasings, and names the downstream alternative ('pass its photo_id to get_photo_file_by_photo_id') for the file-retrieval case. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_photo_file_by_photo_idGet the photo as a fileA
Read-onlyIdempotent
Inspect

Returns one photograph from an earlier Pexafy result as an image file, identified by its photo_id. A result's link points to the image; this tool returns the image itself, so the person does not need to send the photograph again.

Use it when the user wants a photograph found here as a file: to place it in a document, a slide or a post, to attach, send or download it, or to have it cropped, captioned or otherwise edited with the host's own tools.

It is for a photograph the person picked: where the Pexafy grid is shown, the photographs of a search are already on screen and need no file to be seen.

The answer contains the photograph, at most 1280 pixels wide, and a line giving its file name, size, licence, source, photo_id, page at the source and the credit line to display. One photo per call; the file stays in the conversation afterwards.

This server does not edit images: what can be done to the file next depends on the host's own tools. Its licence and credit line apply to this photograph only.

ParametersJSON Schema
NameRequiredDescriptionDefault
photo_idYesThe `photo_id` of the specific photo to retrieve from a previous Pexafy result. It is a UUID such as `019e1ecb-0039-7da6-b1ca-987ee4d337c0`. Use the photo's `photo_id`, never a rank or a position: a rank is how the person and you name a photograph out loud, never what this parameter takes.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, yet the description adds substantial context beyond them: max 1280px width, the returned metadata line (file name, size, licence, source, page, credit line), one photo per call, file persistence in conversation, and that this server does not edit images. This is exactly the added behavioral value the dimension rewards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and outcome, and most sentences carry distinct information (output contents, resolution, persistence, licensing scope). It is somewhat long at five paragraphs for a one-parameter tool, with mild redundancy around not needing to resend the photograph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully compensates by enumerating the returned image and its accompanying metadata line, per-call cardinality, and licence/credit applicability. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself already explains the UUID format and the critical rule to use photo_id rather than a rank. The description only restates that the photo is identified by its photo_id, adding little beyond the structured field, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns one photograph from an earlier Pexafy result as an image file, identified by photo_id. It explicitly distinguishes itself from the retrieval-by-link flow and from search siblings (search_photos, get_grid_selected_photos) by noting the link points to the image while this tool returns the image itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use cases (place in a document, slide or post; attach, send, download; crop, caption or edit) and an explicit when-not boundary (a photograph already visible on the grid needs no file). The alternative behavior is named rather than left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_photosSearch free stock photosA
Read-only
Inspect

Use this when the user asks for a real photograph, or states a need that a photograph fills, and the picture is not already in the conversation.

Call it when they ask outright: “find me photos of…”, “show me images of…”, “I need a picture of…”, “do you have a photo of…”, “where can I find free photos of…”, in any language. Call it when they describe the need without asking to search: “I'm writing an article and need a header image”, “my landing page needs a hero image”, “I need something to illustrate this”. Call it when they ask for something meant to carry photographs: “write an article with pictures”, “a deck with images”. Call it when they name only the picture, with no reason given: “a photo of a white mug”, “a train in Japan”. If the user is working on something that usually carries photographs — an article, a page, a deck, a post — without asking for any, you may offer to look for some; call it only once they accept.

This covers requests for photographs for articles, blog posts, websites, landing pages, products, slides, documents, reports, social posts, ads, newsletters, banners, thumbnails, covers, posters, backgrounds, wallpapers and mood boards; photographs that illustrate a concept, explain a subject or accompany a piece of writing; and any request for free, stock, royalty-free, commercially usable, real or documentary photographs.

A request for a visual is not always a request for a photograph: this tool finds photographs that already exist — not illustrations, drawings, logos, icons, diagrams or screenshots — and it does not generate, edit or upscale an image, nor look for a named person.

It searches Pexafy's own index of millions of free-to-use photographs from stock libraries such as Unsplash, Pexels and Pixabay, matched to the scene described. Each result carries a rank, a photo_id, its licence, the credit line to display and an image link; the file itself comes from get_photo_file_by_photo_id. In a host that renders it, the grid shows them; the answer omits image links.

ParametersJSON Schema
NameRequiredDescriptionDefault
english_search_sentenceYesRequired. Describe the desired photograph in one concise English sentence, focusing on its visible subject and scene. Be specific: “Two colleagues laughing in a bright open-plan office” is more effective than “People office”. Keywords work too — send the user's own words, in English, rather than inventing detail they did not ask for. Maximum 250 characters. Describe one coherent scene, focusing on what should appear in the photograph rather than its intended use. Specify the requested photo shape or orientation in explicit_orientation_filter, not here. Example: “An old man sitting at a café table he has visited every morning for thirty years”.
explicit_orientation_filterNoOmit this parameter unless the user explicitly asks for a photo shape or orientation in their own words, or names a format whose shape is part of its definition — a vertical Short, a banner, a square post, a phone wallpaper. This is a hard filter, not a preference: it removes photos with other shapes before ranking, so using a shape the user did not request can exclude the best matches. Never infer the shape from a word inside `english_search_sentence` — “landscape” in “a natural landscape” names the scene, not the format — nor from the subject, the composition, or a purpose that fixes no shape (“a photo for my blog post”, “something for my landing page”). If you are choosing a value rather than repeating one explicitly requested by the user, omit it. Allowed values: `landscape`, `portrait`, `square`. Multiple values are allowed: two shapes return more than one alone, though any filter still returns less than none. For example, “anything but portrait” means `['landscape', 'square']`.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
budgetNoPresent only when the caller is near the end of an allowance — the daily one without an account, the monthly one with. What is left of it, and, for a caller with no account, the one sentence that says what lifts the limit. Also carried by a refusal, where it describes the wall itself.
noticeNoWhy this answer is empty, when it is. A plan limit was reached: the allowance and when it returns. There is nothing to retry until then.
successNo
presentationNoPresent only where the answer is drawn as the Pexafy grid: how it is shown. The grid is the complete visual answer; the reply needs no picture or link.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only, open-world, non-destructive profile, so the bar is lower, and the description still adds real behavior: ranked results with licence, credit line, image link, the host-rendering vs. answer-omits-links distinction, and that the file must be fetched separately. Missing only ranking/count/rate-limit behavior, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core trigger, which is good, but the trigger examples are repeated four times in near-identical form and the coverage sentence is an enumerative list. Effective but noticeably longer than needed for the information delivered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and the description still covers scope, exclusions, sibling routing, and result shape. For a two-parameter search tool this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameters are already richly documented in-schema, so baseline 3 applies. The description adds no field-level semantics (e.g. that explicit_orientation_filter is a hard filter) beyond what the schema already states clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('searches ... Pexafy's own index of millions of free-to-use photographs') and delimits against siblings: it does not generate/edit, does not find illustrations/logos, and routes the actual file to get_photo_file_by_photo_id. An agent knows exactly what this returns versus search_photos_by_image or get_photo_file_by_photo_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Extensive, explicit trigger conditions given as verbatim user phrasings, plus when-not-to-use (visual ≠ photograph, named person, generation/editing) and a conditional offering behavior. Nothing about selection is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_photos_by_imageFind photos that look like an image or a Pexafy photoA
Read-only
Inspect

Use this when the user wants photographs that look like a picture, rather than ones described in words: a picture they link to, one the host passes to the tool as a file, or a Pexafy photo already found or liked in the grid.

Call it for “find images like this”, “something similar to this photo”, “find a free alternative to this image”, “I need this but royalty-free”, “photos in this style”, “more like the second one”, whether or not they say “search by image”.

Give exactly one reference: photo_id for a Pexafy photo from an earlier result or liked in the grid; image_url for a picture at a public URL, such as a link the user pasted; image_file when the host passes the user's uploaded image to the tool; image_base64 for image bytes a client already holds. Sending two is refused. A picture that is only visible in the conversation — not linked, not passed to the tool — is not a reference this tool can receive; its scene can be searched in words with search_photos. Words are optional, in english_search_sentence: with a photo_id, the words that photograph was found under; with an image, only what the user wants changed or kept (“like this but at night”).

It finds free stock photographs in Pexafy's index that visually match the reference. The reference image is sent to Pexafy only to run the search; it is not stored. Each result carries a rank, a photo_id, its licence, the credit line to display and an image link. In a host that renders it, the grid shows them; the answer omits image links.

ParametersJSON Schema
NameRequiredDescriptionDefault
photo_idNoThe photo_id of the Pexafy reference photo, copied from the result the user or assistant is referring to. It is a UUID such as `019e1ecb-0039-7da6-b1ca-987ee4d337c0`. Use it instead of an image when the reference is a Pexafy photo, whether it was returned in an earlier search or liked in the grid, and pass the words of that search in `english_search_sentence` if needed.
image_urlNoPublic http(s) URL pointing directly to the reference image file, including a URL the user pasted in the conversation. For a photograph Pexafy returned, send its `photo_id` instead.
image_fileNoThe user's uploaded image, as a host that passes uploads to tools provides it: the upload's `download_url` and `file_id`. A picture that is only visible in the conversation has neither.
image_base64NoReference image as base64-encoded bytes, optionally as a data: URL. Use for programmatic clients that already hold the image data.
english_search_sentenceNoOptional, and usable with any reference. Send the words that say what the user wants from the reference: with a `photo_id`, the words that photograph was found under, so the results stay on the subject they asked for; with an image, what they want changed or kept from it (“like this but at night”). The reference stays the main signal and these words adjust it. With an image, send the change alone (“at night”) rather than the whole scene rewritten, which would outweigh the picture instead of adjusting it; with a `photo_id`, the full sentence that photograph was found under is what to send. In English, like the sentence of a text search. The words a reference photograph was found under are the best ones; where the grid hands you a short description of it instead, that description serves. When it is unclear whether they want the same subject or simply the same look, send the words: staying on the subject is the safer default. Omit them only when they plainly want photographs that look like the picture itself.
explicit_orientation_filterNoOmit this parameter unless the user explicitly asks for a photo shape or orientation in their own words, or names a format whose shape is part of its definition — a vertical Short, a banner, a square post, a phone wallpaper. This is a hard filter, not a preference: it removes photos with other shapes before ranking, so using a shape the user did not request can exclude the best matches. Never infer the shape from the reference image the user gave — its shape is a property of the picture they had, not a constraint on the ones they want — nor from the subject, the composition, or a purpose that fixes no shape (“a photo for my blog post”, “something for my landing page”). If you are choosing a value rather than repeating one explicitly requested by the user, omit it. Allowed values: `landscape`, `portrait`, `square`. Multiple values are allowed: two shapes return more than one alone, though any filter still returns less than none. For example, “anything but portrait” means `['landscape', 'square']`.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
budgetNoPresent only when the caller is near the end of an allowance — the daily one without an account, the monthly one with. What is left of it, and, for a caller with no account, the one sentence that says what lifts the limit. Also carried by a refusal, where it describes the wall itself.
noticeNoWhy this answer is empty, when it is. A plan limit was reached: the allowance and when it returns. There is nothing to retry until then.
successNo
presentationNoPresent only where the answer is drawn as the Pexafy grid: how it is shown. The grid is the complete visual answer; the reply needs no picture or link.

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/non-destructive, so the description earns credit for adding what those do not: the reference image is transmitted to Pexafy solely to run the search and is not stored, exactly one reference is accepted and two are refused, and results carry rank, photo_id, licence, credit line and image link. It stops short of describing rate limits or latency, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the use case and the parameter selection rule, and organized into clean paragraphs. It is longer than strictly necessary — the `english_search_sentence` paragraph in particular restates the change-vs-full-sentence rule and then adds fallbacks — but every paragraph carries real instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, nested-object, open-world search tool with an output schema, the description covers trigger conditions, reference selection, filter caution, privacy handling, and result shape. Nothing needed to invoke it correctly is missing, and return-value detail is appropriately brief given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds decision-level semantics the schema does not: the mutual exclusivity rule across the four reference inputs, when to prefer `photo_id` over an image, and detailed strategy for `english_search_sentence` (send only the change with an image, the full original sentence with a photo_id). The `explicit_orientation_filter` guidance about never inferring shape from the reference is behavior the schema text alone would not convey as crisply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('finds free stock photographs ... that visually match the reference') and explicitly contrasts with the text-based sibling by naming `search_photos` for scene-in-words searches. An agent can distinguish it from `search_photos` and `get_photo_file_by_photo_id` without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrasings ('find images like this', 'something similar to this photo'), names the alternative (`search_photos`) for the case it cannot serve, and enumerates which reference parameter applies to each situation. The 'exactly one reference, two is refused' rule and the 'visible only in conversation is not a reference' exclusion leave nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedsearch_photos12 fields changed
      • addedOutput schema / properties / data / items / properties / alt_description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / alt_description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / height / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / height / type
        Removed value: -[
-  "integer",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / photographer_full_name / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / photographer_full_name / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / source_image_url / anyOf
        Added value: +[
+  {
+    "format": "uri",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / source_image_url / format
        Removed value: -"uri"
      • removedOutput schema / properties / data / items / properties / source_image_url / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / width / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / width / type
        Removed value: -[
-  "integer",
-  "null"
-]
      • addedOutput schema / properties / presentation
        Added value: +{
+  "description": "Present only where the answer is drawn as the Pexafy grid: how it is shown. The grid is the complete visual answer; the reply needs no picture or link.",
+  "properties": {
+    "grid_already_rendered": {
+      "description": "The grid is on the person's screen.",
+      "type": "boolean"
+    },
+    "mode": {
+      "description": "The answer is drawn as the Pexafy grid.",
+      "enum": [
+        "grid"
+      ],
+      "type": "string"
+    },
+    "next_step": {
+      "description": "What the person does next in the grid.",
+      "type": "string"
+    },
+    "show_inline_images": {
+      "description": "Whether the reply needs pictures of its own: no, the grid shows them.",
+      "type": "boolean"
+    },
+    "show_photo_links": {
+      "description": "Whether the reply needs photo links: no, each photograph opens from the grid.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
    • Changedsearch_photos_by_image12 fields changed
      • addedOutput schema / properties / data / items / properties / alt_description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / alt_description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / height / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / height / type
        Removed value: -[
-  "integer",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / photographer_full_name / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / photographer_full_name / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / source_image_url / anyOf
        Added value: +[
+  {
+    "format": "uri",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / source_image_url / format
        Removed value: -"uri"
      • removedOutput schema / properties / data / items / properties / source_image_url / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / data / items / properties / width / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / data / items / properties / width / type
        Removed value: -[
-  "integer",
-  "null"
-]
      • addedOutput schema / properties / presentation
        Added value: +{
+  "description": "Present only where the answer is drawn as the Pexafy grid: how it is shown. The grid is the complete visual answer; the reply needs no picture or link.",
+  "properties": {
+    "grid_already_rendered": {
+      "description": "The grid is on the person's screen.",
+      "type": "boolean"
+    },
+    "mode": {
+      "description": "The answer is drawn as the Pexafy grid.",
+      "enum": [
+        "grid"
+      ],
+      "type": "string"
+    },
+    "next_step": {
+      "description": "What the person does next in the grid.",
+      "type": "string"
+    },
+    "show_inline_images": {
+      "description": "Whether the reply needs pictures of its own: no, the grid shows them.",
+      "type": "boolean"
+    },
+    "show_photo_links": {
+      "description": "Whether the reply needs photo links: no, each photograph opens from the grid.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. 5 tool updates
    • First observedconnect_account
    • First observedget_grid_selected_photos
    • First observedget_photo_file_by_photo_id
    • First observedsearch_photos
    • First observedsearch_photos_by_image

Related MCP Connectors

  • OpenverseA
    io.github.pipeworx-io

    Openverse MCP — Creative-Commons-licensed image + audio search.

    SearchOpen Data
    472
  • StockCakeA
    com.stockcake

    Search millions of CC0 public-domain AI images: previews, dimensions, provenance, license.

    SearchOpen Data
    131
  • MemeStackA
    ai.memestack

    Find the image that explains it: published charts, infographics, screenshots and memes, searchable by meaning, by the words printed inside them, or by visual similarity. Publisher charts (Our World in Data, Eurostat, USDA ERS, EEA) come with source, period and license, and every result carries a ready-to-paste citation. 19 read tools free with no account (daily limits); 2 optional paid tools over x402 or L402.

    Entertainment & MediaResearch & DataSearch
    212
  • Lightdrift Images MCPAOAuth
    ai.lightdrift

    Search over 1.85 million captioned images using text, a reference image, or both. Upload a JPEG, PNG, or WebP image as base64, or provide a public HTTPS image URL. Find similar images from a Lightdrift asset ID and retrieve hosted file URLs, source licenses, and attribution. Connect with OAuth or an API key. Searches cost $0.005 ($5 per 1,000); image details are free. Setup: https://docs.lightdrift.ai/guides/images-mcp

    AI & Machine LearningDesign ToolsSearch
    1

Related MCP Servers

  • free-image-library

    surendranb
    A
    license
    A
    quality
    A
    maintenance
    Enables keyless search and retrieval of millions of openly-licensed Creative Commons images and audio, with ready-to-paste attribution and license-awareness built into every result.
    5
    MIT

  • webfetch

    ashlrai
    A
    license
    A
    quality
    B
    maintenance
    License-first federated image search for AI agents and humans. Exposes MCP tools for concise, attribution-aware image discovery, license probing, and guarded downloads across open, platform, and editorial sources.
    7
    16 npm
    3
    MIT

  • wikipedia-mcp-image-crawler

    dazeb
    A
    license
    B
    quality
    D
    maintenance
    Enables searching and retrieving images from Wikipedia Commons with detailed metadata including licenses and authors.
    2
    49 npm
    10
    MIT

  • Pexels MCP Server

    nikola-arman
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables searching and retrieving high-quality stock photos from Pexels with advanced filtering options including orientation, size, color, and localization support.
    16 npm
    ISC
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources