Pexafy Stock Photos

Find photos that look like an image or a Pexafy photo

search_photos_by_image

Read-only

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.

Input Schema

Name	Required	Description
`photo_id`	No	The 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_url`	No	Public 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_file`	No	The 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_base64`	No	Reference image as base64-encoded bytes, optionally as a data: URL. Use for programmatic clients that already hold the image data.
`english_search_sentence`	No	Optional, 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_filter`	No	Omit 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

Name	Required	Description
`data`	No
`error`	No
`budget`	No	Present 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.
`notice`	No	Why 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.
`success`	No
`presentation`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 14, 2026

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"
+}

First observedOct 3, 2026

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.

All Pexafy Stock Photos tools Inspect

Try in Browser