Skip to main content
Glama

Style Profile

style_profile
Idempotent

Integrated styling verdict: seasonal color (measured colorimetry consensus) + face-impression zone (published geometry rules) + body frame + integration rules (palette subset, taste, silhouette, modifiers). 1-3 face photos, optional full-body + questionnaire. Flat $0.05/call. Choose this when you want the integrated styling analysis as JSON to use or render yourself; it is the same analysis that style_report turns into a PDF. For color only use portrait_analysis.

Input Schema

NameRequiredDescriptionDefault
styleNoOne of: feminine, masculine, neutral. Styling context: feminine, masculine or neutralneutral
imagesNoUp to 3 objects {image_url | image_base64}
image_urlNoAbsolute http(s) URL of the image (JPEG/PNG/WebP)
x_paymentNoOptional: base64 X-PAYMENT header value (x402 exact scheme, USDC on Base mainnet). Omit it to receive the payment requirements (accepts[] + docs) for this call without being charged.
image_base64NoBase64-encoded image bytes (alternative to image_url)
questionnaireNoOptional frame questionnaire answers (see /catalog input spec)
body_image_urlNoOptional full-body photo URL for frame estimation
body_image_base64NoSee the product's input spec in /catalog

Output Schema

NameRequiredDescriptionDefault
bodyYesJSON body of the underlying call (see /samples/{product} for each product's shape)
statusYesHTTP status of the underlying call (200 result, 402 payment terms, 4xx input error)
how_to_payNo
receipt_idNoset on paid results; free re-fetch via get_receipt
payment_requiredNotrue when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / body_image_base64
      Added value: +{
      +  "description": "See the product's input spec in /catalog",
      +  "type": "string"
      +}
    • addedInput schema / x-required-one-of
      Added value: +[
      +  "image_url",
      +  "image_base64",
      +  "images"
      +]
    • addedOutput schema / properties / how_to_pay
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / payment_required
      Added value: +{
      +  "description": "true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / receipt_id
      Added value: +{
      +  "description": "set on paid results; free re-fetch via get_receipt",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "body": {
      +      "description": "JSON body of the underlying call (see /samples/{product} for each product's shape)"
      +    },
      +    "status": {
      +      "description": "HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error)",
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "status",
      +    "body"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / style / description
      Previous value: -"Styling context: feminine, masculine or neutral"New value: +"One of: feminine, masculine, neutral. Styling context: feminine, masculine or neutral"
  4. Changed6 schema fields changed
    • addedInput schema / properties / body_image_url / description
      Added value: +"Optional full-body photo URL for frame estimation"
    • addedInput schema / properties / image_base64 / description
      Added value: +"Base64-encoded image bytes (alternative to image_url)"
    • addedInput schema / properties / image_url / description
      Added value: +"Absolute http(s) URL of the image (JPEG/PNG/WebP)"
    • addedInput schema / properties / images / description
      Added value: +"Up to 3 objects {image_url | image_base64}"
    • addedInput schema / properties / questionnaire / description
      Added value: +"Optional frame questionnaire answers (see /catalog input spec)"
    • addedInput schema / properties / style / description
      Added value: +"Styling context: feminine, masculine or neutral"
  5. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is partly covered. The description adds genuinely new behavior: a flat $0.05/call charge (non-read-only compute), input cardinality (1-3 face photos), and the exact analytical equivalence to style_report. It does not discuss failure modes for poor photos or image retention, leaving a small gap.

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 value proposition and component list are front-loaded, and the routing guidance comes last where it is needed. It is dense with domain jargon (colorimetry consensus, geometry rules) but no sentence is filler; a slightly tighter break into sentences would improve scanability.

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?

With an output schema present, return values need not be explained, and cost, inputs, and sibling relationships are all covered. The questionnaire and body_image_base64 params defer to '/catalog input spec', an external reference the agent may not have loaded, which is the only notable gap.

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 schema already explains every parameter, including the x_payment flow and image formats. The description only adds the '1-3 face photos, optional full-body + questionnaire' constraint, which is marginal over the schema's 'Up to 3 objects' note; baseline 3 applies.

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 names a specific verb+resource ('Integrated styling verdict') and enumerates its components (seasonal color, face-impression zone, body frame, integration rules). It explicitly distinguishes itself from both style_report (PDF) and portrait_analysis (color only), so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Choose this when you want the integrated styling analysis as JSON to use or render yourself' gives an explicit selection condition, and 'For color only use portrait_analysis' names the alternative and the case that selects it. The style_report relationship is also clarified as output-format-only, not analytical difference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources