@flowboardlabs/mcp-server

MCP (Model Context Protocol) server for FlowBoard — lets AI tools like Claude Code, Cursor, and other MCP-compatible assistants manage your projects, tasks, ideas, and releases directly from your IDE.

Setup

1. Get an API Key

Go to Settings > Integrations > API Keys in your FlowBoard workspace. Click "Generate API Key" and copy it.

2. Configure Your AI Tool

Add the following to your MCP server configuration:

macOS / Linux:

{
  "mcpServers": {
    "flowboard": {
      "command": "npx",
      "args": ["-y", "@flowboardlabs/mcp-server"],
      "env": {
        "FLOWBOARD_API_KEY": "your-api-key-here",
        "FLOWBOARD_USER_EMAIL": "[email protected]"
      }
    }
  }
}

Windows (REQUIRED — npx needs cmd wrapper):

{
  "mcpServers": {
    "flowboard": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@flowboardlabs/mcp-server"],
      "env": {
        "FLOWBOARD_API_KEY": "your-api-key-here",
        "FLOWBOARD_USER_EMAIL": "[email protected]"
      }
    }
  }
}

Important: On Windows, you must use the cmd /c wrapper. Using npx directly as the command will fail silently.

Where to put this config

• Claude Code: .mcp.json in your project root
• Cursor: Cursor MCP settings
• Other tools: Check your tool's MCP configuration docs

Ideas are not workable tasks

The server sends this as MCP instructions on connect, so any client that surfaces them gets it without being told. It is repeated here because it is the one rule that silently destroys work when ignored.

Tasks on the Ideas Board are un-reviewed submissions. Before any call that starts, assigns, branches or completes a task, compare its projectId against ideasBoardId from get_workspace_schema. If they match: do not set status to in_progress, ready or done, do not set branchName, do not open an MR.

place_idea is the only way off the Ideas Board and it is one-way — rework_idea refuses a task that has already left, and update_task refuses moves back on. An idea worked in place therefore completes on the Ideas Board permanently, and QA queues and release drafts both read from the flow projects, so it ships untested or never ships at all.

The order is always accept_idea → place_idea → score_task, and only then may the task be picked up. Accepting is a product decision: ask before running it, never as a side effect of starting work.

Taking work: claim it, don't assign yourself

Use claim_next_task to pick up work. Don't search and then assign yourself — that's three calls with a gap in the middle, so two agents running at once choose the same task, both start, and one wastes its whole run. claim_next_task can't hand the same task to two callers.

An agent is never a task's assignee. It's the delegate: the agent does the work, a human keeps ownership, and that human is who gets notified and who answers for it if the run fails. Setting assignee to an agent: id is refused, with an error naming delegate instead. If you stop before finishing, hand the task back with delegate: null.

claimed: null means nothing is workable right now. That's a normal answer, not an error — don't retry in a tight loop.

Behaviour changes for existing integrators

Write attribution now records the agent, with the human as principal (2026-09). X-User-Email previously replaced the author: a write through an API key carrying the header was stored as though the person had made it, and the agent vanished from the record. The agent is now always the author, and the header adds the human alongside it — createdBy/updatedBy hold agent:<key name>, and createdOnBehalfOf/updatedOnBehalfOf hold the human. If you read createdBy expecting a user id for agent-made writes, read the onBehalfOf field instead. The header is still only trusted when that user is a member of the key's workspace.

Two changes to create_task (which calls the submitTask endpoint) that existing integrations should know about:

• priorityScore is no longer a fixed default. Previously, every task created via the API got priorityScore: 5 regardless of workspace configuration. It's now computed from the workspace's own priorityFormula (Settings > Workspace) — the same formula score_task uses and the UI shows. Workspaces still on the default formula (impact + clients + techEase) see no change; workspaces with a custom formula will see different scores on API-created tasks than before.
• Unknown customFields keys are now rejected. A customFields key that doesn't match a workspace-configured field (by id or by name) now returns a 400 naming the valid fields, instead of being written through silently as it was before. Call get_workspace_schema to see the valid keys for a workspace.

Environment Variables

