Photo AI Studio MCP Server

Official

by photo-ai-studio

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose: browse_themes for theme discovery, create_video for video generation, edit_image for photo editing, generate_photo for AI photo generation, get_account for account info, get_prediction and list_predictions for status, and upload_image for image upload. There is no overlap between these functions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., browse_themes, create_video, edit_image, generate_photo, get_account, get_prediction, list_predictions, upload_image). The verbs are imperative and descriptive, providing a predictable naming convention.
Tool Count5/5
With 8 tools, the server covers the essential operations of a photo AI studio: uploading, generating, editing, creating videos, checking account info, and managing predictions. The number is well-scoped and neither too sparse nor too bloated.
Completeness4/5
The tool set covers the main lifecycle: upload, generate/edit/video, and check predictions. Minor gaps exist, such as no tool to delete uploaded images or cancel predictions, but these are non-critical for common workflows. The included operations are comprehensive.
Average 4.1/5 across 8 of 8 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation ('list past predictions'), but lacks details on rate limits, auth, or behavior with empty results. Minimal disclosure.
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?
Single, efficient sentence (13 words) conveying purpose, scope, and features. Front-loaded with key action and resource.
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?
Adequate for a simple list tool with well-documented schema. Missing description of return format, but no output schema exists, and list context is clear.
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 covers all 3 parameters with descriptions (100% coverage). Description only adds 'past predictions' context and optional state filter, providing minimal value beyond schema.
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 verb 'list', resource 'predictions', and specifies scope as 'past predictions (generations, edits, videos)' with pagination and state filter. Distinguishes from siblings like get_prediction (single) and creation tools.
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?
No explicit when/when-not or alternatives, but context implies listing past predictions. Sibling tools provide implicit guidance, but no exclusions or prerequisites stated.
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?
No annotations are provided. The description discloses that it is a read operation (browsing) and mentions the return of slugs, but lacks details on pagination, rate limits, or whether it requires authentication. For a simple listing, it is adequate but not comprehensive.
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, concise and front-loaded with the core purpose. Every sentence adds value with no redundancy.
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 lack of output schema, the description explains the return value (theme slugs). It covers the filter parameters but does not specify behavior when no parameters are provided (e.g., returns all themes). Overall, it is sufficient for the tool's simplicity.
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%, so the schema already documents both parameters. The description rephrases filtering by gender and search by tag, adding minimal extra meaning. It also hints at the output usage, which is helpful but not parameter-specific.
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 browses photo themes/categories, specifies filtering by gender or tag, and explains the return value (theme slugs) needed by generate_photo. It distinguishes from sibling tools like generate_photo by establishing a dependency.
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 when to use: to obtain theme slugs for generate_photo. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for this simple browse tool.
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?
Given no annotations, the description attempts to disclose behaviors: credit cost and prerequisite upload. However, it omits details about the generation process (e.g., whether it is synchronous or async, what happens on error, or how the wait_for_result parameter affects behavior). This leaves some ambiguity for the agent.
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 three sentences, with no redundant information. It front-loads the core purpose and follows with essential usage guidance in a logical order. Every sentence earns its place.
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?
The description covers the tool's purpose, prerequisites, and cost, and mentions the key distinction between themed and custom generation. However, it does not explain the conditional dependency between type/category/prompt, nor describe the output format (e.g., image URL or prediction ID) despite having a wait_for_result parameter. Given the complexity (9 params, no output schema), slightly more detail would improve completeness.
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 100% schema description coverage, the schema already documents all parameters. The description adds value by explaining the credit cost and linking category usage to browse_themes, but does not clarify conditional requirements (e.g., when type=themed vs custom). 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?
The description explicitly states the tool generates AI photos from face images using themed styles or custom prompts. It clearly identifies the verb 'generate', the resource 'AI photos', and the method, and distinguishes itself from sibling tools like upload_image and browse_themes by referencing them as prerequisites or discoverability tools.
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 usage context: it requires prior face image upload via upload_image, costs 100 credits per photo, and recommends browse_themes for theme discovery. It does not explicitly state when not to use this tool (e.g., for other media types), but the sibling tools cover those purposes, and the guidance is sufficient for an informed selection.
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?
No annotations are provided, so the description bears full burden. It states the tool returns 'current state and result URL when complete,' which is adequate but lacks details on possible states, error handling, or idempotency. More transparency on the async behavior would help.
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 efficiently convey purpose, scope, and output. Front-loaded with the verb 'Check' and no unnecessary 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?
Given low complexity (one param, no output schema), the description covers the essential purpose, output, and input origin. Minor gaps: does not enumerate possible states or mention error cases for invalid IDs, but still fully usable.
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 description's parameter info ('returned by generate_photo, edit_image, or create_video') duplicates the schema. No additional meaning is added beyond the schema, meeting baseline expectations.
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 checks the status of an async operation for generation, edit, or video. It explicitly distinguishes from sibling tools like generate_photo, edit_image, and create_video (which start operations) and list_predictions (which lists all predictions).
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 used after initiating an async operation to check its status, and differentiates from siblings. However, it lacks explicit guidance on when not to use it (e.g., for initiating operations or listing all predictions) or alternatives.
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?
With no annotations, the description carries the full burden. It discloses credit costs, required parameters per type, output type options, and the behavior of the wait_for_result parameter, providing good insight into tool behavior.
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 well-structured with bullet points for each type and credit costs front-loaded. It is concise yet informative, though the credit listing could be slightly more streamlined.
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 16 parameters and no output schema, the description covers input requirements well but lacks details on output format, error handling, or processing time. This gap reduces completeness.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters by type and explicitly stating which parameters are required for each type, along with credit cost implications, enhancing understanding beyond the schema.
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 explicitly states 'Create AI videos' and details three distinct types (image_to_video, ugc, product_holder) with their specific use cases and credit costs, making the purpose crystal clear and differentiating from sibling tools.
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 guidance on when to use each type by listing required parameters and credit costs for each. It lacks explicit 'when not to use' but the enum and descriptions suffice for correct selection.
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?
Discloses credit costs, required parameters per operation, and the 'wait_for_result' behavior. Missing details on idempotency, rate limits, or side effects, but adequate given no 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?
Well-structured with bullet points and clear sections. Could be slightly more concise, but every sentence adds necessary information.
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; the description does not explain the return format (e.g., edited image URL or prediction ID) for most operations, leaving the agent uncertain about what to expect.
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?
Schema coverage is 100%, but the description adds value by mapping operations to required parameters and providing examples, which helps the agent understand usage beyond raw schema.
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 edits photos using 19 AI operations, with a specific verb and resource. It distinguishes from siblings like 'generate_photo' and 'create_video' by focusing on editing existing images.
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 explicit guidance on which operation requires which parameters and credit costs. However, it does not explicitly state when to avoid this tool in favor of alternatives.
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?
With no annotations, the description bears full transparency burden. It discloses the CDN destination, max file size (10MB), and input formats. However, it omits details like allowed image types, idempotency, overwrite behavior, or response format beyond 'CDN URL'.
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?
Four sentences, no wasted words. Critical information (purpose, output, input options, size limit) is front-loaded. Highly concise and structured for quick parsing.
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 simple upload tool with two optional parameters and no output schema, the description adequately covers purpose, input constraints, and downstream use. However, since no output schema exists, a more precise description of the returned URL format would improve completeness.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that image_url expects a 'Public URL' and image_base64 accepts 'raw or data URI' base64, elaborating on the schema's simple type strings.
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 action ('Upload an image'), the target resource ('Photo AI Studio CDN'), and the outcome ('Returns a CDN URL'). It explicitly names the downstream tools that use this URL (generate_photo, edit_image, create_video), distinguishing it from those sibling tools.
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 explains when to use this tool (to upload an image for later use by other tools) and specifies accepted input formats (URL or base64). However, it does not explicitly mention when NOT to use it or name alternatives, though no alternative upload tool exists among siblings.
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?
With no annotations, the description must disclose behavior. It states the tool is a read operation that returns credit balance, total predictions, and membership date. This is sufficient for a simple retrieval. Could mention authentication implicitly.
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, front-loaded with purpose, then usage advice. Every word earns its place. No 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?
For a simple account info tool with no output schema, the description covers what is returned and the use case. It is complete enough for an agent to decide when to use it.
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?
No parameters, so schema coverage is 100%. According to guidelines, 0 params gives a baseline of 4. The description adds no parameter info, which is fine.
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 uses a specific verb 'Get' and identifies the resource 'account info', listing the exact fields returned. It clearly distinguishes from sibling tools which are about browsing themes, creating videos, editing images, generating photos, etc.
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?
Explicitly states when to use: 'before generating photos to check available credits.' Provides clear context, though it doesn't explicitly list when not to use it or name alternatives.
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:

[![photo-ai-studio-mcp MCP server](https://glama.ai/mcp/servers/photo-ai-studio/photo-ai-studio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/photo-ai-studio/photo-ai-studio-mcp)

Score Badge

Copy to your README.md:

[![photo-ai-studio-mcp MCP server](https://glama.ai/mcp/servers/photo-ai-studio/photo-ai-studio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/photo-ai-studio/photo-ai-studio-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/photo-ai-studio/photo-ai-studio-mcp'

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