visual-hunt-mcp

by CTlanston

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct action or platform: opening specific sites (Google Maps, Instagram, Pinterest, Xiaohongshu, generic URL), extracting or re-extracting candidates, downloading or saving images, and searching via Google or wallpaper sites. No two tools have overlapping purposes, and descriptions clarify their unique roles.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., 'close_manual_page', 'download_candidate_images', 'open_google_maps_visual_search'). There are no deviations or mixed styles, ensuring predictability for agents.
Tool Count5/5
With 11 tools, the server is well-scoped for its purpose of visual hunting. Each tool serves a clear function without redundancy, and the count is neither too thin nor too heavy for the domain.
Completeness5/5
The tool set covers the full workflow: opening visual sources (platform-specific and generic), extracting and re-extracting candidates, downloading images, and saving metadata. There are no obvious missing operations like a 'list downloads' tool, but the core lifecycle is complete and agents can accomplish tasks without dead ends.
Average 4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true, meaning side effects exist, but no destructive or idempotent hints. The description adds valuable behavioral context: it uses the browser session for cookies/referer, blocks Google-hosted previews and Google Maps imagery, and accepts flexible input formats for 'candidates'. This goes beyond annotations by specifying what is blocked and how sessions are used.
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?
The description is extremely concise at two sentences, yet it packs essential information: destination, browser dependency, blocked sources, and parameter flexibility. No redundant text; every sentence adds value. Structure is front-loaded with the primary action.
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?
Given the complexity of 3 parameters (including a nested object) and no output schema, the description covers the download destination and blocking behavior. However, it omits important context like response details (success/failure), error handling, the effect of the 'limit' parameter, and prerequisites for the browser session. It is adequate but not fully complete for a tool with no output schema and low parameter documentation.
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 description coverage is 0%, so the description must explain all parameters. It only partially covers 'candidates' by noting it accepts arrays or JSON strings. 'projectName' and 'limit' are left unexplained, lacking any additional context on their format, purpose, or constraints. The description fails to compensate for the lack of schema descriptions.
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?
The description clearly specifies the action ('Download candidate images'), the target location ('into a project folder under the current MCP working directory'), and the mechanism ('using the connected browser session for cookies and referer when needed'). It effectively distinguishes this tool from siblings like 'save_candidates_json' or 'search_google_images' by focusing on downloading images rather than metadata or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools like 'save_candidates_json' for saving metadata instead. Usage context is only implied by the action (download) but lacks comparative decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool opens a URL in a local Chrome session and extracts visible image candidates, adding context beyond the annotations (readOnlyHint, destructiveHint). It explains the scheme restriction, but does not detail browser state changes or extraction mechanics.
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?
The description is a single sentence that efficiently conveys the core functionality and a key constraint. However, it omits parameter details, which could be structured as a short list. It is concise but at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what 'extract visible image candidates' returns (e.g., image URLs, data). It also fails to describe the return format or any pagination behavior. Combined with missing parameter explanations, the tool is inadequately specified for reliable agent invocation.
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?
The input schema has 0% description coverage, so the description must compensate. It mentions the 'url' parameter but does not explain the 'limit' parameter, its purpose, or how it controls extraction. This leaves the agent guessing about a critical parameter.
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?
The description clearly states the action (open URL and extract images), the resource (connected local Chrome session), and the output (visible image candidates). It also explicitly rejects non-http/https schemes, distinguishing it from sibling tools that target specific sites.
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 description specifies that only http/https URLs are accepted and lists rejected schemes, but it does not provide guidance on when to use this generic tool versus specialized siblings like open_google_maps_visual_search. The usage context is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only. The description adds that images are not downloaded, which is helpful but does not cover other behaviors like overwriting or error handling. 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 concise sentences: first states the core action and location, second clarifies the parameter flexibility. No unnecessary words.
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?
Covers key behavior and parameter type but lacks details on return value, success/failure, file naming, or idempotency. Adequate but not rich.
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?
The description adds value by explaining that 'candidates' accepts either an array or JSON string, which is not described in the schema. However, 'projectName' remains uncommented, and overall schema coverage is 0%.
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?
The description clearly states the tool saves candidate metadata to the MCP working directory and explicitly excludes downloading image files. This distinguishes it from sibling tools like download_candidate_images.
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 description implies use for metadata-only saving without images, but does not explicitly give when/when-not guidance or name alternatives. Users must infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it removes from registry and returns {closed:false} for unknown ID, going beyond annotations (destructiveHint, idempotentHint). No contradiction.
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 concise sentences, front-loaded with action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main action and edge case, but could describe what manualPageId represents. However, tool complexity is low, and overall is fairly complete.
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 0%, but description adds no information about the parameter manualPageId beyond its name. Fails to compensate for the gap.
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?
Clearly states verb 'close' and resource 'manual-assisted page', distinguishing it from sibling open tools. No ambiguity.
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?
Implies use after opening, but lacks explicit when-to-use or when-not-to-use. Doesn't reference any alternative close tools (none exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds useful behavioral specifics: map tile URLs are automatically filtered and remaining preview URLs cannot be downloaded. This provides context beyond annotations, though it does not detail the exact opening behavior (e.g., tab creation, return value).
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 sentences, each with clear purpose. The first sentence is front-loaded with the main action, and the second adds necessary filtering details. No superfluous content.
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?
The description explains the tool's purpose and some behavioral traits, but lacks detail on parameter semantics and invocation behavior. With no output schema and 0% parameter coverage, the description should provide more complete guidance for an agent to correctly use the tool.
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 description coverage is 0%, so the description must compensate. It does not describe the 'query' or 'limit' parameters, leaving their meaning and usage ambiguous. The description focuses on the tool's function rather than the parameters, which is a significant gap.
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?
The description clearly states the tool opens Google Maps for 'safe, manual-assisted visual inspiration review,' specifying the verb, resource, and scope. It distinguishes itself from sibling tools like open_instagram_visual_search by focusing on Google Maps and manual review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for manual-assisted review, providing context for when to use it. It mentions filtering of map tile URLs and the inability to download preview URLs, which are behavioral hints. However, it does not explicitly state when not to use this tool compared to alternatives like search_google_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable context: it uses a connected local Chrome session, extracts only visible candidates, and addresses the occasional login wall with a fallback action. 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?
The description is two concise sentences: the first states the primary function, and the second provides a critical usage note. No extraneous content, and the key information is front-loaded.
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?
The description covers the login wall scenario but lacks details on extraction behavior (e.g., scrolling, handling of dynamic content) and the format of returned candidates. With no output schema, these gaps reduce completeness for an agent expecting clear expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'query' or 'limit' beyond their names. It fails to compensate for the lack of schema descriptions, leaving the agent without guidance on expected input format or constraints.
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?
The description clearly states it opens Pinterest search results and extracts visible image candidates, using specific verbs like 'open' and 'extract'. It distinguishes from siblings by specifying Pinterest, as opposed to other platforms like Google Maps or Instagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use an alternative tool: if a login wall appears, call extract_manual_page_candidates. However, it does not explicitly compare to other sibling tools or state when to prefer this over open_url_and_extract_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions using a connected local Chrome session and warns that verbose quality suffixes can lead to zero results. Annotations already indicate read-only and non-destructive behavior; the description fills in additional dependencies and risks.
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?
The description is two sentences, front-loaded with the core action, and includes a crucial warning. Every clause earns its place—no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers the main purpose, a key parameter caveat, and the Chrome session dependency. It does not detail return values, but given the simplicity, it is mostly 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?
The input schema has 0% description coverage, so the description must compensate. It explains the 'quality' parameter's default and cautionary behavior, but does not clarify 'query' (though implied) or 'limit'. Partial value added.
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?
The description clearly states the tool's purpose: searching Google Images for poster and wallpaper candidates using a local Chrome session. It specifies the resource (Google Images with udm=2) and the verb (search), distinguishing it from sibling tools that target other platforms or actions.
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 description provides guidance on when to use the 'quality' parameter (pass 'cinematic' or 'poster' only when a stylistic suffix is wanted) and warns about zero-results pages. However, it does not explicitly state when to use this tool instead of other image search tools or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds value by noting that each access refreshes the TTL, which goes beyond the annotations. 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?
The description is two sentences long, front-loaded with the core action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and annotations, the description covers the purpose, usage scenario, and a behavioral note (TTL refresh). It does not describe return format or pagination, but is reasonably complete for a re-extraction tool.
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 0%, so the description must compensate. It explains that manualPageId originates from a prior open_*_visual_search call, adding meaning. However, it provides no additional context for the optional limit parameter, so only partial compensation.
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?
The description clearly states the tool re-extracts visible image candidates from a previously opened manual-assisted page. It specifies the verb 're-extract' and resource 'image candidates', and distinguishes from siblings by tying to a prior open_*_visual_search call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: after logging in, scrolling, or dismissing overlays. It does not explicitly state when not to use it or name alternatives, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and open-world behavior. Description adds context about empty candidates in certain page states and suggests re-extraction steps, which is valuable beyond 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 sentences with no unnecessary words. First sentence states core functionality, second sentence handles an important edge case. Information is front-loaded and easy to scan.
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 description should clarify return values. It partially does by mentioning 'candidates' and 'visible images', but does not explain the full output structure or behavior of the 'limit' parameter. Adequate but not comprehensive.
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 0% and description does not explain the 'query' or 'limit' parameters. The meaning of 'query' can be inferred, but 'limit' is not mentioned at all, leaving ambiguity.
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?
Description clearly states the tool opens Instagram for manual-assisted visual review and extracts visible images. It differentiates from sibling tools by specifying Instagram and mentions handling of login_required/blocked states, distinguishing from other open tools.
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?
Explicitly says when to use (for manual-assisted visual review on Instagram) and what to do when login_required or blocked (log in manually, then use extract_manual_page_candidates). Provides a clear alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by explaining the Google fallback, direct site adapters, and quality suffix behavior. No contradictions 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 concise sentences that front-load the purpose and provide necessary usage details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behaviors like fallback and sites flexibility. Lacks details on return format or limit parameter, but the tool is search-style and return is somewhat implied.
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?
With 0% schema description coverage, the description partially compensates by explaining the `sites` parameter format (array or JSON string) and the default quality suffix. However, the `limit` and `query` parameters are not elaborated.
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?
The description clearly states the verb 'Search', the resource (wallpaper, photography, etc., image sources), and the method (direct site adapters with Google fallback). It distinguishes from siblings like search_google_images by indicating multiple sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on how to use the `sites` parameter and the default quality suffix. However, it does not explicitly state when to use this tool versus alternatives like search_google_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds value by explaining login wall behavior and that candidates are empty in that case. No contradictions, but could elaborate more on output format.
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 sentences, no wasted words. Front-loaded with primary action, followed by important conditional guidance. Exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, and a special case. Lacks parameter details and output explanation, but given no output schema and annotations, it's mostly adequate.
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 has 0% description coverage and the description does not mention parameters (query, limit). It fails to add any meaning beyond the schema, which is minimal.
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?
The description clearly states the tool opens Xiaohongshu search results and extracts visible images, with a specific verb (open, extract), resource (Xiaohongshu), and distinguishes from siblings by mentioning it's best for Chinese-language queries.
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?
Explicit when-to-use (best for Chinese-language queries) and when-not-to-use (login wall scenario, with alternative: extract_manual_page_candidates). Provides clear context and conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![visual-hunt-mcp MCP server](https://glama.ai/mcp/servers/CTlanston/visual-hunt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CTlanston/visual-hunt-mcp)

Score Badge

Copy to your README.md:

[![visual-hunt-mcp MCP server](https://glama.ai/mcp/servers/CTlanston/visual-hunt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CTlanston/visual-hunt-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CTlanston/visual-hunt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server