How do I install Artsonia?

Artsonia is a local plugin. Install it using npm package: artsonia-mcp and add the generated configuration snippet to your AI app's MCP config file. Then restart your AI app.

Is Artsonia safe to use?

Yes. Artsonia passed MCP Marketplace's automated security scan with a score of 8.3/10 (low risk). Every server on MCP Marketplace is security-scanned before it's listed; see the full security report on this page for the findings and permissions.

What credentials does Artsonia need?

Artsonia requires the following credentials or environment variables: ARTSONIA_USERNAME, ARTSONIA_PASSWORD, ARTSONIA_SESSION_CACHE, ARTSONIA_SESSION_FILE, ARTSONIA_OUTPUT_DIR, ARTSONIA_TRANSPORT, ARTSONIA_WS_PORT, ARTSONIA_INLINE_DOWNLOADS. You can find setup instructions on the server detail page.

What AI apps work with Artsonia?

Artsonia uses the Model Context Protocol (MCP) and works with any MCP-compatible AI app, including Claude, ChatGPT / Codex, Gemini, Copilot, Cursor, and more.

Back to Browse

Artsonia MCP Server

by Chris Hall

Developer ToolsLow Risk8.3Local

Free

Parent/fan access to Artsonia student-art portfolios, comments, and fans (AI-built).

About

Parent/fan access to Artsonia student-art portfolios, comments, and fans (AI-built).

Security Report

8.3

Low Risk8.3Low Risk

Valid MCP server (2 strong, 1 medium validity signals). 3 known CVEs in dependencies (0 critical, 2 high severity) Package registry verified. Imported from the Official MCP Registry. Trust signals: trusted author (79/80 approved); 5 highly-trusted packages.

10 files analyzed · 4 issues found

Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.

Permissions Required

This plugin requests these system permissions. Most are normal for its category.

HTTP Network Access

Connects to external APIs or services over the internet.

file_system

Check that this permission is expected for this type of plugin.

env_vars

Check that this permission is expected for this type of plugin.

What You'll Need

Set these up before or after installing:

Your Artsonia login email address. Required in the default direct mode; not needed when ARTSONIA_TRANSPORT=fetchproxy (the signed-in browser tab carries the session).Optional

Environment variable: ARTSONIA_USERNAME

Your Artsonia account password. Required in the default direct mode; not needed when ARTSONIA_TRANSPORT=fetchproxy.Required

Environment variable: ARTSONIA_PASSWORD

Set to false to disable the on-disk session cache and re-authenticate on every process start. Defaults to enabled.Optional

Environment variable: ARTSONIA_SESSION_CACHE

Absolute path for the session cache file. Defaults to $MCP_DATA_DIR/.artsonia-mcp/session-<user>.json.Optional

Environment variable: ARTSONIA_SESSION_FILE

Folders artsonia_download_artwork may save into (a path-delimiter list: ':' on macOS/Linux, ';' on Windows). Unset: ~/Downloads and ~/Pictures. Any other dest is refused. Not used on a hosted server, which never writes downloads to disk.Optional

Environment variable: ARTSONIA_OUTPUT_DIR

fetch (default) logs in directly with ARTSONIA_USERNAME/ARTSONIA_PASSWORD; fetchproxy is the optional fallback that rides your signed-in artsonia.com browser tab.Optional

Environment variable: ARTSONIA_TRANSPORT

fetchproxy WebSocket port override (default 37149, a shared fleet port). Only used when ARTSONIA_TRANSPORT=fetchproxy.Optional

Environment variable: ARTSONIA_WS_PORT

1/true/yes/on returns artsonia_download_artwork images inline as base64 image blocks instead of writing them to disk; unset/false saves to disk. Implied on a hosted server (MCP_DATA_DIR or MCP_BLOB_BASE_URL set).Optional

Environment variable: ARTSONIA_INLINE_DOWNLOADS

How to Install

Add this to your MCP configuration file:

