mcp-face-transform

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct face transformation or detection task. There is no overlap: age change, cartoonize, keypoint detection, beautification, gender change, swap, liveness detection, and a usage guide all have clearly different purposes.
Naming Consistency5/5
All tool names follow a consistent 'face_' prefix followed by a descriptive verb or verb phrase in snake_case (e.g., face_change_age, face_detect_keypoints). This pattern makes the tool set easy to navigate and select from.
Tool Count5/5
With 8 tools, the server is well-scoped for face-related transformations and detections. Each tool addresses a specific and non-trivial capability, and the count feels appropriate for a focused image processing domain.
Completeness4/5
The tool set covers the most common face manipulation requests (aging, cartoonizing, beautifying, gender swap, swapping) and detection needs (keypoints, liveness). The included usage guide is a nice touch. A minor gap could be the absence of a general face_generate tool, but the core workflow is well-covered.
Average 3.5/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
- 19 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only describes what effects are applied but does not disclose behavioral traits such as whether the operation is destructive, how it handles missing faces, whether the original image is modified, or any required permissions. The minimal phrasing leaves significant gaps.
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, efficient sentence that front-loads the core purpose. Every word earns its place, though it lacks structural elements like bullet points or explicit mention of the required image_url parameter. Still, it avoids verbosity.
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?
Given the complexity (5 parameters, multiple sibling tools, output schema exists), the description is too brief. It omits context like required input format, output behavior, limitations (e.g., only works on portraits), and comparisons to alternate face tools. The output schema exists, so return values need not be described, but the description still feels incomplete.
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 each parameter already has a descriptive schema (name, range, default). The description adds no new semantic meaning beyond enumerating the effects, which is already evident from parameter names and descriptions. 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 clearly states the tool's purpose with a specific verb ('Apply') and resource ('beauty effects'), listing four concrete effects in parentheses. This distinguishes it from sibling tools like face_cartoonize or face_swap, as beautification is a distinct operation.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., image must contain a face), nor any exclusion criteria or comparison with siblings like face_cartoonize. The agent is left to infer use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic operation. It does not disclose whether multiple faces are handled, what happens if the source has no face, resolution limits, or whether the result is a new image or modification. The output schema exists but is not referenced.
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 sentence, zero wasted words. The essential information is front-loaded. Perfectly concise for a straightforward operation.
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?
Given the tool's complexity (face swap with 4 parameters, output schema exists, multiple siblings), the description is too brief. It fails to explain failure modes, prerequisites, or output format. The agent is left with many unknowns.
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% (all four parameters have descriptions). The description adds value by clarifying the relationship between the two required parameters (source face transplanted to target). However, it does not add extra syntax or format details beyond the schema. 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 is a specific verb+resource: 'Replace the face in target_image_url with the face from source_image_url.' It clearly identifies the two images involved and the action, distinguishing it from siblings like face_cartoonize or face_beautify.
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?
No guidance on when to use face_swap versus alternatives (e.g., face_change_age, face_detect_keypoints). No prerequisites, conditions, or exclusions are mentioned. The agent receives no context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core transformation but does not disclose output format, limitations, prerequisites (e.g., image must contain a face), or potential failure modes. This lack of detail is insufficient for a tool with no annotation support.
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 a single sentence with no wasted words. It efficiently conveys the tool's purpose without unnecessary elaboration.
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?
For a simple one-parameter tool with an output schema, the description is minimally adequate. However, it lacks any usage context, such as input image requirements or expected output behavior, leaving some gaps for an agent deciding whether to use this 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?
The single parameter image_url is fully described in the input schema ('URL of the portrait to stylize'), and the tool description adds no additional meaning beyond that. With 100% schema coverage, the baseline of 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 clearly states the tool's function with a specific verb ('Convert') and resource ('portrait'), and specifies the output style ('animated / cartoon'). This distinguishes it from sibling face manipulation tools like face_beautify or face_change_gender.
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 guidance on when to use this tool versus alternatives. It only states what the tool does, without any context for selecting it over related tools like face_beautify or face_swap, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the transformation intent but does not mention whether the operation is destructive, requires authentication, returns an image URL, or processes multiple faces (though the gender_infos parameter suggests array support). The agent lacks critical behavioral context.
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 a single sentence of 8 words, highly concise and front-loaded. Every word serves the purpose of defining the tool's function. No wasted or redundant language.
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 tool has 2 parameters and an output schema, the description is incomplete. It does not mention that the tool can handle multiple faces in one call (implied by gender_infos array), nor does it describe the output format (though output schema exists). The description could be more informative without becoming overly verbose.
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 the baseline is 3. The tool description does not add any parameter-specific meaning beyond what the schema already provides (image_url and gender_infos with example). It meets the minimum threshold but adds no extra semantic value.
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 "Swap perceived facial gender characteristics in a portrait" uses a specific verb ('swap') and resource ('facial gender characteristics in a portrait'), clearly distinguishing this tool from siblings like face_change_age (age) and face_swap (face swapping). The purpose is unambiguous and directly conveys the tool's core function.
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 guidance on when to use this tool versus its siblings (e.g., face_change_age, face_swap, face_beautify). It does not specify contexts, prerequisites, or alternatives. The agent must infer usage solely from the tool name and sibling tool names, which is insufficient for 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?
With no annotations provided, the description carries the full burden. It discloses the ability to both age and de-age, and that multiple faces can be processed. However, it lacks details on limitations (e.g., image requirements, result format, reversibility), which a typical agent would need for safe invocation.
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 a single sentence of 12 words, front-loaded with the core action. Every word earns its place; there is no redundancy or fluff. Ideal for quick scanning by an AI agent.
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 tool's simplicity (2 parameters, output schema present), the description is adequate but incomplete. It does not clarify how the 'age_infos' array maps to multiple faces in the image, nor does it explain the return format or error cases. The presence of an output schema mitigates some gaps, but the description should still provide clarity on usage flow.
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% with clear parameter descriptions (e.g., 'URL of the portrait' and 'Target age information for each face'). The description adds the nuance of 'Age or de-age' and 'one or more faces', but these are already inferable from the schema. The added value is modest, warranting a baseline 3.
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 ('Age or de-age') and resource ('faces'), and specifies scope ('one or more'). It effectively distinguishes from sibling tools like 'face_change_gender' and 'face_cartoonize' by focusing on age transformation.
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?
No explicit guidance on when to use this tool vs. alternatives. While the description implies usage for age transformation, it does not mention when not to use it (e.g., for gender changes) or provide context about prerequisites, making it unhelpful for decision-making among siblings.
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?
Since no annotations are provided, the description must carry the full behavioral transparency burden. It correctly states the classification task (live vs. spoof), which implies a binary decision, but it does not disclose what happens when liveness cannot be determined (e.g., low confidence, ambiguous cases), expected output format/confidence scores, or any security/capture requirements for the image.
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?
A single sentence of moderate length directly conveys the purpose without any fluff. Every word is meaningful and 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?
Given the simplicity (1 required parameter, clear binary decision task) and the presence of an output schema, the description provides enough context for basic use. It could be strengthened by noting that the tool outputs a liveness score or binary result, but the output schema presumably covers that. A minor gap is no mention of image requirements (size, format) for reliable liveness detection.
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% with only one parameter. The description does not add semantics beyond the schema, but the parameter is self-explanatory (image_url). The output schema is present (indicated by context signals), so the return value semantics are handled there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the binary classification task (live vs. printed/screen photo), uses the specific verb 'Decide', and identifies the resource as 'face image'. Within the sibling context (which focuses on aesthetic transformations like age change, cartoonize, beautify), this detection tool is easily distinguishable.
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 gives no guidance on when to use this tool vs. alternatives. From the sibling list, a user might wonder when to use face_detect_liveness vs. face_detect_keypoints, but no comparison or context is provided. It does not mention prerequisites (e.g., image quality, lighting conditions) or limitations.
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 must fully disclose behavior. It states the output is a 'concise usage guide' but does not detail its format, content, or whether it is static. The existence of an output schema partly compensates, but more specifics on what the guide includes would improve transparency.
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: a single-line purpose followed by two usage bullets. Every sentence adds value, no redundancy, and key information is front-loaded. Ideal structure for this simple tool.
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 zero-parameter tool with an output schema, the description covers essential aspects: purpose and usage context. It does not elaborate on the guide's content, but the output schema likely details return structure, making the description adequate.
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?
There are zero parameters, so the input schema already conveys all parameter information. The description correctly omits parameter details, meeting the baseline expectation for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a usage guide for Face Transform tools, using the specific verb 'Return' and resource 'usage guide'. The 'Use this when' bullets further clarify its purpose. It implicitly distinguishes from sibling tools (which perform transformations) by being a guidance tool.
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 explicitly provides two usage scenarios: 'The model needs a refresher...' and 'Onboarding a new conversation...'. While it does not name alternatives, the sibling tool list suggests this is for guidance rather than transformation, making the context clear.
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 provided, the description carries the full burden of disclosing behavioral traits. It mentions the return of 90+ keypoints but omits important details such as rate limits, authentication requirements, image format/size constraints, behavior when no faces are found, or error handling. The transparency is adequate but has clear gaps.
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: one sentence for the core purpose followed by a bullet list of use cases. Every word adds value, with no redundancy or fluff. The structure is well-organized and front-loaded.
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 that an output schema exists (the tool has output schema: true) and the description covers the primary purpose and usage scenarios, the description is largely complete. It lacks details on edge cases (e.g., no faces, unsupported images) but the output schema likely documents the return structure. Overall, it provides sufficient context for an agent to decide when and how to invoke the 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 100%, so the descriptions in the schema already document all parameters (e.g., mode, image_url, face_model_version, need_rotate_detection). The tool description does not add new parameter-level meaning beyond what the schema provides, making a baseline score of 3 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 clearly states the tool detects faces and returns 90+ keypoints per face, with a specific verb and resource. It distinguishes from sibling tools (e.g., face_swap, face_beautify) by emphasizing raw landmark coordinates for downstream tasks like alignment or animation, which no sibling offers.
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 explicit use cases: 'raw landmark coordinates for downstream alignment / animation' and 'count or locate faces.' It does not explicitly state when not to use the tool or mention alternatives, but the context (sibling tools) makes it inferential. A near-perfect score is withheld due to the lack of exclusion 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:

[![FaceTransformMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/FaceTransformMCP/badges/card.svg)](https://glama.ai/mcp/servers/AceDataCloud/FaceTransformMCP)

Score Badge

Copy to your README.md:

[![FaceTransformMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/FaceTransformMCP/badges/score.svg)](https://glama.ai/mcp/servers/AceDataCloud/FaceTransformMCP)

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/AceDataCloud/FaceTransformMCP'

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