This server provides an MCP interface to AceDataCloud Face Transform APIs for AI-powered face analysis and image editing.
Detect faces and return 90+ facial keypoints per face (multi-face supported).
Beautify portraits with smoothing, whitening, face slimming, and eye enlarging controls.
Change a face's apparent age by specifying target age(s).
Swap perceived facial gender characteristics.
Replace a face in a target image with a face from a source image, optionally using an async webhook.
Convert portraits to cartoon/animated styles.
Perform liveness detection to distinguish live captures from printed or screen photos.
Retrieve a concise usage guide for the available face tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-face-transform Cartoonize the face in this image"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that exposes the AceDataCloud Face Transform API — face keypoint detection, beautification, age/gender transform, face swap, cartoonization, and liveness detection.
Status: All Face APIs are currently in Alpha. Interfaces may evolve.
Keypoint detection — 90+ landmarks per face, multi-face supported
Beautification — smoothing, whitening, face slimming, eye enlarging
Age transform — age or de-age a portrait
Gender transform — swap perceived facial gender characteristics
Face swap — move a source face onto a target image (with optional async webhook)
Cartoonize — render a portrait in animated / cartoon style
Liveness detection — distinguish live captures from printed / screen photos
Related MCP server: MidjourneyMCP
pip install mcp-face-transformSet your AceDataCloud API token:
export ACEDATACLOUD_API_TOKEN=your_token_hereGet your token from https://platform.acedata.cloud.
mcp-face-transformmcp-face-transform --transport http --port 8000Tool | Description |
| Detect 90+ keypoints per face (multi-face supported). |
| Smoothing, whitening, face slimming, and eye enlarging. |
| Age or de-age a portrait. |
| Swap perceived facial gender characteristics. |
| Move a source face onto a target image (with optional async webhook). |
| Render a portrait in cartoon / animated style. |
| Distinguish a live capture from a printed / screen photo. |
| Concise client-side tool usage reference. |
"Detect all faces in https://example.com/group.jpg and return their keypoints."
→ face_detect_keypoints(image_url="https://example.com/group.jpg")
"Lighten and smooth my portrait."
→ face_beautify(image_url="https://example.com/me.jpg", smoothing=15, whitening=25)
"Replace the face in the scene with the headshot."
→ face_swap(
source_image_url="https://example.com/headshot.jpg",
target_image_url="https://example.com/scene.jpg",
){
"mcpServers": {
"face-transform": {
"command": "uvx",
"args": ["mcp-face-transform"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_api_token_here"
}
}
}
}Or use the hosted endpoint with bearer auth:
{
"mcpServers": {
"face-transform": {
"url": "https://face.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer your_api_token_here"
}
}
}
}pip install -e ".[dev,test]"
pytest --cov=core --cov=tools
ruff check .MIT — see LICENSE.
Apply beauty effects (smoothing / whitening / slimming / eye enlarging).
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL of the portrait to beautify. | |
| smoothing | No | Skin smoothing 0-100 (default 10). | |
| whitening | No | Whitening 0-100 (default 30). | |
| face_lifting | No | Face slimming 0-100 (default 70). | |
| eye_enlarging | No | Eye enlarging 0-100 (default 70). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Convert a portrait to an animated / cartoon style.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL of the portrait to stylize. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Age or de-age one or more faces using explicit target age information.
| Name | Required | Description | Default |
|---|---|---|---|
| age_infos | Yes | Target age information for each face, for example [{'age': 30}]. | |
| image_url | Yes | URL of the portrait to age-transform. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Swap perceived facial gender characteristics in a portrait.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL of the portrait whose facial gender should be swapped. | |
| gender_infos | Yes | Target gender information for each face, optionally including face_rect. Example: [{'gender': 1, 'face_rect': {'x': 0, 'y': 0, 'width': 100, 'height': 100}}]. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Detect faces in an image and return 90+ keypoints per face.
Use this when:
- You want raw landmark coordinates for downstream alignment / animation.
- You need to count or locate faces in a photo.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 0 = all faces (default), 1 = largest face only. | |
| image_url | Yes | URL of the image containing one or more faces. | |
| face_model_version | No | Algorithm version. '3.0' is recommended. | 3.0 |
| need_rotate_detection | No | 0 = disabled (default), 1 = enabled. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Decide whether a face image is from a live person versus a printed / screen photo.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL of the face image to verify. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Return a concise usage guide for the Face Transform tools.
Use this when:
- The model needs a refresher on which face tool fits the user's intent.
- Onboarding a new conversation that hasn't seen the prompts yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Replace the face in target_image_url with the face from source_image_url.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | Max upstream wait time in seconds (default 120). | |
| callback_url | No | Optional webhook URL to receive the result asynchronously. | |
| source_image_url | Yes | URL of the image whose face will be transplanted. | |
| target_image_url | Yes | URL of the image that will receive the new face. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0face_beautifyface_cartoonizeface_change_ageface_change_genderface_detect_keypointsface_detect_livenessface_get_usage_guideface_swapEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides YouCam API for skin, face & body analysis, beauty/makeup try-on, and hair & beard styling.
Provides YouCam API for AI image and video editing and generation.
Analyze user-submitted face photos with a complete report or 13 focused face-analysis tools.
Generate AI influencer photos, face swaps, and character sheets with a consistent face.
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