| Variable | Required | Description | |----------|----------|-------------| | FLOWBOARD_API_KEY | Yes | Your FlowBoard API key | | FLOWBOARD_API_URL | No | Custom API URL (for self-hosted instances) | | FLOWBOARD_USER_EMAIL | No | Your email address in the workspace. Enables user-aware features: the mine filter in search, the human owner a claimed task is assigned to, and recording which person the agent acted for on every write | | FLOWBOARD_REVIEW_RUBRIC | No | Path to a local Markdown file with your own idea-review rubric, used by the flowboard://review-rubric resource and the review prompts instead of the shipped default. If the path can't be read, the server logs a warning to stderr and falls back to the default rubric rather than failing to start. |

Available Tools — 37 tools across 10 categories

Projects

| Tool | Description | |------|-------------| | list_projects | List all projects in the workspace. Returns id, name, description, color. Use project IDs when creating flow tasks (feature/improvement/fix/chore). | | create_project | Create a new project (a flow board). Params: name (1-100 chars, must be unique — a duplicate name is refused rather than silently allowed), description, color. Requires both View Projects and Update Tasks. | | update_project | Rename a project or change its description/colour. Params: projectId, name, description, color. This is the only way to rename a board through the API. Renaming onto a name another project already uses is refused. | | delete_project | Delete a project. Params: projectId. Refused while the project still holds any non-trashed task — move them first with update_task or bulk_update_tasks — and refused outright for the ideas and bugs boards, which submissions depend on. |

Tasks

