Artifacts for Gemini CLI
Gemini CLI lives in the terminal, which means its output lives in the terminal too, or in a file you then have to do something with. thing gives it a publish step: the model writes the page, calls one tool, and returns a URL you can send to a person who has never opened a terminal.
Already connected? Publish your first artifact
Connect thing to Gemini CLI
Gemini CLI reads ~/.gemini/settings.json. Add thing under mcpServers:
{
"mcpServers": {
"thing": {
"command": "npx",
"args": ["-y", "@unravel-tech/thing", "mcp"],
"env": { "THING_TOKEN": "$THING_TOKEN" }
}
}
}
Gemini CLI expands $VAR inside the env block, so the token can stay in your shell environment rather than in the settings file. Run /mcp in a session to confirm the server connected.
Publish your first artifact
Paste this into Gemini CLI. It creates a real artifact; no existing file is required.
The agent should return a thing URL. Open it while signed in and confirm the report is there. Check Share before sending it. Personal artifacts open for anyone with the link; to keep a report restricted, push it to a team, where artifacts default to team-only and you can invite people one by one.
For your next report, use the same name to add a version at the same URL.
Something not working?
Check npx --version, then run npx -y @unravel-tech/thing@latest whoami on the machine running your agent. If sign-in is missing, run npx -y @unravel-tech/thing@latest login there and restart the agent. For MCP, confirm thing’s tools appear before asking it to publish. Never put credentials in a prompt or a committed config.
Not using Gemini CLI for everything?
The same artifacts work from every other agent, and from CI. See artifacts for any coding agent for Claude Code, Aider, Cline, shell tools, and pipelines, and for why a page that outlives the session it came from is worth the extra step of publishing.