den / Guide / Agents

Connect an agent

One install brings the den connector and the skill that tells an agent how to use it. Claude Code takes a plugin; claude.ai and every other MCP client take the same URL as a connector; sign-in happens in the browser.

6 min read · On this page: One install, in Claude Code · One URL, everywhere else · Claude on your phone · How a session runs · The tools · REST

#One install, in Claude Code

den serves its own plugin catalog, so Claude Code takes the connector and the skill together:

claude plugin marketplace add https://den.pkslabs.com/.claude-plugin/marketplace.json
claude plugin install den@den-pkslabs-com

Then /mcp inside Claude Code opens the browser to sign in. The plugin carries the address, never the grant.

The skill is the difference between an agent that holds the tools and one that knows a session starts with whoami, that a write carries base_version, and that a grocery list belongs in a document that already exists. The plugin is how it arrives.

#What the plugin installs

The connector, at https://den.pkslabs.com/mcp, named den so an agent's tools read as they always have.
The den skill, the same text /skill.md serves.

#A kind's own plugin

A kind published with a plugin block is its own install, with the same server underneath and the kind's words on every tool:

claude plugin install den-household@den-pkslabs-com

Its connector is https://den.pkslabs.com/mcp/household and its skill is /skill/household.md. claude.ai takes the same connector URL, and the plugin catalog is mirrored to a git repository for clients that install from one. Kinds says how a kind becomes a product.

#If you connected den before the plugin existed

Nothing removes the older copies for you, so you would carry each of them twice — a second MCP server called den, and the skill loaded once from ~/.claude/skills and again from the plugin, because plugin skills are namespaced (/den:den) and coexist rather than override.

claude mcp remove den
rm -rf ~/.claude/skills/den    # only if `den skill --install` wrote it; leave a symlink to your own skill alone

#Updates, and removal

The archive's digest is its version. den declares no version number anywhere, so a change to the skill changes the digest and Claude Code's auto-update fetches it; there is no version to bump and no way to sit on a stale skill. To remove: claude plugin uninstall den@den-pkslabs-com.

Every den serves its own catalog, named after its own host: staging offers den-staging@den-staging-pkslabs-com, and a self-hosted den offers its own, pointing at its own /mcp. The names differ, so two of them can be installed at once.

#One URL, everywhere else

Plugins are Claude Code's. Every other client takes the same URL. den speaks MCP over HTTP at /mcp, with OAuth sign-in, and there is no token to copy.

Claude Code, tools without the skill claude mcp add --transport http den https://den.pkslabs.com/mcp

claude.ai and Claude Desktop Customize → Connectors → + → Add custom connector, and paste https://den.pkslabs.com/mcp.

Claude on a phone Claude on your phone has the steps.

Any other MCP client registers itself, opens the same sign-in, and gets the same tools.

On the consent page you pick the workspaces the connector may act in.

#Claude on your phone

A person whose Claude is the phone app gets the whole of den: the same tools, the same workspaces, the same versioned writes. Only the setup happens somewhere else, because the mobile apps read the connectors on your account but cannot add one.

On a computer, once. Sign in to claude.ai, open Customize → Connectors, press + next to Connectors, and give it a name (den) and the URL https://den.pkslabs.com/mcp. The advanced OAuth fields stay empty: den registers the client itself, and accepts Anthropic's hosted client metadata too.
Sign in to den and pick the workspaces. This is the step that decides what the phone can reach. A connector bound to your personal workspace is the usual reason den "has nothing" later; pick the shared workspace your team works in.
Open the Claude app, signed in to the same account. den is in the connector list; switch it on for the chat.
Ask for something by name. "Read the status of the den topic" is a whole session's start. Every answer carries a web_url; tapping it opens that artifact in den in the phone's browser, where the sidebar sits behind the menu button in the top bar.

The phone writes like a laptop does: write_artifact still names the version it read, append_entry still dates the entry, and the audit log records the connector it came from. Nothing about a write is weaker for having been dictated on a train.

What the phone cannot do is the laptop half of den: den login, the CLI, and the mount need a machine with a terminal and a filesystem. Read The CLI and the mount when you get back to one.

Revoke the connector under Tokens and devices; it is listed as a connector grant with the workspaces it may act in.

#How a session runs

den for software developers walks through it: whoami, get_topic, read_artifact on status, the work, append_entry on journal, and status rebuilt with base_version. den serves that procedure as a skill at /skill.md; the plugin installs it, and den skill --install writes it to ~/.claude/skills/den for anyone not using the plugin.

#The tools

Tool	What it does
`whoami`, `list_workspaces`	Who the session acts as, the role, and the workspaces it may switch to
`search`	Hybrid search over every artifact in the workspace, with filters and a confidence flag
`query`	One read-only SQL statement over every table, list and log in the workspace
`upcoming`	What is coming up: renewals, birthdays, appointments, computed from the documents
`find_place`, `change_document`, `change_rows`, `import_rows`	Where a thing belongs and the shape to write; a whole document; one row, item or event by id; rows from CSV
`list_topics`, `get_topic`, `create_topic`, `update_topic`	The catalog, one topic with its artifacts and instructions, new topics, edits to title, tags, instructions, skills
`read_artifact`, `write_artifact`, `list_versions`	A body at the head or a version; a new version with `base_version`; the history
`append_entry`	A dated entry at the top of a journal, gotchas, changelog, learnings or decision log, with an amount if it has one
`checkout_artifact`, `checkin_artifact`	Leases for long edits
`share_artifact`	A read-only link
`list_kinds`, `get_kind`, `create_kind`, `update_kind`, `set_kind_artifact`	The contracts, and changes to them for owners and admins
`list_marketplace`, `get_marketplace_kind`, `install_kind`, `publish_kind`	The marketplace: browse, install into a workspace, publish your own
`update_workspace`, `add_member`	A workspace's properties (currency, timezone); a member by email
`list_skills`, `get_skill`, `put_skill`	Skills as resources
`list_audit`	Who changed what, with versions, for owners and admins
`export_topic`	A portable folder with download links

Every result carries a web_url the agent can hand to a person. A tool that acts in a workspace takes an optional workspace to act in another one the token may reach; the marketplace tools are den-wide.

#REST

The same services answer plain HTTP with a bearer token from the Tokens and devices page:

curl -H "Authorization: Bearer $DEN_TOKEN" https://den.pkslabs.com/api/topics/<key>/artifacts/<name>?body=true

An API key is made for CI and headless agents, and it carries what it may do: the workspaces it acts in (the first is its default; X-Den-Workspace picks another from the set, and one outside it is refused), the role it acts as (at most your own in each of those workspaces, and never above your live membership role), its scopes, and an expiry. A key that should only read gets the viewer role or the read scope; a key that imports gets member. Revoke it on the same page.