Skip to main content
Glama

Searchapi

by io.searchapi
OverviewDiscussionsAdmin

Google Lens

google_lens
Read-only

Analyze images using Google Lens. Upload an image URL to get visual matches, product identification, text extraction, and exact match detection. Supports refining results with a text query for search types: all, visual_matches, and products.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoOptional text query to refine image search results. Only works with search_type: all, visual_matches, or products.
urlYesPublic URL of the image to analyze. Required.
cropNoCrop region as left;top;right;bottom with normalized 0-1 coordinates (e.g., '0.1;0.2;0.6;0.8'). Searches only the specified region of the image.
countryNoCountry code for localized results (e.g., 'us', 'gb'). Uses ISO 3166-1 alpha-2 format.
safe_searchNoSafe search filtering. 'active' enables strict filtering, 'blur' blurs explicit content (default), 'off' disables filtering.
search_typeNoType of lens analysis. 'all' for general analysis, 'visual_matches' for similar images, 'products' for shopping, 'exact_matches' for identical images. Default: all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changed
    • changedInput schema / properties / safe_search / description
      Previous value: -"Safe search filtering. 'blur' blurs explicit content (default), 'off' disables filtering."New value: +"Safe search filtering. 'active' enables strict filtering, 'blur' blurs explicit content (default), 'off' disables filtering."
    • changedInput schema / properties / safe_search / enum
      Previous value: -[
-  "blur",
-  "off"
-]New value: +[
+  "active",
+  "blur",
+  "off"
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / crop
      Added value: +{
+  "description": "Crop region as left;top;right;bottom with normalized 0-1 coordinates (e.g., '0.1;0.2;0.6;0.8'). Searches only the specified region of the image.",
+  "type": "string"
+}
  4. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already establish the safe read-only, open-world, non-destructive profile. The description adds the URL requirement and the kinds of results returned, which is useful. However, it does not disclose rate limits, auth needs, or result variability, and with idempotentHint=false, the description could clarify why results differ between calls. No contradiction with annotations.

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

Conciseness5/5

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

Two tight sentences with the core capability front-loaded and zero filler. Every clause earns its place, and the capabilities list precedes the refinement detail. Appropriate size for the tool's complexity.

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

Completeness3/5

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

No output schema exists, so the description carries some return-format responsibility. It covers what the tool does and the main capabilities, but omits exact_matches from the search types and does not specify the expected URL format. For a read-only tool with strong annotations, it is reasonably complete yet has the notable enum gap.

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

Parameters2/5

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

Schema coverage is 100%, so baseline is 3. The description adds helpful meaning for search_type and the text query, but it lists only 'all, visual_matches, and products' and omits 'exact_matches' — a valid enum value in the schema. This incomplete list actively detracts from what the schema already provides and could prevent an agent from using exact match detection.

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?

Specific verb ('Analyze images using Google Lens') plus a concrete resource and a clear list of outputs (visual matches, product identification, text extraction, exact match detection). This clearly distinguishes it from the many text-search siblings like google_search_light and google_images_light, since it is the only image-recognition tool.

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

Usage Guidelines3/5

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

The use case is implied ('Upload an image URL') and the refined search types give context, but there is no explicit when-to-use vs. alternatives, nor any exclusions. An agent must infer it is the right tool for image analysis rather than being told to prefer it over, say, google_images_light.

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

All Searchapi toolsInspect
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