_ registry / mcp streamable-http · checked 11h ago

brilliant

https://brilliant.design

Registry code: 362d80ea125ae11b

api record

Use Brilliant when the user asks to design, mock up, wireframe or lay out pages, screens (a mobile app screen, a login screen), dashboards, posts, slides or posters, to change a design open in the chat, or to remove a photo's background. design opens a new, live Brilliant canvas of editable layers in the chat, empty. Brilliant applies rows as they arrive and the canvas animates each batch in, so a design reads best when its first rows set the frame and its main sections and later rows fill in the details. The design is editable layers, not an image. edit_design adds rows to a design open in…

endpoint
https://brilliant.design/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is brilliant live?
Yes — it answered the hub's last check (checked 11h ago). It answered 100% of checks over the last 30 days.
Is brilliant free to use?
Not measured yet.
What tools does brilliant have?
6 tools: design, edit_design, remove_background, inspect_design, place_image, get_knowledge.
Is brilliant safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 100%· all time 100%

latency
331ms

last good check

priced tools
0

of 6 tools

_ answered our checks, 90 days 1 checks · signed record
  • unknown → live
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 6 tools
6 never probed 0 of 6 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • design unknown never probed

    Use this when the user asks to design or mock up a screen or page: a mobile app screen, a login or sign-up screen, a landing or pricing page, a dashboard, a slide, a social post or a poster. The result is an editable design on a live canvas (frames, text, shapes, icons the user keeps changing by hand). Brilliant builds it in the chat as a live canvas of editable layers (frames, text, shapes, icons) that the user keeps editing by hand. Not for generating a photograph or an illustration, for photo edits (use remove_background) or for questions that need no design. Do not use to change a design already open in this conversation. Rows take literal values (hex colors, numbers); design tokens are not available in this lane.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "title": {
          "type": "string",
          "description": "A short name for the design."
        },
        "intent": {
          "type": "string",
          "maxLength": 160,
          "description": "One plain line on what this design is about to hold, such as \"A pricing section with three plans and a highlighted middle tier\". The canvas shows it beside ChatGPT's cursor while the first rows are written."
        }
      }
    }
    arguments 14 lines
  • edit_design unknown never probed

    Use this when the user wants to change or add to a Brilliant design opened in this conversation, such as adding a section or a screen next to it, changing the copy, or making it darker. It takes the design's seed and Blueprint rows and applies them on that design's canvas: new rows add layers, and a row that leads with an id or #ref the design already has changes that layer. It returns how the rows applied, naming any row that did not apply. Its rows run up to 8,000 characters per call; a call of about 20 rows (about 1,500 characters), such as a page's frame and its first section, lands on the canvas within a few seconds. Rows take literal values (hex colors, numbers); design tokens are not available in this lane.

    mcp-tool

    {
      "type": "object",
      "required": [
        "seed",
        "blueprint"
      ],
      "properties": {
        "seed": {
          "type": "string",
          "description": "The slug of a design opened in this conversation (from the design result)."
        },
        "blueprint": {
          "type": "string",
          "maxLength": 8000,
          "description": "Readable design rows, one element per line: its kind, text, size and colors in short form. Example: t(\"Sign in\",Inter,15,b) f[(#FFFFFF)] is the bold white 15 px Inter text \"Sign in\". Children sit indented two spaces under their parent; no file() row; literal values (hex colors, numbers). People in placeholder copy, such as a testimonial's author, are written as a role only (\"Home cook\"), with no name or place. Brilliant applies rows as they arrive and the canvas animates each batch in, so a design reads best when its first rows set the frame and its main sections and later rows fill in the details."
        }
      }
    }
    arguments 18 lines
  • remove_background unknown never probed

    Use this when the user attaches or links a photo and asks to remove its background, cut out the subject or get a transparent PNG. It returns the user's own photo with the background cut away by a matte, at its original size up to 2,048 pixels on the long edge, every subject pixel unchanged. An image generator redraws the picture; this does not. Do not use to generate a new image. It cuts the subject out of the original photo with a matte. It takes the user's image as image (a file the user attached), imageUrl (https) or imageBase64, and returns the cutout, a share link, and Open in Brilliant.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "image": {
          "type": "object",
          "required": [
            "download_url",
            "file_id"
          ],
          "properties": {
            "file_id": {
              "type": "string"
            },
            "file_name": {
              "type": "string"
            },
            "mime_type": {
              "type": "string"
            },
            "download_url": {
              "type": "string"
            }
          },
          "description": "The photo the user attached.",
          "additionalProperties": false
        },
        "imageUrl": {
          "type": "string",
          "description": "An https URL of the photo (PNG, JPEG or WebP, up to 25 MB)."
        },
        "mimeType": {
          "type": "string",
          "description": "The mime type of imageBase64 (optional, the bytes are sniffed)."
        },
        "imageBase64": {
          "type": "string",
          "description": "The photo's bytes as base64 (PNG, JPEG or WebP, up to 25 MB)."
        }
      }
    }
    arguments 40 lines
  • inspect_design unknown never probed

    Use this when the user wants to see, check or talk about a Brilliant design opened in this conversation: it returns the element tree as Blueprint rows with ids (the ids rows can target), how each turn of the design ended (complete, halted, stopped at a limit, or still building) and any rows that did not apply. With wait, it holds up to 25 seconds for the design's latest turn to end; a turn still building at that point answers its progress. A design renders once the user has the canvas open in the chat.

    mcp-tool

    {
      "type": "object",
      "required": [
        "seed"
      ],
      "properties": {
        "seed": {
          "type": "string",
          "description": "The design's slug (from the design result)."
        },
        "wait": {
          "type": "boolean",
          "description": "true holds the answer up to 25 seconds for the design's latest turn to end. Default false."
        }
      }
    }
    arguments 16 lines
  • place_image unknown never probed

    Use this when the user wants an image (one they attached, or one generated in this conversation) placed into a Brilliant design opened in this conversation: it puts the image on the canvas as an editable image layer, or as the fill of a target layer, and answers how it applied. It takes the design's seed and the image as image (the file attached or generated in the conversation), imageUrl (https) or imageBase64 (PNG, JPEG or WebP, up to 25 MB); target names an existing frame or shape by its id or #ref to fill instead.

    mcp-tool

    {
      "type": "object",
      "required": [
        "seed"
      ],
      "properties": {
        "name": {
          "type": "string",
          "description": "The new image layer's name (default Image)."
        },
        "seed": {
          "type": "string",
          "description": "The slug of a design opened in this conversation (from the design result)."
        },
        "image": {
          "type": "object",
          "required": [
            "download_url",
            "file_id"
          ],
          "properties": {
            "file_id": {
              "type": "string"
            },
            "file_name": {
              "type": "string"
            },
            "mime_type": {
              "type": "string"
            },
            "download_url": {
              "type": "string"
            }
          },
          "description": "The image attached to or generated in the conversation.",
          "additionalProperties": false
        },
        "target": {
          "type": "string",
          "description": "The id or #ref of an existing frame or shape in the design whose fill becomes the image; its size and position stay. Without it, the image lands as a new layer."
        },
        "imageUrl": {
          "type": "string",
          "description": "An https URL of the image (PNG, JPEG or WebP, up to 25 MB)."
        },
        "imageBase64": {
          "type": "string",
          "description": "The image's bytes as base64 (PNG, JPEG or WebP, up to 25 MB)."
        }
      }
    }
    arguments 51 lines
  • get_knowledge unknown 11h ago

    Use this when writing Blueprint rows for a Brilliant design: it loads Brilliant's Blueprint and design knowledge pages by key (blueprint/core, blueprint/layout, blueprint/paint, blueprint/text, design/foundations). Each key pulls in its prerequisites unless includeDependencies is false; all loads the whole tree page by page within the response budget.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "all": {
          "type": "boolean",
          "description": "Load every page of the tree (the response budget defers the rest by name)."
        },
        "keys": {
          "type": "array",
          "items": {
            "type": "string"
          },
          "description": "Knowledge keys, each a path under the knowledge tree without .md (blueprint/core)."
        },
        "includeDependencies": {
          "type": "boolean",
          "description": "Also load the assumes: prerequisites of each key. Default true."
        }
      }
    }
    arguments 20 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id 362d80ea125ae11b.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/362d80ea125ae11b/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/362d80ea125ae11b/badge.svg)](https://brick.blue/agent/362d80ea125ae11b?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.