| Tool | Description | |------|-------------| | search_tasks | Search and filter tasks. Params: board (flows/bugs/ideas), status (open/in_progress/in_review/blocked/ready/done/paused/rework/rejected, plus deleted with includeDeleted), statuses (comma-separated). With no status filter every live status comes back, rework included — a task sent back for rework is still on the board. Reworked ideas carry awaitingSubmitter: true and daysSinceActivity, projectId, assignee (email or ID), delegate (the agent holding the task — me for your own claimed work, any for everything the agents hold, none for work no agent has picked up, or an explicit agent:<key name>), type (idea/bug/feature/improvement/fix/chore), tags (comma-separated), limit (default 100, max 500), mine (boolean), q (free-text search across title and description — use to check whether an idea already exists), sortBy (priority (default) / votes / created). Hierarchy filters: parentTaskNumber lists one task's direct subtasks, topLevelOnly (boolean) drops subtasks from the results for a board-style overview. | | get_task | Get a single task by taskId or taskNumber, including all comments. Returns full task details: title, description, status, type, tags, assignee, time logs, QA status, dependencies, and comments thread. Also returns parent (the task this one is a piece of, or null) and children (its direct subtasks), alongside the raw parentId, subtaskCount and subtaskDoneCount fields. | | create_task | Create a new task. Params: title (3-200 chars), description (0-5000 chars), type (idea/bug/feature/improvement/fix/chore), projectId (required for feature/improvement/fix/chore — use list_projects to find IDs), tags (comma-separated, max 10), linkedTaskNumbers (comma-separated task numbers to link the new task to, e.g. "1474,1481" — links are bidirectional), impact (1-10, business impact), clients (1-10, demand), techEase (1-10, implementation ease), estimate (hours, or null to clear), customFields (object keyed by field id or name — call get_workspace_schema to discover valid keys). Ideas go to the ideas board, bugs to bugs board, flow types to the flows board under the specified project. priorityScore is computed from the workspace's own priorityFormula (Settings > Workspace), not a fixed default — a workspace on a custom formula will score API-created tasks differently than one on the default impact + clients + techEase. An unrecognized customFields key is rejected with a 400 that names the valid fields, rather than being written through silently. parentTaskNumber makes the new task a subtask of that task — a real parent/child relationship, not a "Part of #N" line in the description. Subtasks are one level only (the target must not itself be a subtask), the ideas board can hold neither side, and the child inherits its parent's projectId, impact and clients unless you pass your own. To create several at once use create_subtasks. | | update_task | Update a task by taskId or taskNumber. Does not set scores — impact, clients, techEase and customFields are not accepted here and passing them changes nothing; use score_task (one task) or bulk_update_tasks (a set), which also recompute priorityScore. estimate is accepted here, but only the scoring calls re-rank the task on it. Params: status (open/in_progress/blocked/ready/done/paused), type (feature/improvement/fix/chore/bug — what the task IS; a release groups its changelog by it, and everything submitted as an idea is stored as feature whatever it describes, so a submission that turns out to be a defect needs re-typing), comment (1-5000 chars — adds a comment), assignee (email or ID — humans only, an agent id is refused), delegate (agent:<key name>, or null to hand the task back — see Taking work), branchName (git branch, max 200 chars), externalReferenceType (github_pr/gitlab_mr), externalReferenceUrl, externalReferenceTitle, linkedTaskNumbers (comma-separated task numbers to link to — appends to existing links, bidirectional, deduplicated). Multiple fields can be set in one call. parentTaskNumber re-parents the task under that task number, or null un-parents it. Distinct from linkedTaskNumbers: a link means "related to", a parent means "part of", and parenting never creates a link. Setting status: "done" on a task with open subtasks is refused with a 409 naming them. removeLinkedTaskNumbers unlinks (comma-separated numbers) — linkedTaskNumbers only ever appends, so this is the only way to take a link back. Bidirectional, and clears the link reason as well as the link, so a blocked-by dependency removed here actually stops blocking claim_next_task. | | claim_next_task | Take the highest-scored task you can actually work on, atomically — use this instead of search_tasks + update_task when picking up work, because those are three calls with a gap in the middle and two agents will choose the same task. Params (all optional filters): projectId, type, tag. Sets you as the task's delegate and leaves a human as assignee; does not change the status. Skips anything already delegated, blocked by an unfinished dependency, still on the ideas board, or whose open subtasks are the real work. Returns claimed: null when nothing is workable — a normal answer, not an error. Looks at most 50 tasks deep and reports scanned and skipped so you can tell "backlog empty" from "nothing workable near the top". Requires Update Tasks. | | bulk_update_tasks | Apply the SAME change to many tasks at once — the practical way to triage a backlog instead of one call per task. Params: taskNumbers and/or taskIds (comma-separated, up to 50), plus status, assignee, delegate, comment, type (one classification across a batch of imported or mis-filed tasks is often exactly right, unlike a shared title), projectId, tags/addTags/removeTags, dueDate, estimate, the publishing fields (isPublic/publicTitle/publicDescription) and the scoring fields (impact, clients, techEase, customFields). Deliberately does NOT accept title or description, because setting one title on many tasks is always a mistake. Scoring is per task, not per batch: each task is re-scored against its own remaining fields through the workspace priorityFormula, so one shared impact still yields a different priorityScore per task, and each gets the same before/after audit comment score_task leaves. Re-ranking or re-estimating a reviewed batch is therefore one call rather than one score_task per item; the response carries priorityScore and scoreChanges per task, and a broken formula is reported once as a batch-level warning. Returns a per-task result — a task that can't be changed is reported as skipped with a reason while the rest go through, so check the results array rather than assuming everything applied. A status: "done" that would close a parent over its open subtasks is skipped with a reason, the same rule update_task applies one at a time. Also accepts removeLinkedTaskNumbers, to cut one stale link off a whole set in a single call. There is deliberately no bulk add-links counterpart. | | delete_task | Soft-delete (trash) a task by taskId or taskNumber. Task can be restored from trash in the UI. A task that has subtasks is refused with a 409 until you pass cascade: "orphan" keeps them as standalone tasks, "delete" trashes them too. The response reports which subtasks were affected. | | create_subtasks | Break one task into several subtasks in a single call — the right tool for splitting an epic, instead of one create_task round trip per piece. Params: parentTaskNumber or parentTaskId, titles (one title per line, 3-200 chars each, max 20 per call), type (feature/improvement/fix/chore, defaults to the parent's type), projectId (defaults to the parent's — a subtask may live in a different project than its parent), tags (comma-separated, applied to every subtask). Each subtask inherits the parent's impact and clients so the pieces sort next to it rather than at the bottom of the board; set techEase per subtask afterwards with score_task. Requires Submit Ideas. |

Ideas

| Tool | Description | |------|-------------| | list_ideas | Shortcut for search_tasks with board=ideas. Params: status (open / ready / rework / rejected — left out, all of them), limit. Ideas sent back for rework are included by default, flagged awaitingSubmitter: true with daysSinceActivity, because they are waiting on the person who submitted them and nothing else on the board surfaces them. | | vote_idea | Toggle a vote on an idea by taskId or taskNumber. Voting again removes the vote. Returns updated vote count. |

Idea Review

Requires the Review Ideas (canReviewIdeas) API key permission. Each tool guards that the target task is actually on the workspace's ideas board — calling one on a non-idea task returns a 400 telling you to use update_task instead.

| Tool | Description | |------|-------------| | accept_idea | Accept an idea: marks it ready and stamps when it was accepted. Does NOT move it into a flow — follow with place_idea to put it in a project, and score_task to set techEase. Params: taskId or taskNumber, reason (optional note recorded as an audit comment). | | reject_idea | Reject an idea. Params: taskId or taskNumber, reason (required, 1-5000 chars). Written as a comment visible to the submitter — it's permanent, so write it as feedback, not a verdict. | | rework_idea | Send an idea back for rework — also how you ask the submitter for more information. Params: taskId or taskNumber, reason (required, 1-5000 chars). Delivered to the submitter as a notification, so put the actual questions in it. The idea stays on the board at status rework and shows up in list_ideas flagged awaitingSubmitter, so it can be chased instead of quietly lost. | | place_idea | Move an accepted idea off the ideas board, reopening it as work. Params: taskId or taskNumber, projectId (required — use list_projects or get_workspace_schema), reason (optional audit note). The target is normally a flow project; the bugs board is also allowed, and placing there sets type: "bug" as well, which is the route for a submission that turned out to be a defect rather than a request. Only the ideas board itself is refused. |

Scoring

| Tool | Description | |------|-------------| | score_task | Set scoring fields on any task (idea, bug, or flow item) and recompute priorityScore using the workspace's formula. Params: taskId or taskNumber, impact (1-10), clients (1-10), techEase (1-10), estimate (hours, or null to clear), customFields (object keyed by field id or name). impact/clients reflect submitter-reported demand — ask before overwriting them; techEase is yours to judge. Every change is written as a before/after audit comment. If nothing actually changed, returns changes: [] and writes nothing. Requires Update Tasks (canUpdateTasks). | | get_workspace_schema | Get the workspace's priorityFormula, custom field definitions, project list, and the ideas/bugs board IDs. Call this before scoring in a workspace you haven't scored before — the formula determines which fields actually move priority. Requires View Projects (canViewProjects). |

Comments

| Tool | Description | |------|-------------| | get_comments | Get comments for a task by taskId or taskNumber. Params: limit (default 50, max 100). Returns comment text, author, timestamp, and type. | | add_comment | Add a comment to a task by taskId or taskNumber. Params: text (1-5000 chars). When FLOWBOARD_USER_EMAIL is set, the comment is attributed to your account. |

Releases

| Tool | Description | |------|-------------| | list_releases | List confirmed releases. Params: limit (default 25, max 100). Returns name, version, status, task count, dates. | | get_release | Get a single release by releaseId with all associated tasks (id, title, status, type, taskNumber). | | get_release_draft | Get the current release draft state. Returns two lists: releaseItems (tasks staged for the next release) and hotfixItems (bugs staged for a hotfix), each with full task details, plus the draft version and deployNotes. Requires canManageReleases API key permission. | | add_to_release_draft | Add task(s) to the release or hotfix draft. Params: taskIds (comma-separated) and/or taskNumbers (comma-separated), list ("release" or "hotfix", default "release"). Tasks are mutually exclusive between lists — adding to one removes from the other. Requires canManageReleases. | | remove_from_release_draft | Remove task(s) from the release or hotfix draft. Params: taskIds and/or taskNumbers, list. Requires canManageReleases. | | set_release_version | Set the version string for the release draft. Params: version (e.g. "1.2.0"). Requires canManageReleases. | | confirm_release | Confirm and publish a release from the current draft. Creates the release, archives all included tasks (sets releaseId and archived: true), and clears the draft. Params: version (overrides draft version), name (defaults to "Release {version}"), isPublic (boolean), environments (comma-separated, e.g. "Staging,Production"), list ("release" or "hotfix"). Requires canManageReleases. | | add_tasks_to_release | Add task(s) to an EXISTING (already-published) release — e.g. fixes cherry-picked onto an already-cut release branch. Applies the same effects as confirming (releaseId + archived: true). Idempotent: tasks already in the release are skipped and reported. Params: releaseId (primary key) or version (fails if it matches more than one release), plus taskIds and/or taskNumbers (comma-separated). Requires canManageReleases. | | remove_tasks_from_release | Remove task(s) from an existing release. Clears releaseId, unarchives the tasks so they reappear on their board. Tasks not in the release are skipped and reported. Same params as add_tasks_to_release. Requires canManageReleases. |

Workspace

| Tool | Description | |------|-------------| | get_workspace | The workspace's own identity and settings: name, product name, logo, whether a public roadmap is live and at which URL, and which projects act as the default flow, ideas board and bugs board. get_workspace_schema covers scoring and project ids; this covers everything else. | | update_workspace | Change workspace identity and settings, including publishing a public roadmap. Two things to know: a public roadmap needs BOTH publicRoadmapEnabled: true AND a publicRoadmapSlug — either alone is a dead end, and the response tells you which half is missing. Roadmap slugs are a GLOBAL namespace across all workspaces, so a clash is refused; pick something specific. Only tasks explicitly marked isPublic appear on it. |

Members

| Tool | Description | |------|-------------| | list_members | List the people in the workspace with their user IDs, emails, display names and roles. Call this before assigning work — assignee expects a real email or user ID, and guessing one silently assigns to nobody. |

Weekly commitments

| Tool | Description | |------|-------------| | list_commitments | The commitments wall for one week (week, ISO key like 2026-W40, defaults to this week): members with ids and emails, every commitment with its id, owner, confidence status and blocker reason, check-in and close-out state (answeredLate when the answer came after the Friday summary), renegotiations with reasons; plus phase (declare / check_in / close_out), progress, and the stored summary and flags once the Friday summary ran. Requires View Projects. | | declare_commitment | Declare one outcome for the week: outcome (10-300 chars, verifiable, never a task list), criterion (what they will see on Friday), optional ownerEmail or ownerId to declare for someone who reports to you (Settings > Team > Reports To) or, as the workspace owner, for anyone; a workspace admin who manages nobody may declare for nobody. Optional week for a later week. The week is the deadline. No cap per person. Requires Update Tasks and FLOWBOARD_USER_EMAIL. | | update_commitment | One change by commitmentId: action = check_in (status on_track / at_risk / blocked, reason unless on_track), close_out (result met / not_met — also takes a commitment the Friday summary recorded as unanswered, while its week is the current one or the one just gone, answering it with answeredLate: true; older weeks are refused), edit (new outcome and/or criterion and/or ownerEmail/ownerId, no reason — only while nobody has answered it, and moving it needs authority over both people), renegotiate (new outcome and/or criterion, reason required), withdraw (reason), carry_over (a not-met commitment into next week, once). The owner may do all of them; the manager they report to may renegotiate, withdraw and carry_over but never answer a check_in or close_out. Requires Update Tasks and FLOWBOARD_USER_EMAIL. |

Task identification

All task-related tools accept either a taskId (Firestore document ID) or a taskNumber (the human-readable integer, e.g. 42). Task numbers are easier to work with — agents can extract them from git branch names like feature/42-fix-login.

User identity

When FLOWBOARD_USER_EMAIL is set, the MCP server sends an X-User-Email header with every request. This enables:

• mine filter — search_tasks with mine: true returns only tasks assigned to you. Without FLOWBOARD_USER_EMAIL it returns what the key's own agent is holding as delegate instead, since an agent is never an assignee. Use delegate: "me" when you want your claimed work either way
• Comment attribution — comments added via add_comment or update_task record the agent as the author and you as the principal it acted for (createdBy: agent:<key name>, createdOnBehalfOf: <your uid>), rather than the generic "api" author

API Key Permissions

Each tool requires specific API key permissions. Enable them when generating a key in Settings > Integrations:

| Permission | Tools it unlocks | |------------|-----------------| | Submit Ideas | create_task (type: idea), create_subtasks | | Submit Bugs | create_task (type: bug) | | Search Tasks | search_tasks, get_task, list_ideas, list_releases, get_release, get_comments | | Update Tasks | update_task (including its comment field), delete_task, vote_idea, score_task, declare_commitment, update_commitment | | View Projects | list_projects, get_workspace_schema, list_commitments | | Manage Comments | add_comment only — the comment field on update_task is gated by Update Tasks, not this permission | | Manage Releases | get_release_draft, add_to_release_draft, remove_from_release_draft, set_release_version, confirm_release, add_tasks_to_release, remove_tasks_from_release | | Review Ideas | accept_idea, reject_idea, rework_idea, place_idea |

Review Ideas (canReviewIdeas) defaults to off — existing API keys do not gain it automatically. Enable it explicitly on a key (Settings > Integrations > API Keys > Generate API Key) to use the idea-review tools.

For a full-featured MCP agent, enable all permissions. For read-only, enable only Search Tasks and View Projects.

Prompts

MCP prompts you can invoke directly (check your MCP client's docs for its prompt-invocation syntax — e.g. Claude Code exposes MCP prompts as slash commands) to drive a structured review, rather than free-form chat.

| Prompt | Description | |--------|-------------| | review_idea_backlog | Walks the open ideas queue (sorted by votes) one idea at a time: pulls the workspace schema, checks each idea for duplicates with search_tasks, recommends accept/reject/rework with reasoning against the rubric, then stops and waits for you to confirm before calling any write tool. | | triage_idea | Same review process for a single idea. Param: taskNumber (the idea's task number, e.g. 1482). |

Both prompts judge against the rubric returned by the flowboard://review-rubric resource (see below) and never write to more than one idea without your confirmation.

Resources

| Resource | Description | |----------|-------------| | flowboard://projects | List of all projects in the workspace. | | flowboard://tasks/{taskId} | A single task with its comments. | | flowboard://review-rubric | The rubric used when reviewing ideas — the shipped default, or your own file if FLOWBOARD_REVIEW_RUBRIC is set. |

Reviewing ideas

End-to-end flow for using an AI assistant as a first-pass reviewer on your ideas backlog:

1. Mint a key with Review Ideas enabled. Settings > Integrations > API Keys > Generate API Key, check Review Ideas (and Update Tasks + View Projects, since the review flow also scores and places ideas). Existing keys don't gain this permission automatically — it's opt-in per key.
2. (Optional) Point FLOWBOARD_REVIEW_RUBRIC at your own rubric. Write a Markdown file describing how your team judges ideas (what counts as high impact, what's out of scope, etc.) and set the env var to its path alongside FLOWBOARD_API_KEY in your MCP config. Skip this to use the shipped default rubric.
3. Run the review_idea_backlog prompt. The assistant fetches your workspace schema, pulls open ideas sorted by votes, and works through them one at a time — checking for duplicates, proposing accept/reject/rework with a techEase estimate, and stopping to wait for your confirmation before writing anything.
4. Confirm each recommendation. On your go-ahead, the assistant calls accept_idea + place_idea + score_task (to move it into a project and score it), or reject_idea / rework_idea (to close it out or send it back with your questions attached).

For a single idea instead of the whole backlog, use triage_idea with a task number.

Example Prompts

Once configured, just ask naturally:

• "Show me my in-progress tasks"
• "Show me all open bugs in the backend project"
• "Create a bug: login page returns 500 when email contains a plus sign"
• "Move task 42 to in_progress and assign it to me"
• "What are the latest releases?"
• "Add a comment to task 15: Fixed in PR #42"
• "Add tasks 10, 12, and 15 to the release draft"
• "Set the release version to 2.1.0 and confirm the release"
• "Show me what's in the release draft right now"
• "Add bug 88 to the hotfix draft and confirm the hotfix"

Requirements

• Node.js >= 18
• A FlowBoard workspace with an API key

Deploying and publishing (maintainers)

When a release adds or changes Cloud Functions endpoints that this package calls, deploy the functions before publishing the package — not after, and not at the same time. This package talks to those endpoints on its very first tool call; a published version that expects an endpoint the deployed backend doesn't have yet fails immediately for every user who upgrades.

# 1. Verify first — from the repo root
cd functions && npm test
cd .. && npx nx test data-access --testPathPattern=priority-formula
npx nx build flowboard

# 2. Deploy the functions this release touches, from the repo root
firebase deploy --only functions:reviewIdea,functions:scoreTask,functions:getWorkspaceSchema,functions:getTasks,functions:submitTask,functions:createApiKey

# 3. Smoke-test each new/changed endpoint against production with a real API key
#    before moving on — a bad deploy caught here is a lot cheaper than one caught
#    after publish.

# 4. Only then, publish the package
cd packages/mcp-server
npm run build
npm publish --access public

If a deploy needs to be rolled back, roll back the functions; do not try to unpublish a package version to fix it — npm publishes are effectively permanent (unpublish is restricted and doesn't retract a version already installed elsewhere).

License

MIT