Skip to main content
Glama
520,024 tools. Updated 2026-09-06 08:15

"Solid" matching MCP tools:

  • Generate a single composed illustration from a prompt - a scene, environment, hero image, banner, character portrait, or any standalone picture. (For a SET of separate isolated subjects sharing one style - icons, sprites, asset packs - use generate_image_set for solid-color backgrounds, or generate_transparent_image_set for transparent backgrounds, instead.) Returns a zip download URL: the image plus a prompt.json recording what you asked for, plus an index.html viewer. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key. The prompt describes the picture and is used as written (no template, no appended instructions); do not put the pixel size in it - put the size in the width and height arguments. width and height must be one of the supported pixel pairs below; any other pair is rejected. These are the maximums offered - nothing larger is available. Each line is one shape: the first pair is that shape's largest size, the rest are exact proportional downscales of it. Prompt craft, since each call costs a credit: name the light and the time of day (cold blue twilight, one warm lamp from the left), because lighting carries the mood of a single picture; fix the camera (wide establishing shot, three-quarter portrait, viewed from the doorway) so the composition commits to one vantage point; ask for open space on a named side when text will be laid over the picture later; and say no text or lettering unless a word on a sign is the point, since lettering inside a picture is unreliable and titles are better added afterwards. 2816x1584, 1408x792, 704x396 2048x2048, 1024x1024, 512x512, 256x256 1456x2912, 728x1456, 364x728 3200x1440, 1600x720, 800x360 2912x1456, 1456x728, 728x364 1664x2496, 832x1248, 416x624 2496x1664, 1248x832, 624x416 1776x2368, 888x1184, 444x592 2368x1776, 1184x888, 592x444 1584x2816, 792x1408, 396x704 1440x3200, 720x1600, 360x800 Formats: png (default, lossless), jpg, webp. quality (1-100) applies to jpg and webp; default 90. Prompt max length: 2500 characters. A prompt that does not describe a picture is rejected. unpackTo: a directory on your local filesystem to extract the downloaded zip into. filename: name for the image file inside the zip (default illustration.<ext>). If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
    ConnectorAPI key
  • Generate a cohesive SET of custom images with TRANSPARENT backgrounds, each one a separate isolated subject sharing one visual style (icons, logos, sprites, UI assets that need to drop onto any backdrop). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. When a solid colored background fits the user's use case, generate_image_set (1 credit per call) is the faster choice. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key. Output formats: PNG (lossless) or WebP. JPG is not supported because it has no alpha channel. Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations); fixing them resamples to that box, and fixing one axis lets the other hug each subject. IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set. - Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result. - The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing. - Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration'). - Do not put background color or background descriptions in the style or subject descriptions. - Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'. - Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves. - Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase'). - No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign). - No grid lines, borders, frames, or separators. - No overlapping or collage-style arrangements. - Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine. - No dramatic/long drop shadows (subtle shadows are fine). - Image descriptions should describe WHAT to depict, not where to position it. - Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead. - Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia'). - Maximum 18 images per generation. Do not put the image count in the style. - Subjects must be distinct: entries that differ only in case, punctuation, or spacing count as the same subject and the call is rejected. Explicit filenames must be distinct too (a different extension alone is not distinct). - The style must actually describe a visual style, and each subject must name a drawable subject; text that does not is rejected. - Style description max length: 500 characters. Image description max length: 200 characters each. - Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images. - Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set. - Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 18 subjects, 160 with 10 to 12, 180 with 7 to 9, 192 with 5 or 6, 256 with 4 or fewer. Every generation result states its batch's own crisp base size. - If the style check returns a suggested cleanup, show the user the specific changes and get their confirmation, then resubmit the approved prompt with validation set to "skip" so it generates exactly as approved (resubmitting without "skip" re-runs the check and may return further suggestions). See the validation parameter for when to use "skip" and "auto-apply". - If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
    ConnectorAPI key
  • Place a single voxel block at a grid cell, using the same box brush humans use. This is how you BUILD - adding blocks is the default and the action you want almost every time. Coordinates are integer grid cells. World map: wx=gx*0.5, wy=2.0+gy*0.5, wz=gz*0.5. gy=0 is the first solid block layer (world y=2.0). One block per cell. Player-parity: must be within ~15m of where you stand AND the cell must touch the ground or an existing solid block. op defaults to 'add'. Set op:'remove' ONLY to clear a SOLID block that already exists and is in your way - removing an empty cell is rejected as nothing-to-remove and wastes the turn, so never remove on open ground. Failure returns { ok:false, reason, suggested_stand? }. reason is one of: "not-adjacent" (the cell has no solid neighbour below or beside it - it would float; build out from existing blocks), "out-of-reach" (you are too far - move_to(suggested_stand) then retry), "out-of-claim" (outside your buildable area), "material-not-allowed", "nothing-to-remove" (op:remove on empty air), "rate-limited". Only inside your claim, allowed material, additive unless granted destructive.
    Connector
    Destructive
    No auth
  • Materialize a memory or freeform note as a post-item in the space. Position+normal anchor it to a 3D surface: call list_surfaces first to pick a real wall/floor instead of guessing. Put it at EYE LEVEL (a wall face around world y 3.5 to 4), not the foundation row (world y 2.0) where it reads as a floor sticker. Default visibility inherits from the region you stand in (list_regions / inspect_region_provenance to check) or falls back to your private cap. Pass memoryId to link this post to a reflection row in agents.memories. Content shape MUST match the type: text={text:string<=2000}; image={url|asset_key,width,height}; sticker={stickerId} OR {kind:'custom',url,asset_key,width,height}; video={kind:'youtube',youtube_id,...} OR {kind:'streamVideo',stream_uid|hls_url|asset_key|url,...}; card={title?,body?,sourceUrl?,layout?,composition?,...}. The anchor MUST sit on a real surface: the server snaps a near-miss onto the nearest voxel face within ~1.5m, but rejects an anchor with nothing solid in reach (reason no-surface) so a post can never float in mid-air. Returns { ok, postId, memoryId } on accept, { ok:false, reason } on reject (no-surface / capability-missing / type-not-allowed / invalid-content-shape:<type>:<path> / rate-limit-1s / quota-daily / content-too-large / invalid-*). A post landing where you have already looked a lot may be skipped automatically (skipped:true, reason:'low_novelty') to avoid storing redundant observations; pass force:true to override that gate and insert regardless. Delete your own posts with delete_memory_post.
    ConnectorNo auth
  • Performs **network clustering** on a STRING interaction network and returns both a **network image URL** and details about each detected cluster. Use the same parameters as in the network creation step to ensure consistency. If the network already contains disconnected subgraphs, the resulting number of clusters may differ from the requested value. Dashed lines represent connections between clusters, while solid lines indicate interactions within clusters. Notes: - For small queries (≤5 proteins), the `required_score` parameter is automatically lowered to 0. - If only a single cluster is produced, try increasing `required_score`, adjusting the inflation parameter, or switching to `kmeans` for small, highly interconnected networks.
    ConnectorNo auth
  • Strips the background from a video frame-by-frame using rembg (u2netp) on AetherWave's Python service. Pass a public `videoUrl`. Choose `bgType: "transparent"` for an alpha-channel WebM output (compositing) or `bgType: "color"` with a `customColor` hex for a solid replacement. 2 credits per second. Slowest tool in the surface (per-frame processing); a 6s clip takes ~4 min, a 30s clip ~15-20 min. Works best on subjects with clear edges (people, products). Returns the processed video URL (R2-hosted).
    ConnectorNo auth

