Skip to main content
Glama
Sign In

Fashio AI

by com.fashiolabs
OverviewDiscussionsAdmin

Get account info

get_account

Returns the API key owner's account: {email, diamondBalance, plan: {isPremium, status, planProductId, provider, cancelAtPeriodEnd, renewsAt}}, where plan.status is active | will_expire | paused | billing_issue | expired | refunded | none. Use it to check the diamond (credit) balance before a large create_catalog_job, or to confirm which account a key belongs to. Not needed before every create_generation (a low balance there returns 402 without charging), and it does not list tool prices (use list_models). Read-only and free. Needs a valid Fashio API key (Bearer); every call counts toward the key's daily request cap (429 when reached, 401 for a missing or revoked key).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_account"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it declares the tool read-only and free, requires a Bearer Fashio API key, and discloses error semantics (401 for missing/revoked key, 429 on daily request cap, 402 from the downstream create_generation). This is exactly the auth and rate-limit context an agent needs before calling.

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?

Front-loaded with purpose, then usage, then constraints, and no sentence is filler. The inline field-list and status enumeration are dense but earn their place given the absence of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe the response, and it does so field-by-field including the plan.status enum domain. Combined with auth, cost, and rate-limit disclosure, nothing an agent needs to call this correctly is missing.

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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning to add. The description instead documents the return shape in detail, which is valuable but belongs to output semantics rather than parameter semantics.

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?

Opens with a specific verb and resource ("Returns the API key owner's account") and then enumerates the exact return fields including the plan.status enum values. It is clearly separable from siblings like create_catalog_job, create_generation, and list_models, each of which is named in a distinguishing context.

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?

Gives explicit when-to-use guidance (check diamond balance before a large create_catalog_job; confirm which account a key belongs to), an explicit when-NOT-to-use (not needed before every create_generation, since low balance returns 402 without charging), and a named alternative for a related need (list_models for prices).

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

All Fashio AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources