Skip to main content
Glama

aaddyy_boyfriend_designer

Design and generate a custom AI boyfriend character by choosing his appearance, outfit, pose, art style, and background for personalized images.

Instructions

Design and generate your dream boyfriend character with AI - customize every detail from appearance to style (~10 credits)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
poseNosmirking_selfie
scarsNo
outfitNocasual_hoodie
hisNameNo
tattoosNo
artStyleNorealistic
bodyTypeNoathletic
eyeColorNohazel
eyeStyleNosharp
lightingNodramatic
skinToneNofair
faceShapeNochiseled
hairColorNodark_brown
hairStyleNoundercut
imageSizeNo1024x1024
backgroundNogym
expressionNococky_grin
facialHairNostubble
heightVibeNotall
nsfwFilterNo
ageAppearanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

C2.9/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact beyond the schema — the approximate credit cost (~10) — but otherwise says nothing about generation latency, output format, moderation (e.g. the nsfwFilter param and an 'nsfw_tease' pose), or authentication.

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?

A single front-loaded sentence with no filler, packing purpose, customization scope, and cost. Slightly denser structuring (e.g. separating cost from purpose) would be ideal, but it wastes nothing.

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?

For a 21-parameter image-generation tool with zero schema descriptions and no output schema or annotations, this is under-specified. It gives no sense of what is returned (image URL?), how the many enums map to the result, or what the nsfwFilter default of true implies for the 'nsfw_tease'/'aroused' options.

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% across 21 parameters, so the description must compensate and does not — it never references any specific field such as pose, outfit, nsfwFilter, or ageAppearance. The self-explanatory enum values carry all the meaning, leaving 'customize every detail' as an empty gesture.

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 states a specific verb+resource: 'Design and generate your dream boyfriend character with AI'. This is clearly distinguishable from the obvious sibling aaddyy_girlfriend_designer and from generic image tools, and it names the customization scope ('appearance to style'). It stops short of explicitly routing to alternatives, but the purpose itself is unambiguous.

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 only usage-relevant signal is the '~10 credits' cost. There is no statement of when to choose this over aaddyy_girlfriend_designer, aaddyy_image_generator, or aaddyy_headshot_generator, and no prerequisites or exclusions. An agent must infer usage entirely.

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