Servidor MCP para Prismism — DocSend para agentes de IA.
Sube cualquier archivo → obtén un enlace rastreable y compartible. PDF, HTML, Markdown, imágenes, vídeo. Control de acceso, análisis, captura de correo electrónico, webhooks.
Crea una cuenta gratuita en prismism.dev o utiliza la herramienta prismism_register después de la configuración.
No requiere instalación: conéctate directamente a la API de Prismism:
Claude Code
claude mcp add prismism --transport http https://prismism.dev/mcp \
--header "x-api-key: pal_your_key_here"Claude Desktop — edita ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"prismism": {
"url": "https://prismism.dev/mcp",
"headers": {
"x-api-key": "pal_your_key_here"
}
}
}
}Cursor — edita .cursor/mcp.json:
{
"mcpServers": {
"prismism": {
"url": "https://prismism.dev/mcp",
"headers": {
"x-api-key": "pal_your_key_here"
}
}
}
}Windsurf — edita ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"prismism": {
"serverUrl": "https://prismism.dev/mcp",
"headers": {
"x-api-key": "pal_your_key_here"
}
}
}
}VS Code — edita .vscode/mcp.json:
{
"servers": {
"prismism": {
"type": "http",
"url": "https://prismism.dev/mcp",
"headers": {
"x-api-key": "pal_your_key_here"
}
}
}
}Ejecuta mediante npx si prefieres el transporte local:
{
"mcpServers": {
"prismism": {
"command": "npx",
"args": ["@prismism/mcp-server"],
"env": {
"PRISMISM_API_KEY": "pal_your_key_here"
}
}
}
}Pregunta a tu agente: "Use the prismism_health tool to check the connection"
Related MCP server: @putput/mcp
Herramienta | Autenticación requerida | Descripción |
| — | Comprobar conexión y estado de autenticación |
| — | Crear cuenta + obtener clave API (una sola vez) |
| ✓ | Publicar un archivo, HTML o Markdown y obtener un enlace compartible |
| ✓ | Listar tus artefactos con paginación |
| ✓ | Obtener detalles del artefacto + análisis |
| ✓ | Actualizar título, nivel de acceso, puertas, contenido o caducidad |
| ✓ | Obtener contenido bruto del artefacto (texto o base64) |
| ✓ | Eliminar permanentemente un artefacto |
| ✓ | Obtener información de la cuenta, plan y uso |
"Publish this report as a shareable link"La herramienta prismism_publish admite tres modos:
Carga de archivos — Establece content (texto plano o base64) + filename. Usa encoding: "base64" para archivos binarios.
HTML en línea — Establece html con contenido HTML bruto. No se necesita archivo.
Markdown en línea — Establece markdown con contenido Markdown bruto. No se necesita archivo.
Todos los modos admiten parámetros opcionales: access, password, requireEmail, allowedDomains, allowedEmails, expiresAt y allowNetwork.
Formatos de archivo admitidos: PDF, HTML, Markdown, Imágenes (PNG/JPG/GIF/SVG/WebP), Vídeo (MP4).
"Get the content of my artifact abc123"La herramienta prismism_content obtiene el contenido bruto del artefacto. Los formatos de texto se devuelven como cadenas UTF-8, los formatos binarios se devuelven como base64. La clave API del propietario omite todas las puertas automáticamente. Para contenido protegido no propio, pasa los parámetros password o email.
"Make this artifact private"
"Set allowlist access with alice@acme.com"La herramienta prismism_update admite access (público/privado/lista de permitidos), allowedEmails, password, requireEmail y allowedDomains. Cambiar a privado/lista de permitidos borra silenciosamente las puertas de contraseña y correo electrónico.
Si aún no tienes una clave API, la herramienta prismism_register puede crear una cuenta:
"Register me on Prismism with my email"Devuelve la clave API una vez: el agente te ayudará a guardarla en tu configuración.
Variable | Requerido | Predeterminado | Descripción |
| Para la mayoría de herramientas | — | Tu clave API de Prismism |
| No |
| URL base de la API |
Todas las herramientas devuelven un sobre JSON consistente:
{
"ok": true,
"data": { ... },
"_hints": ["Actionable guidance for the agent"]
}En caso de error:
{
"ok": false,
"error": { "code": "STORAGE_LIMIT", "message": "..." },
"_hints": ["Upgrade at https://prismism.dev/settings/billing"]
}Endpoint alojado: Sin requisitos: funciona con cualquier cliente MCP
Local (stdio): Node.js 18+, npm o npx
MIT
Prismism — Enlaces compartibles para cualquier archivo
Get your account details — name, email, plan, and storage usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates the read-only nature ('Get') and the specific data returned, but omits information about rate limiting, caching behavior, or authentication requirements that would be necessary for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the action verb front-loaded. The em-dash concisely lists return fields without redundant phrasing. Every element earns its place in guiding tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and lack of output schema, the description adequately compensates by enumerating the expected return fields (name, email, plan, storage). For a read-only account introspection tool, this provides sufficient context for invocation, though explicit authentication context would improve it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4. The description appropriately does not invent parameters, maintaining consistency with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' with resource 'account details' and explicitly enumerates the returned fields (name, email, plan, storage usage). This clearly distinguishes it from sibling tools like 'prismism_get' (generic getter) and 'prismism_delete' by focusing specifically on account retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'prismism_get', nor does it mention prerequisites such as authentication requirements. The agent must infer usage solely from the resource specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete an artifact. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the destructive, irreversible nature of the operation ('Permanently delete', 'cannot be undone'). However, it omits other critical behaviors such as authorization requirements, what happens if the ID doesn't exist, or whether deletion cascades to related resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first establishes the action and scope; the second provides the critical safety warning. Every word earns its place and the irreversibility warning is appropriately emphasized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation without output schema, the description covers the essential safety warning. However, given the lack of annotations, it could improve by mentioning error conditions (e.g., 'fails if artifact does not exist') or permission requirements to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage ('Artifact ID to delete'), establishing a baseline of 3. The description does not add additional context about the ID format, validation rules, or how to obtain valid IDs, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Permanently delete') and resource ('artifact'), matching the tool name. However, it does not explicitly differentiate from siblings like 'prismism_update' or indicate when deletion is preferable to other lifecycle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The irreversibility warning ('This cannot be undone') provides an implied 'when-not' (don't use if recovery might be needed). However, it lacks explicit guidance on prerequisites (e.g., checking existence first) or when to use 'update' versus 'delete' versus 'unpublish'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details and analytics for a specific artifact by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable context by specifying that 'analytics' are included in the response, not just static details. However, it omits other behavioral traits like error handling for missing IDs, caching behavior, or whether the analytics are real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action ('Get') and immediately qualifies the scope ('details and analytics') and targeting mechanism ('by ID').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single string parameter, 100% schema coverage, no output schema), the description is adequately complete. It informs the agent of the tool's read-only retrieval purpose and the nature of the returned data without needing exhaustive elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage ('Artifact ID'), establishing a baseline of 3. The description reinforces this with 'by ID' but does not add significant semantic depth regarding the ID format or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Prismism Artifact'), and specifies the return type ('details and analytics'). It implicitly distinguishes from siblings like prismism_list (specific vs. collection) and prismism_delete/update (read vs. write operations), though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the prerequisite of having a specific artifact identifier, suggesting when to use this tool versus prismism_list. However, it lacks explicit guidance contrasting with siblings or stating error conditions (e.g., invalid ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that the Prismism MCP server is running and the API key is configured correctly. Call this first to confirm your setup works before doing anything else.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool checks API key configuration and server status, but omits return value format, error states, or idempotency characteristics that would help an agent interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose, the second states usage order. Every word earns its place and the description is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters, the description covers essential functionality. However, without an output schema, it could briefly mention what indicates success/failure (e.g., boolean or status string) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per guidelines establishes a baseline of 4. No parameter documentation is required or present in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Verify') and clearly identifies the scope (server running status and API key configuration). It distinguishes this diagnostic tool from operational siblings like prismism_publish or prismism_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing guidance ('Call this first') and clear context for when to use it ('before doing anything else'), effectively establishing it as a prerequisite check for the other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your published artifacts with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (starts at 1) | |
| limit | No | Items per page (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination behavior and user-scoping ('your'), but omits critical operational details such as read-only status, rate limits, sorting order, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient single sentence with zero waste. Front-loaded with the action ('List') and immediately qualifies the resource and mechanism. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema with full coverage, the description is minimally adequate. However, with no output schema and no annotations to declare safety properties, the description should ideally disclose more about return values or read-only status to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for 'page' and 'limit'. The description mentions 'pagination' which loosely maps to these parameters, but adds no specific semantic guidance beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'List' with clear resource 'published artifacts' and scope 'your'. Mention of 'pagination' implicitly distinguishes from sibling 'prismism_get' (single retrieval), though it doesn't explicitly state when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus siblings like 'prismism_get' or 'prismism_publish'. No mention of prerequisites or conditions that would trigger selection of this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file and get a shareable, tracked link. Supports PDF, HTML, Markdown, images (PNG/JPG/GIF/SVG/WebP), and video (MP4). Send content as plain text (default) or base64 for binary files.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | File content — plain text (default) or base64-encoded for binary files | |
| filename | Yes | Filename with extension, e.g. "report.pdf" or "chart.png" | |
| encoding | No | Content encoding — use "base64" for binary files like PDFs, images, or video | utf8 |
| contentType | No | MIME type — auto-detected from filename if not provided | |
| title | No | Display title for the artifact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that links are 'tracked' and 'shareable', indicating monitoring and accessibility traits. However, it omits critical operational details like file size limits, retention policies, idempotency behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence front-loads the action and supported formats; second sentence handles encoding guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately indicates the return value ('get a shareable... link'). With 100% parameter coverage in schema, the description appropriately focuses on format support and encoding. Minor gap: missing operational constraints like file size limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by listing supported file formats (PDF, HTML, Markdown, etc.) and explaining the binary vs text encoding decision logic, which aids parameter selection beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb ('Upload') + resource ('file') + outcome ('shareable, tracked link'). The action clearly distinguishes it from siblings like prismism_get, prismism_update, and prismism_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use base64 vs plain text encoding for binary files. However, it does not explicitly differentiate from prismism_update (for existing files) or mention prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Prismism account and get an API key. This is a one-time setup tool. The API key is returned once and cannot be retrieved again — save it to your MCP config immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your name | |
| Yes | Your email address — use a real email you can access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellently discloses irreversible behavior: 'API key is returned once and cannot be retrieved again'. Warns of data loss risk if not saved. Minor gap: doesn't specify behavior if email already registered or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: 1) Purpose, 2) Usage classification, 3) Critical warning. Front-loaded with action and resource. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates well for missing output schema by describing the return value (API key) and critical handling requirements. Given simple 2-parameter input with complete schema coverage, description adequately covers complexity. Minor gap on error conditions (duplicate email).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('Your name', 'Your email address — use a real email you can access'). Description adds no parameter-specific semantics, but with complete schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Create' + specific resource 'Prismism account' + outcome 'get an API key'. The 'one-time setup' framing distinguishes this initialization tool from sibling management tools like prismism_account, prismism_update, and prismism_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'one-time setup tool' establishing when to use it. Provides critical handling instruction to 'save it to your MCP config immediately'. Minor deduction for not explicitly naming what to use if account already exists (likely prismism_account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update settings for an existing artifact — title, download permissions, or password protection.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID | |
| title | No | New display title | |
| allowDownload | No | Allow viewers to download the file | |
| password | No | Set a password to protect the artifact (empty string to remove) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Identifies the operation as an update/mutation, but omits critical behavioral details: error handling for non-existent IDs, whether changes are immediate, authentication requirements, or the return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with efficient em-dash enumeration. Every clause earns its place: subject establishes operation, 'existing' establishes scope, and the list clarifies which settings are mutable. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a 4-parameter mutation tool with complete schema documentation. Covers the primary updatable fields but leaves gaps in behavioral context expected for a write operation, particularly given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. Description adds semantic grouping by categorizing the fields as 'settings' and maps 'allowDownload' to 'download permissions,' but doesn't elaborate on parameter interactions (e.g., that empty password string removes protection, which is only in the schema description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Update' + resource 'artifact' + explicit field list (title, download permissions, password protection). The phrase 'existing artifact' effectively distinguishes this from sibling tools like prismism_register (creation) and prismism_delete (removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies prerequisite by specifying 'existing artifact,' suggesting the ID must reference an already-created item. However, lacks explicit when-to-use guidance versus siblings like prismism_publish or prismism_register, and doesn't state that only the ID is required for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.2prismism_accountprismism_deleteprismism_getprismism_healthprismism_listprismism_publishprismism_registerprismism_updateScored across 8 tools
Each tool has a distinct purpose with no overlap: account management, artifact deletion, retrieval, health check, listing, publishing, registration, and updating. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tools follow a consistent 'prismism_verb' pattern (e.g., prismism_get, prismism_publish), using snake_case throughout. This predictability makes it easy for agents to understand and select tools.
With 8 tools, the set is well-scoped for artifact management, covering core operations like CRUD, listing, account setup, and health checks. Each tool serves a clear purpose without redundancy or bloat.
The toolset provides complete lifecycle coverage for artifact management: create (publish/register), read (get/list/account), update, and delete, plus health and setup tools. There are no obvious gaps, enabling smooth agent workflows.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
Publish Markdown or HTML to a shareable link from your AI assistant. OAuth, no API keys.
Get share links, publish and manage websites, artifacts and agents. No account needed.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
