@monnet/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MONNET_API_KEY | Yes | API key (mnk_*), sent as the X-API-Key header on every request | |
| MONNET_API_URL | No | Override for self-hosted or local dev backends (default: https://api.monnet.ai) | https://api.monnet.ai |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| monnet_whoamiA | Verify your Monnet MCP connection and list the API keys on your account. Useful for debugging setup issues. |
| list_workspacesA | List all Monnet workspaces you are a member of. Returns the workspace name and slug needed by other tools (get_motion, list_motions, create_motion, etc.). Call this first if you don't know the workspace slug. |
| get_workspace_memoryA | Read a Monnet workspace's MEMORY.md — a concise, auto-synthesized digest of the workspace's priorities, product decisions, recurring patterns, open threads, and team context, distilled from closed motions. Use it to ground yourself in what the team already cares about and has decided, without re-reading every motion. |
| get_motionA | Read a Monnet motion's full details — summary, body, status, priority, plan steps with assignees, member roles, and threaded comments (each comment shows a short id usable as parent_id in the comment tool to reply in its thread). Call this when the user references a specific motion by its short id or URL. |
| list_motionsA | List motions in a workspace, filterable by status. Returns short ids so you can follow up with get_motion on a specific one. Default status is 'open'. |
| get_inboxA | Fetch the user's 'For You' feed — motions across all their workspaces that need attention (pending approvals, unread activity, assigned steps). Use this when the user asks 'what's on my plate', 'what needs my attention', or similar. |
| create_motionA | Create a new draft motion in a Monnet workspace from a free-form prompt. Returns the new motion's id and URL immediately — a background Monnet run drafts the summary, body, and plan over the next few seconds. Call |
| update_motionA | Update a motion's summary, body, priority, or plan. All fields are optional — only include the ones you want to change. For plan updates, provide the full list of steps (use get_motion first to see the current plan, then modify and send it back). |
| commentA | Post a public comment on a motion, either top-level or as a reply within an existing comment thread (pass parent_id). The user is asked to approve the message before it is sent — nothing is posted without their explicit confirmation. Monnet may respond — if it does, the response is included in the return value. |
| approveA | Approve a plan step on a motion. Requires editor role on the motion. Use get_motion first to see the plan and identify the step_index (0-based). |
| rejectA | Reject a plan step on a motion, with an optional reason. Requires editor role on the motion. Use get_motion first to see the plan and identify the step_index (0-based). |
| ask_monnetA | Ask Monnet a question in the context of a specific motion. The question is sent as a private message (only you and Monnet see it). Monnet's response is returned directly. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct action or resource. get_motion vs list_motions, create vs update, comment vs ask_monnet, and approve vs reject are all clearly separated with no overlapping purposes.
Most tools follow a verb_noun pattern (list_workspaces, get_motion), but several use bare verbs (comment, approve, reject, ask_monnet) and one uses a monnet_ prefix (monnet_whoami), creating two distinct naming conventions.
12 tools is well within the ideal 3-15 range. Each tool serves a distinct purpose and the count feels appropriate for a workspace/motion management server.
Core lifecycle coverage is solid: create, read, list, update motions, plus commenting, approval/rejection, and inbox. Missing delete/archive for motions is a minor gap, but the surface is otherwise complete for typical workflows.