Matching MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for the Solid protocol enabling AI models to read, write, search, and manage resources in Solid pods.
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for reading, searching, and optionally writing data in Solid Pods via LDP/RDF with headless client-credentials authentication.
    10
    MIT

Matching MCP Connectors

  • Run JavaScript in an isolated sandbox; return a value. One call composes edits. Submit JavaScript; declaration types are guidance. No promises, async/await, dynamic import, or type annotations. Hosted note: execute runs in an on-demand isolate and costs more than the direct render_svg/render_ascii/render_png/verify/describe tools — prefer those for plain render/verify calls. For straightforward structured edits, prefer the declarative mutate/build tools; reserve execute for logic the ops don't express. Hosted mermaid.renderMermaidSVG*, renderMermaidASCII*, and layoutMermaidWithReceipt calls force security:'strict' and embedFontImport:false; caller code cannot weaken that host policy. SDK declaration: type DiagramKind = 'flowchart' | 'state' | 'sequence' | 'timeline' | 'class' | 'er' | 'journey' | 'architecture' | 'xychart' | 'pie' | 'quadrant' | 'gantt' | 'mindmap' | 'gitgraph' | 'radar' type MutationOp = { kind: string; [field: string]: unknown } type Result<T, E = { code: string; message: string }> = { ok: true; value: T } | { ok: false; error: E } interface SourceLocation { readonly line: number; readonly col: number } interface SourceMapSpans { readonly preserved: PreservedSourceSpans; readonly nodes: ReadonlyMap<string, SourceSpan>; readonly edges: ReadonlyMap<string, SourceSpan>; readonly groups: ReadonlyMap<string, SourceSpan>; readonly labels: ReadonlyMap<string, SourceSpan> } interface SourceMap { readonly nodes: ReadonlyMap<string, SourceLocation>; readonly edges: ReadonlyMap<string, SourceLocation>; readonly groups: ReadonlyMap<string, SourceLocation>; readonly labels: ReadonlyMap<string, SourceLocation>; readonly spans?: SourceMapSpans } interface ValidDiagram { readonly kind: DiagramKind; readonly source: SourceMap } type ExternalFamilyId = `family:${string}` interface ExtensionCompatibility { readonly [contract: string]: string | undefined readonly core?: string readonly scene?: string } interface ExtensionProvenance { readonly owner: string; readonly source: string; readonly reference?: string } interface ExtensionIdentity<Kind extends string = string> { readonly id: `${Kind}:${string}` readonly kind: Kind readonly version: string readonly compatibility: ExtensionCompatibility readonly provenance: ExtensionProvenance } interface SourceSpanPoint { readonly offset: number; readonly line: number; readonly col: number } interface SourceSpan { readonly start: SourceSpanPoint; readonly end: SourceSpanPoint } interface PreservedSourceSpans { readonly source: SourceSpan readonly wrapper?: SourceSpan readonly frontmatter?: SourceSpan readonly initDirectives?: readonly SourceSpan[] readonly accessibilityDirectives?: readonly SourceSpan[] readonly header: SourceSpan readonly body: SourceSpan } interface SourcePreservationReceipt { readonly version: 1 readonly classification: 'unsupported' | 'inventory-only' | 'unknown' readonly source: string readonly header: string readonly upstreamFamilyId?: string readonly mermaidVersion: string readonly spans?: PreservedSourceSpans } interface ParseError { readonly code: string readonly message: string readonly line?: number readonly col?: number readonly preservation?: SourcePreservationReceipt readonly help?: string } interface ExtensionValidDiagram { readonly kind: ExternalFamilyId readonly descriptorIdentity: ExtensionIdentity<'family'> readonly source: SourceMap } interface PreservedValidDiagram { readonly kind: ExternalFamilyId readonly source: SourceMap readonly body: { readonly kind: 'preserved' readonly representation: 'opaque' | 'unknown' readonly source: string readonly preservation: SourcePreservationReceipt readonly spans: PreservedSourceSpans readonly diagnostic: { readonly code: 'UNSUPPORTED_FAMILY' | 'UNKNOWN_HEADER' | 'FAMILY_DESCRIPTOR_MISMATCH' readonly message: string readonly help: string } } } type ParsedDiagram = ValidDiagram | ExtensionValidDiagram | PreservedValidDiagram type RenderedRegionKind='node'|'edge'|'label'|'canvas'|'group'|'cluster'|'lane'|'band'|'compartment'|'plot'|'ring' type DiagramActionSecurity='safe'|'unsafe'|'source-only'|'unsupported' interface RenderedRegion { id:string;kind:RenderedRegionKind;elementId?:string;parentId?:string;bounds:{x:number;y:number;w:number;h:number};sourceLine?:number } interface DiagramActionRecord { id?:string;regionId?:string;family:DiagramKind;target:string;action:'href'|'call'|'callback';raw:string;line?:number;href?:string;security:DiagramActionSecurity;executable:false;message?:string } interface RenderedLayout { version: 1; kind: DiagramKind | ExternalFamilyId; bounds: { w: number; h: number }; nodes: unknown[]; edges: unknown[]; groups: unknown[]; regions?: RenderedRegion[]; actions?: DiagramActionRecord[] } interface VerifyResult { ok: boolean; warnings: unknown[]; layout: RenderedLayout } type CheckMermaidSpec = string[] | { include?: string[]; exclude?: string[]; exact?: boolean } interface CheckMermaidResult { ok: boolean; missing: string[]; unexpected: string[]; facts: string[] } type MermaidConfigScalar = string | number | boolean | null type MermaidConfigValue = MermaidConfigScalar | MermaidConfigValue[] | { [key: string]: MermaidConfigValue | undefined } type MermaidRuntimeConfig = { [key: string]: MermaidConfigValue | undefined } interface StyleColors {bg?:string;fg?:string;line?:string;accent?:string;muted?:string;surface?:string;border?:string} type SceneStyleRole="node"|"edge"|"edge-label"|"group"|"group-header"|"label"|"actor"|"lifeline"|"activation"|"message"|"block"|"note"|"class-box"|"member"|"entity"|"attribute"|"relationship"|"cardinality"|"pie-slice"|"legend"|"bar"|"series"|"point"|"axis"|"grid"|"plate"|"section"|"task"|"milestone"|"marker-line"|"rail"|"period"|"event"|"score"|"actor-pill"|"service"|"junction"|"icon"|"title"|"defs"|"prelude"|"chrome" type ExactSceneStyleRole="node"|"edge"|"group"|"group-header"|"label"|"actor"|"relationship"|"pie-slice"|"legend"|"bar"|"series"|"point"|"task"|"milestone" type BindableSceneStyleRole="group-header"|"actor"|"relationship"|"pie-slice"|"legend"|"bar"|"series"|"point"|"task"|"milestone" type RoleStyleSpec={"fontFamily"?:string;"fontSize"?:number;"fontWeight"?:number;"letterSpacing"?:number;"textTransform"?:"uppercase"|"lowercase"|"capitalize";"textColor"?:string;"paddingX"?:number;"paddingY"?:number;"cornerRadius"?:number;"lineWidth"?:number;"bendRadius"?:number;"fillColor"?:string;"borderColor"?:string;"strokeColor"?:string;"headerFillColor"?:string;"cue"?:"none"|"outline"|"double-line"|"pattern"} type RoleStyleFor<R extends ExactSceneStyleRole>=R extends "node"|"actor"?Pick<RoleStyleSpec,"borderColor"|"cornerRadius"|"fillColor"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"paddingX"|"paddingY"|"textColor"|"textTransform">:R extends "edge"|"relationship"?Pick<RoleStyleSpec,"bendRadius"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"strokeColor"|"textColor"|"textTransform">:R extends "group"?Pick<RoleStyleSpec,"borderColor"|"cornerRadius"|"fillColor"|"fontFamily"|"fontSize"|"fontWeight"|"headerFillColor"|"letterSpacing"|"lineWidth"|"paddingX"|"paddingY"|"textColor"|"textTransform">:R extends "group-header"?Pick<RoleStyleSpec,"borderColor"|"cue"|"fillColor"|"fontFamily"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"strokeColor"|"textColor"|"textTransform">:R extends "label"?Pick<RoleStyleSpec,"fontSize"|"fontWeight"|"letterSpacing"|"textColor"|"textTransform">:R extends "pie-slice"|"task"|"milestone"?Pick<RoleStyleSpec,"borderColor"|"cue"|"fillColor"|"lineWidth"|"strokeColor">:R extends "legend"?Pick<RoleStyleSpec,"borderColor"|"fillColor"|"lineWidth"|"strokeColor"|"textColor">:R extends "bar"|"point"?Pick<RoleStyleSpec,"borderColor"|"fillColor"|"lineWidth"|"strokeColor">:R extends "series"?Pick<RoleStyleSpec,"borderColor"|"lineWidth"|"strokeColor">:never type RoleStyles={[R in ExactSceneStyleRole]?:Readonly<RoleStyleFor<R>>} type SemanticBindingChannel="category" interface SemanticBinding {channel:SemanticBindingChannel;value:string;slot:string;role?:BindableSceneStyleRole} type BrandConstraint={kind:"contrast";action:'warn'|'error';role?:SceneStyleRole;minimum?:number}|{kind:"accent-area";action:'warn'|'error';maxFraction:number}|{kind:"mono-role";action:'warn'|'error';role:SceneStyleRole} interface StyleSpec {"formatVersion"?:1;"$schema"?:string;"name"?:string;"blurb"?:string;"colors"?:StyleColors;"font"?:string;"roles"?:RoleStyles;"semanticSlots"?:Readonly<Record<string,Readonly<RoleStyleSpec>>>;"bindings"?:readonly SemanticBinding[];"constraints"?:readonly BrandConstraint[];"stroke"?:"crisp"|"jittered"|"freehand";"roughness"?:number;"bowing"?:number;"passes"?:number;"strokeWidth"?:number;"fill"?:"none"|"hachure"|"solid"|"wash";"hachureAngle"?:number;"hachureGap"?:number;"fillWeight"?:number;"washOpacity"?:number;"washEdge"?:number;"backdrop"?:"plain"|"paper-ruled"|"grid";"intent"?:"premium"|"draft"|"lofi";"mono"?:boolean} type StyleInput=string|StyleSpec type ArchitectureVisualOverrides = Readonly<Record<string, unknown>> interface SharedRenderOptions { bg?:string;fg?:string;line?:string;accent?:string;muted?:string;surface?:string;border?:string;font?:string;style?:StyleInput | StyleInput[];padding?:number;nodeSpacing?:number;layerSpacing?:number;wrappingWidth?:number;componentSpacing?:number;transparent?:boolean;interactive?:boolean;shadow?:boolean;class?:{ hierarchicalNamespaces?:boolean };architecture?:{ visual?:ArchitectureVisualOverrides };timeline?:{ maxWidth?:number };journey?:{ experienceCurve?:boolean };gantt?:{ dependencyArrows?:boolean; criticalPath?:boolean };mermaidConfig?:MermaidRuntimeConfig;embedFontImport?:boolean;compact?:boolean;idPrefix?:string;security?:'default' | 'strict';ganttToday?:string;seed?:number;} interface ConfigDiagnostic { code: 'INEFFECTIVE_CONFIG'; field: string; message: string } interface TerminalProjectionDiagnostic { code: string; feature: string; message: string } interface SvgRenderOptions extends SharedRenderOptions { onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;} interface AsciiRenderOptions extends SharedRenderOptions { useAscii?:boolean;paddingX?:number;paddingY?:number;boxBorderPadding?:number;colorMode?:'auto' | 'none' | 'ansi16' | 'ansi256' | 'truecolor' | 'html';theme?:{ fg?:string; border?:string; line?:string; arrow?:string; accent?:string; bg?:string; corner?:string; junction?:string };maxWidth?:number;targetWidth?:number;onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;onProjectionDiagnostic?:(diagnostic: TerminalProjectionDiagnostic) => void;} interface LayoutRenderOptions extends SharedRenderOptions { debug?:boolean;regions?:boolean;actions?:boolean;onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;} interface RenderArtifactDiagnostic { code: string; message?: string; reference?: string; feature?: string; input?: string; canonicalId?: string; removal?: { release: string; date: string } } interface CapabilityResolution { readonly id: `${string}:${string}`; readonly range: string; readonly level: 'required' | 'preferred' | 'optional'; readonly status: 'selected' | 'unsupported' | 'incompatible'; readonly version?: string } interface CapabilityDecision { readonly version: 1; readonly accepted: boolean; readonly resolutions: readonly CapabilityResolution[] } interface RenderExecutionDecision { readonly family: { readonly id: string; readonly version: string };readonly backend: { readonly mode: 'scene'; readonly requestedId: string; readonly selectedId: string; readonly version: string; readonly hostPolicy: boolean } | { readonly mode: 'family-svg' };readonly digest: string;} interface RenderRequestReceipt { version: 2; output: 'svg' | 'png' | 'ascii' | 'unicode' | 'html' | 'layout'; sharedRequestDigest: string; requestDigest: string; appearanceDigest: string; capabilityDecision: CapabilityDecision; diagnostics?: readonly RenderArtifactDiagnostic[]; graphicalProjectionDigest?: string; executionDecision?: RenderExecutionDecision } interface RenderedSvg { svg: string; receipt: RenderRequestReceipt } interface RenderedAscii { text: string; receipt: RenderRequestReceipt; terminalStyle: Record<string, unknown>; outputPolicy: Record<string, unknown> } interface RenderedLayoutArtifact { layout: VerifyResult['layout']; receipt: RenderRequestReceipt } declare const mermaid: { parseRegisteredMermaid(source: string): Result<ParsedDiagram, ParseError[]> createMermaid(kind: DiagramKind, opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): ValidDiagram buildMermaid(kind: DiagramKind, ops: MutationOp[], opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): Result<ValidDiagram, { code: string; message: string; opIndex: number }> asFlowchart(diagram: ValidDiagram): ValidDiagram | null asState(diagram: ValidDiagram): ValidDiagram | null asSequence(diagram: ValidDiagram): ValidDiagram | null asTimeline(diagram: ValidDiagram): ValidDiagram | null asClass(diagram: ValidDiagram): ValidDiagram | null asEr(diagram: ValidDiagram): ValidDiagram | null asJourney(diagram: ValidDiagram): ValidDiagram | null asArchitecture(diagram: ValidDiagram): ValidDiagram | null asXyChart(diagram: ValidDiagram): ValidDiagram | null asPie(diagram: ValidDiagram): ValidDiagram | null asQuadrant(diagram: ValidDiagram): ValidDiagram | null asGantt(diagram: ValidDiagram): ValidDiagram | null asMindmap(diagram: ValidDiagram): ValidDiagram | null asGitGraph(diagram: ValidDiagram): ValidDiagram | null asRadar(diagram: ValidDiagram): ValidDiagram | null mutate(diagram: ValidDiagram, op: MutationOp): Result<ValidDiagram> verifyMermaid(input: ParsedDiagram | string, opts?: { suppress?: string[]; labelCharCap?: number; renderOptions?: SharedRenderOptions }): VerifyResult analyzeMermaid(diagram: ValidDiagram): Record<string, unknown> analyzeMermaidSource(source: string): Result<Record<string, unknown>> describeMermaidFacts(diagram: ValidDiagram): string[] describeMermaidFactsSource(source: string): Result<string[]> checkMermaid(diagram: ValidDiagram, spec: CheckMermaidSpec): CheckMermaidResult checkMermaidSource(source: string, spec: CheckMermaidSpec): Result<CheckMermaidResult> serializeMermaid(diagram: ParsedDiagram): string renderMermaidSVG(input: ParsedDiagram | string, opts?: SvgRenderOptions): string renderMermaidSVGWithReceipt(input: ParsedDiagram | string, opts?: SvgRenderOptions): RenderedSvg renderMermaidASCII(input: ParsedDiagram | string, opts?: AsciiRenderOptions): string renderMermaidASCIIWithReceipt(input: ParsedDiagram | string, opts?: AsciiRenderOptions): RenderedAscii layoutMermaidWithReceipt(input: ParsedDiagram | string, opts?: LayoutRenderOptions): RenderedLayoutArtifact describeOps(family: DiagramKind): Record<string, { name: string; required: boolean; type: string; note?: string }[]> opSignatures(family: DiagramKind): string[] }
    ConnectorNo auth
  • Generate a cohesive SET of custom images on a SOLID-COLOR background, each one a separate isolated subject sharing one background and one visual style (icons, logos, game assets, UI elements, sprite/asset packs). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key. For TRANSPARENT-background output, use generate_transparent_image_set instead (1 credit per call). For a SINGLE composed picture or a full-bleed scene (hero image, banner, character portrait, environment), use generate_illustration instead. Output formats: PNG (lossless), JPEG, or WebP. Images can be delivered at a fixed width and height, at one fixed axis with the other hugging each subject, or at their native resolution. Size and quality considerations: Leaving width and height unset delivers images at their native resolution with zero scaling, which produces the highest quality results and is recommended when images will be post-processed, composited, or resized downstream. Native output dimensions vary between generations and track the subject count - roughly 650-950px per side for small sets, down to roughly 400-650 at the full 18; fewer subjects means larger native images. Fixing width and height (e.g. 512 and 512) guarantees consistent dimensions across all images and generations but applies resampling which may soften fine details; fixing one axis lets each image keep its subject's own proportion on the other. IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set. - Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result. - The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing. - Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration'). - Do not put background color or background descriptions in the style or subject descriptions. - Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'. - Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves. - Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase'). - No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign). - No grid lines, borders, frames, or separators. - No overlapping or collage-style arrangements. - Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine. - No dramatic/long drop shadows (subtle shadows are fine). - Image descriptions should describe WHAT to depict, not where to position it. - Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead. - Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia'). - Maximum 18 images per generation. Do not put the image count in the style. - Subjects must be distinct: entries that differ only in case, punctuation, or spacing count as the same subject and the call is rejected. Explicit filenames must be distinct too (a different extension alone is not distinct). - The style must actually describe a visual style, and each subject must name a drawable subject; text that does not is rejected. - Style description max length: 500 characters. Image description max length: 200 characters each. - Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images. - Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set. - Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 18 subjects, 160 with 10 to 12, 180 with 7 to 9, 192 with 5 or 6, 256 with 4 or fewer. Every generation result states its batch's own crisp base size. - If the style check returns a suggested cleanup, show the user the specific changes and get their confirmation, then resubmit the approved prompt with validation set to "skip" so it generates exactly as approved (resubmitting without "skip" re-runs the check and may return further suggestions). See the validation parameter for when to use "skip" and "auto-apply". - If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
    ConnectorAPI key
  • Judge whether a specific asking price for a PC part is good, by comparing it against tracked market data. Use when someone asks 'is $X a good price for Y' or wants a listing sanity-checked. Strongest for RAM, which is compared per-GB against the daily index; for other parts it falls back to matching deal headlines and says so. Returns 'insufficient_data' rather than guessing when there is nothing solid to compare against.
    ConnectorNo auth
  • Add a link to the linked account's SmartSite, with smart placement. TWO STEPS: (1) call with just the url — the tool detects what kind of link it is (payment like Venmo/PayPal/Cash App, social, contact, website) and returns a recommendation with a text preview of each layout: a small ICON in the icon row, a link BUTTON tile, or a full-width INFOBAR call-to-action card. Show the user the message + previews and ask which they want. (2) call again with the same url plus displayAs = 'icon' | 'button' | 'infobar' to place it. You can override title / buttonName / description / style ('solid' | 'glass') for an info bar. Returns a viewUrl to preview the result.
    ConnectorNo auth
  • Build many blocks at once with macro ops, each expanded into individual box brushes. Coordinates are integer grid cells. World map: wx=gx*0.5, wy=2.0+gy*0.5, wz=gz*0.5. gy=0 is the first solid block layer (world y=2.0). One block per cell. Ops: {op:'box',min:[gx,gy,gz],max:[gx,gy,gz],material,operation?} (filled box); {op:'shell',min,max,material} (hollow box); {op:'layer',y,material,cells:[[gx,gz],...]} (flat layer); {op:'line',from:[gx,gy,gz],to:[gx,gy,gz],material}. min/max are INCLUSIVE on every axis, so min:[-8,0,-6],max:[-6,0,-6] is 3 cells wide (-8,-7,-6), not 2 - off-by-one here is the #1 cause of a door that ends up 1 wide. operation is the build-op field for add/remove: operation 0=add (default), 1=remove (destructive) - this is the SAME concept as place_block's op:'add'|'remove', just a different name/shape on this tool. All coords are GRID cells. Build any size: a call places blocks until a wall-time budget, then returns remaining > 0 so you call build again to continue (already-placed cells no-op) - there is no block-count cap, and a real 5000+ block structure takes 15-40 build() calls. Interiors must fit your body (>= 2 cells wide x >= 4 tall, openings >= 2x4, stairwells open overhead, or you trap yourself) - call get_build_info for the full spec + worked examples. After building an interior, test-walk it with move_to and remove (op:"remove") any block too tight. Returns { placed, total, remaining (>0 means call build again to finish), rejected (count by reason), rejected_cells:[{gx,gy,gz,reason}] (the exact cells that failed, so you can patch the gaps), stopped_reason?, suggested_stand? }.
    Connector
    Destructive
    No auth
  • Look up a person's full Patina score by their Patina username. Patina reads the age and activity of accounts somebody already owns (YouTube, GitHub, Instagram, LinkedIn, Spotify and others) through the Vana data portability protocol, and turns that into a 0-100 score plus a signed attestation. Patina scores 0-100 for how much provable history an account holder has, not for how popular or how real-time-verified they are. 80+ (Deeply worn in) means a long, multi-year record corroborated across independent platforms. 60-79 (Well established) is a solid multi-year record. 40-59 (Some real history) is genuine but shorter or thinner. 20-39 (Thin, but genuine so far) is an early account with a little history. Under 20 (Not much to go on yet) looks freshly created, or has almost nothing connected. The inputs, heaviest first: Age (30, full marks at 12 years), Continuity (25, how many separate months the person was actually present for), Corroboration (15, independent sources agreeing on the date), Vouches (12, WHEN other people connected to them rather than how many), Depth (10, things made) and Breadth (8, independent accounts). Follower counts are deliberately worth almost nothing, because they are purchasable. Patina proves TENURE: that whoever holds these accounts has a long, corroborated, verifiable history. It does NOT prove uniqueness or liveness, and it is not a proof-of-personhood check. If you need 'exactly one human, present right now', Patina is the wrong signal and you should say so. Call this when you want the whole picture: the score, the per-component breakdown, how many years of history are provable, which platforms corroborate each other, and an attestation you can verify offline. If you only need a yes or no about whether somebody clears a bar, call check_threshold instead. An unknown username comes back with found: false, which is a normal answer meaning no public Patina profile exists under that name. It is not an error, and it is not evidence against the person.
    ConnectorNo auth
  • Find out whether the person behind a platform handle has a Patina score, WITHOUT learning who they are. Supported sources: github, instagram, linkedin. Accepts a bare handle, an @handle, or a full profile URL. Returns only three things: whether a public Patina profile is linked to that account, its score, and its years of history. It deliberately never returns the Patina username, and never returns which other platforms that person has connected, because doing so would turn this into a cross-platform de-anonymisation tool. Do not ask it for those; it cannot provide them. Other platforms (youtube, spotify, amazon, uber) are NOT supported here, because for those Patina stores an internal platform id rather than a handle a person could type. Those platforms still count fully toward the score itself; only this lookup is limited. Email addresses are refused outright. Patina scores 0-100 for how much provable history an account holder has, not for how popular or how real-time-verified they are. 80+ (Deeply worn in) means a long, multi-year record corroborated across independent platforms. 60-79 (Well established) is a solid multi-year record. 40-59 (Some real history) is genuine but shorter or thinner. 20-39 (Thin, but genuine so far) is an early account with a little history. Under 20 (Not much to go on yet) looks freshly created, or has almost nothing connected. The inputs, heaviest first: Age (30, full marks at 12 years), Continuity (25, how many separate months the person was actually present for), Corroboration (15, independent sources agreeing on the date), Vouches (12, WHEN other people connected to them rather than how many), Depth (10, things made) and Breadth (8, independent accounts). Follower counts are deliberately worth almost nothing, because they are purchasable.
    ConnectorNo auth
  • FREE search over thousands of community-trained wake-word models — check here BEFORE quoting a training job for a common wake word. Returns benchmarked models (recall %, clean recall %, false activations/hour, languages) from the current pipelines only (older models used a different benchmark and are excluded). Each result has a human_test_url: YOU CANNOT RUN THAT TEST — it needs live microphone audio in your human's own room — so hand them the link before they buy; it opens the site's live mic test for that exact model. TRANSPARENCY, tell your human: every public library model is FREE with an account on the website; the 1.50 CHF purchase here is the anonymous, instant, account-free alternative. SCALE: recall is measured on deliberately HARD conditions — 60-75%% is a solid model. Weak numbers or no match? Train a custom model with create_training_job instead.
    ConnectorNo auth
  • TWO WRITE VERBS, chosen by where the text lands (BOTH are live — there is no single-verb 'submit-only' mode): contribution = APPEND to the pool (the shared spool everyone pulls; this is the basic pool / chat — the committed entry); submit = STAGE to the liquid buffer (the revisable pre-commit mirror, for windowed/reflexive use such as xstream's typing preview). Reading pulls everything past your since_position marker (the read-cursor — a DIFFERENT thing from the 'resolution marker'/breadcrumb the room-pool model removed). — Engage a pool at a federated beach with a synthesis envelope: purpose + synthesis_hint + new contributions since your marker. There is NO central resolver — each reader's LLM produces its own personal synthesis from the same stream. The primitive is the SPOOL (transport); it never synthesises. The spool/frame/destination split (docs/RPG-POOL-STATE.md §4) governs the optional verbs: (1) `submit` STAGES text to the pre-commit liquid buffer (liquid:pool:<name>, one slot per author, OVERWRITING) and returns the social mirror of all co-present pending intentions — no pool append, no synthesis; empty string withdraws; (2) `contribution` COMMITS — atomic append of the text (raw OR an LLM-produced synthesis; agnostic) to `destination` ('pool' default = the shared spool everyone pulls, or a block name like 'solid:<name>' for a shared artifact — the objective dial); (3) `purpose` creates the pool if absent with the right object shape — NEVER use raw bsp() with content='<purpose>' which makes a malformed bare-string block. submit and contribution may combine. Marker is caller-managed — pass since_position in, store marker_new. synthesis_hint sourced from the pool's underscore (which may point at an external directive, e.g. function:<game>/1), else a default. RPG's subjective resolution (writing per-subject history:<handle> spines) is the resolver's bsp() job, not this primitive. Defaults to https://beach.happyseaurchin.com; pass pool_url to target a different beach.
    Connector
    Destructive
    No auth
  • Search Font Awesome Free (2000+ icons) by keyword: matches names, labels, and official search terms, ranked. Returns icon names, available styles (solid/regular/brands), and terms. Use the chosen name in POST /api/icon/generate. ($0.002 per call, paid via x402)
    ConnectorNo auth
  • List the available color themes (solid and gradient) for generate_qr and generate_pixel_art_qr.
    ConnectorNo auth
  • NOTE: differentiates by English share only - all non-English languages score identically, so it cannot rank es vs fr vs de. FREE word-quality check — use BEFORE paying. Predicts the recall a training run would reach for this wake word plus false-activation risk (model trained on thousands of real jobs). SCALE: predictions are for deliberately HARD benchmark conditions (loud noise, reverb) — 60-75 is a solid word, very usable in real rooms; do NOT reject words for scoring below ~80. 2-4 syllable phrases work best; only warn your human when the score is under ~50.
    ConnectorNo auth
  • Remove or replace an image background through Uwear's canonical free backdrop generation path. Provide exactly one foreground source: generation_result_id, clothing_item_asset_id, or a public HTTPS image_url. Use backdrop_mode transparent, solid with color_hex, or image with background_image_url. Returns generation_id; poll get_generation_status, then fetch get_generation_results.
    ConnectorNo auth
  • Render a visual onto a post at CP3, or edit an existing image. scope: 'full' (default) renders a new visual and requires `background`. 'recomposite' re-composites new text, color, or size over the retained background at no charge. 'restore' reverts to the prior image from history, at no charge. 'reframe' produces a per-platform aspect variant from the retained background, at no charge. background (required for scope='full'): • 'photo': a generated AI/photographic image with the headline composited over it. ~30 credits, ~30-90s, asynchronous: returns status='rendering_image_card'; poll niche_session_state (image_render.status: rendering, then done with static_urls on the output, or failed with credits refunded). A repeat call while a render is in flight is a no-op. • 'design': the INFOGRAPHIC, a generated editorial graphic that DRAWS the argument (a ranked bar chart, a two-column diagram, a stat, a before/after, a pull-quote), on-brand and legible, with vetted icons. The designer art-directs the treatment from the brand PALETTE (leads light for data, dark for narrative; accent as a spice), and honors a look steer in design_concept ('brighten it up', 'a ranked bar chart', 'navy and gold'). ~30 credits, asynchronous (poll as above). • 'brand_color': a flat brand card with the headline on the brand's solid color with logo and wordmark. No generation, no credits, synchronous. • 'svg': you author the card exactly as SVG markup (pass `svg`); the server rasterizes it to the cell's dimensions. Free, instant, deterministic. The right choice for data, labels, charts, and comparisons (where generated images fail at layout), and the only visual that works from a network-locked sandbox (SVG is text). The SVG owns the whole canvas; use brand colors and fonts from niche_whoami. Static shapes, paths, and text only (no scripts, external references, or foreignObject). `headline` sets the bold header (defaults to the post's card_headline; auto-fits, not truncated). Idempotent: a prior render is replaced. Errors: render_not_ready before CP3; render_not_configured when image generation is unavailable; render_card_unavailable when background='brand_color' but the piece has no card-bearing platform.
    ConnectorNo auth
  • Make a stablecoin token that uses the ERC-20 standard. Experimental, some features are not audited and are subject to change. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
    ConnectorNo auth