GravityPort
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Save generated images with the effective prompt, distinct user prompt when available, negative constraints, reference hashes, and generation provenance. GravityPort records immutable recipe snapshots automatically. Use generation_record for each distinct generation occurrence, even when its output asset was deduplicated; use generation_relation_record only for evidence-backed parent relationships, and generation_lineage to read the resulting graph. provider_verified is reserved for trusted GravityPort provider integrations and cannot be asserted by ordinary MCP callers. Use asset_version_create only for explicit asset-version workflows.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| asset_createA | Copy an image into the GravityPort library and save prompt recipe metadata. The image path must be an absolute path on this machine. Symbolic links are rejected. Only supported image and video formats are imported. Identical bytes already in the library (outside Trash) return the existing asset with deduplicated: true instead of creating a copy. |
| asset_import_folderA | Import every image and video found in a local folder into the GravityPort library, applying the same prompt/sourceType/source to each file. The folder path must be an absolute path on this machine. Symbolic links are skipped; with recursive: true the folder itself is level 1 and its contents are read down to level 5 (at most four subfolder levels below it), and deeper subfolders are skipped; a single call imports at most 1000 files, otherwise it fails and asks for batches. Identical bytes already in the library are reported as deduplicated. Files import one by one; a failed file is reported and does not stop the rest. Files already in the library are listed in duplicates with the existing assetId. |
| asset_listA | List saved GravityPort assets for a project, optionally filtered by search text. Returns compact per-asset summaries with the total count (20 per page by default, at most 100; pass |
| asset_searchA | Search GravityPort visual memory using lexical search and explicit creation-time bounds. Multiple query words are combined with AND: every word must appear for an asset to match; OR is not supported. Returns compact per-asset summaries with the total match count (20 per page by default, at most 100; pass |
| asset_getA | Get one saved asset and its full prompt recipe. asset_list and asset_search return only compact summaries; call this for the full recipe and metadata. |
| asset_provenance_exportA | Export a portable GravityPort provenance bundle plus an unsigned C2PA assertion payload. Prompts and user messages are excluded by default; pass includePrompts: true only when the user explicitly asks to include prompts. Local filesystem paths and usernames are never exported under any circumstances. This does not create a signed Content Credential; a C2PA signer must bind and sign the assertion separately. |
| asset_trashA | Move an asset to Trash. Trashed assets can be restored with asset_restore or inside the GravityPort app, and are permanently purged after 90 days. Use this when the user asks to delete or remove an asset. Do NOT use this when the user asks to archive or stash an asset. |
| asset_restoreA | Restore an asset from Trash back to the active library. |
| asset_duplicateB | Create an independent editable copy that starts a new version root while retaining duplicate provenance. |
| asset_version_createC | Save a new recipe version as a child of an existing asset without overwriting the parent. |
| asset_version_historyB | Read the complete root-to-descendant recipe version tree for an asset, including archived versions. |
| asset_recipe_historyA | Read immutable generation recipe snapshots for one asset and identify the currently active snapshot. |
| asset_update_metadataC | Update metadata fields for a saved asset. Pass |
| asset_attach_promptC | Attach or replace the full prompt recipe for a saved asset. |
| generation_recordB | Record one generation occurrence independently from the deduplicated output asset. Use this when an agent knows that a specific generation produced a saved GravityPort asset. |
| generation_listC | List generation occurrences, optionally filtered by output asset or provider identifiers. |
| generation_relation_recordA | Record an explicit generation-to-generation relationship such as edited_from or variant_of. Do not infer a parent unless the evidence supports it. When verificationLevel is omitted the relation is recorded as user_confirmed (you are asserting it on the user's behalf); pass "observed" or "inferred" to record a weaker evidence level. |
| generation_lineageA | Read the connected generation lineage graph around one generation event, including parent/child IDs and evidence-bearing relations. |
| stack_createA | Group two or more saved assets into a new stack, the same as stacking a selection in the GravityPort app. coverAssetId defaults to the first asset. name (optional, at most 80 characters) is the stack's display name. An asset can belong to only one stack: if any asset is already in a stack the call fails with ASSET_ALREADY_STACKED and nothing changes; take it out with stack_remove_assets first. To show the same image in several stacks, copy it with asset_duplicate and stack the copy. Archived assets cannot be stacked. |
| stack_add_assetsA | Add saved assets to an existing stack, after its current members. Assets already in this stack are skipped and listed in alreadyInStack. If any asset belongs to a different stack the call fails with ASSET_ALREADY_STACKED and nothing changes. |
| stack_renameB | Set a stack's display name (trimmed, 1 to 80 characters). The name is kept even when the stack was created automatically from a conversation. |
| stack_remove_assetsA | Take assets out of a stack; the assets stay in the library. Every assetId must belong to this stack, otherwise the call fails with ASSET_NOT_IN_STACK and nothing changes. A stack left with one asset is dissolved (dissolved: true). Assets taken out are not stacked again automatically. |
| stack_dissolveA | Dissolve a stack: its assets return to the library as separate assets; nothing is deleted or archived. They are not stacked again automatically. |
| stack_getA | Read one stack: its name, cover, member count, and member asset IDs in stack order. Members in Trash or archived are left out. |
| stack_listB | List the stacks shown in the GravityPort library (two or more visible members), most recently updated first, optionally filtered by text in the stack name. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 25 tools
Most tools map to a distinct resource+action, with clear groupings around assets, stacks, and generations. The main friction is between asset_version_history, asset_recipe_history, and asset_get, which all read some form of asset history/recipe and could be confused, plus asset_update_metadata vs asset_attach_prompt which both mutate recipe data.
Every tool follows a strict resource-prefix + action pattern (asset_*, stack_*, generation_*) in snake_case with no deviations. The prefixes themselves act as a natural taxonomy, making the surface highly predictable.
25 tools is at the heavy end for a single server and pushes against the comfortable 3-15 range. The three domains (assets, stacks, generations) justify some breadth, but several near-duplicate history/recipe readers suggest the surface could be trimmed.
Coverage is strong: assets have create/import/list/search/get/trash/restore/duplicate/version/prompt/provenance, stacks have full create/add/remove/rename/dissolve/get/list, and generations have record/relation/lineage/list. Minor gaps exist, such as no permanent purge, no stack cover/ordering update, and no generation edit/delete operations.