Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent for Artsonia access, but it handles children's portfolio data and account actions with some write/download paths that can run without clear human confirmation.
Review this carefully before installing. Use it only with an Artsonia account you intend to expose to an MCP server, keep confirmation mode at ask-user or refuse, avoid auto mode, and be deliberate before downloading private artwork or writing metadata sidecars that may contain comments or teacher feedback.
Skill accesses MCP server configuration files (mcp.json). MCP configs contain server URLs, authentication tokens, and tool definitions — reading them allows the skill to discover and potentially abuse other tool integrations.
Add to .mcp.json in your project or ~/.claude/mcp.json:
{
The trigger text is overly broad because it claims the skill should activate for essentially any request involving student art portfolios on Artsonia. In a multi-skill environment, that can cause over-selection of this skill and unnecessary access to student artwork, comments, fan lists, or account-linked data even when the user’s request was ambiguous or could have been satisfied without this integration.
artsonia_download_artwork is documented to run in one call with no confirmation, yet it performs non-read-only actions by writing files, optional manifests, and optional metadata to local storage. Even if constrained to allowed directories, autonomous execution can cause unexpected local persistence of student-related images and associated metadata without a deliberate user checkpoint.
| `artsonia_get_activity` | Get recent activity feed for a student |
| `artsonia_get_portfolio` | Get a student's art portfolio. Optional `include_details: boolean` (default `false`) fetches each artwork's full detail (title/project/grade/views/…) concurrently and merges it into the rows; omit it for the fast, lean tiles. |
| `artsonia_get_artwork` | Get details for a single artwork |
| `artsonia_download_artwork` | Download a student's artwork images to a local folder. `dest` must be inside `ARTSONIA_OUTPUT_DIR` when set, else `~/Downloads` or `~/Pictures` (`$MCP_DATA_DIR/downloads` when hosted); any other folder is refused before anything is fetched. Optional `path_template: string` (e.g. `"{grade}/{project}"` or `"{school_year}"`) organizes downloads into subfolders under `dest`, composed with `filename_template` — same tokens (`{title}` `{project}` `{grade}` `{date}` `{school_year}` `{artwork_id}`), segments slugified like filenames, empty tokens collapse, and paths stay deterministic so `skip_existing` re-runs remain idempotent. Optional `embed_metadata: boolean` (default `false`) embeds each image's title/project/grade and source date (its `Last-Modified`) into the JPEG's EXIF (ImageDescription, DateTimeOriginal) and IPTC (title, keywords, date) so the metadata survives renames/moves and is searchable in Spotlight/Apple Photos; the count is returned as `embedded_count` (best-effort — a failed embed writes the original bytes). Optional `write_index: boolean` (default `false`) writes an `index.json` manifest into the destination listing the downloaded items (`artwork_id`, `title`, `file` — dest-relative, `grade`, `project`, `date`); the manifest path is returned as `index_file`. Optional `write_metadata: boolean` (default `false`) writes a per-artwork `<image-name>.json` sidecar next to each image with the artwork's comments and teacher feedback (plus title/project/grade); the count is returned as `metadata_count`. Optional `include_private: boolean` (default `t
...[truncated 25 chars]
The skill documents a download feature that writes files locally and can also create index manifests, metadata sidecars, and embedded image metadata, but this behavior is not surfaced as a prominent warning. Because the content involves children's artwork and related comments/teacher feedback, silent or poorly signposted local persistence can create privacy and data-handling risks for the user.
The confirmation design explicitly allows some state-changing operations to bypass user approval depending on configuration, and documents auto fallback behavior for clients that cannot prompt. In context, this is more sensitive because the skill manages student-related portfolios, comments, fans, and notifications through a real account, so autonomous actions can affect privacy, social interactions, and account state.
### Confirming writes
`artsonia_post_comment` and `artsonia_invite_fan` ask the user to confirm first. (`artsonia_set_notifications`, `artsonia_mark_feedback_read` and `artsonia_download_artwork` run in one call with no confirmation step.) Where the client can show a confirmation prompt, it does (unless the server sets `MCP_CONFIRM_ELICITATION=off`). Otherwise the first call changes nothing and returns `status: "confirmation-required"` with a `preview` of exactly what would be sent and a `confirmToken`: show the preview to the user, and only after they approve in chat call the tool again with the **same arguments** plus `confirmToken`. A token works once (`TOKEN_REUSED`), expires, and is refused as `DRAFT_CHANGED` (with a fresh preview and token) if the arguments or the data it acts on changed in between. `MCP_CONFIRM_MODE` (`ask-user` default / `auto` / `refuse`) controls this fallback.
## Environment Variables
Allowing MCP_CONFIRM_MODE=auto permits write actions to proceed without explicit user approval in chat, weakening the confirmation boundary for actions that affect an external account. In this skill, that could enable autonomous posting, invitations, or notification changes involving a parent/fan account tied to student-related data.
No suspicious patterns detected.