{
  "mcpServers": {
    "io-github-chrischall-artsonia-mcp": {
      "env": {
        "ARTSONIA_WS_PORT": "your-artsonia-ws-port-here",
        "ARTSONIA_PASSWORD": "your-artsonia-password-here",
        "ARTSONIA_USERNAME": "your-artsonia-username-here",
        "ARTSONIA_TRANSPORT": "your-artsonia-transport-here",
        "ARTSONIA_OUTPUT_DIR": "your-artsonia-output-dir-here",
        "ARTSONIA_SESSION_FILE": "your-artsonia-session-file-here",
        "ARTSONIA_SESSION_CACHE": "your-artsonia-session-cache-here",
        "ARTSONIA_INLINE_DOWNLOADS": "your-artsonia-inline-downloads-here"
      },
      "args": [
        "-y",
        "artsonia-mcp"
      ],
      "command": "npx"
    }
  }
}

Documentation

View on GitHub

From the project's GitHub README.

artsonia-mcp

Artsonia MCP server for Claude — developed and maintained by AI (Claude Code)

Download folders

artsonia_download_artwork saves images only inside an allowed folder; any other dest is refused before anything is fetched or written, and no file is ever written through a symlink.

variable	default
`ARTSONIA_OUTPUT_DIR`	`~/Downloads` and `~/Pictures`	The folders `dest` must be inside (subfolders are fine and are created). Several folders: separate them with `:` (`;` on Windows). On a hosted server (`MCP_DATA_DIR` or `MCP_BLOB_BASE_URL` set), or with `ARTSONIA_INLINE_DOWNLOADS=1`, nothing is written to disk, so `dest` is only a label and is not checked: images come back inline up to 10 MiB per result, the rest as one signed zip link when the host has a blob store, and anything that still cannot be delivered is listed by name with the reason.

Upgrading

next release

artsonia_download_artwork no longer drops or strands an image. What changed in its result:

Hosted servers never write to disk. With MCP_DATA_DIR or MCP_BLOB_BASE_URL set, downloads now behave as if ARTSONIA_INLINE_DOWNLOADS=1 were set, whatever that variable says. Before, a hosted server without it saved into $MCP_DATA_DIR/downloads and reported files nobody could open. Because no file is written, a hosted result no longer carries dest, downloaded[].file, skipped[].file, index_file or metadata_count (write_index and write_metadata have nothing to write there); read delivered_via instead.
New archive (only when used): { url, expires_at, file_count, bytes, archive_bytes }. On a hosted server with a blob store, the images that do not fit inline (10 MiB per result) go into one zip behind that signed link. They count as downloaded.
downloaded[] entries gain delivered_via on the inline path: "inline", "archive" (plus archive_file, its path in the zip) or "link" (plus url and expires_at, for a single image too big to inline). Disk downloads are unchanged.
omitted[] entries were { artwork_id, bytes, is_private }. They are now { artwork_id, name, bytes, reason, title?, is_private }. name is the file name the image would have had, and reason says why it was not delivered. An image whose zip upload failed is moved here from downloaded.
failed[] entries gain title when the artwork's detail page was read.

Confirmations

The writes that reach other people — posting a comment and inviting a fan — ask you to confirm them first. Changing your notification settings, marking feedback read, and downloading artwork into your allowed download folders run straight away. A client that can show a confirmation prompt (Claude Code) shows one. A client that cannot (claude.ai, Claude Desktop) gets a two-step flow instead: the first call changes nothing and returns a preview of exactly what would be sent plus a confirmToken; only a second, identical call carrying that token goes ahead. The token is single-use, expires, and is refused if anything changed between the two calls.

variable	default
`MCP_CONFIRM_MODE`	`ask-user`	What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). `ask-user`: two steps — the first call does nothing and returns a preview plus a token, and the model must get your approval in chat before calling again with it. `auto`: the same two steps, but the model may use the token after reviewing the preview itself. `refuse`: writes are refused on such clients. A client that can show prompts (Claude Code) always gets the real prompt, unless `MCP_CONFIRM_ELICITATION=off`. An unrecognised value is treated as `refuse`.
`MCP_CONFIRM_ELICITATION`	`on`	`off` never shows a confirmation prompt, so every client gets the `MCP_CONFIRM_MODE` path. Set it for a client that claims to support prompts but never shows one (the write hangs — opencode 2.0.x). Any other value stays `on`, with a warning on stderr.
`MCP_CONFIRM_TTL_SECONDS`	`600`	How long a token stays valid.
`MCP_CONFIRM_SECRET`	random per process	Signing key; set it only if tokens must survive a server restart.