io.github.Developyn/laver-mcp
NPM · @LAVER/MCP · SCANNED AUG 18
Kanban boards, sprints, tickets and a team wiki, with versioned writes for concurrent agents.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 30 of 95 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 2 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability65
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 16889 tokens (~291/item across 58 items; 58 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management13
- Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
npm · @laver/mcp
claude mcp add developyn-laver-mcp -- npx -y @laver/mcp
codex mcp add developyn-laver-mcp -- npx -y @laver/mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"developyn-laver-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"@laver/mcp"
],
"enabled": true
}
}
} openclaw mcp add developyn-laver-mcp --command npx --arg -y --arg @laver/mcp
mcp_servers:
developyn-laver-mcp:
command: "npx"
args: ["-y", "@laver/mcp"] {
"mcpServers": {
"developyn-laver-mcp": {
"command": "npx",
"args": [
"-y",
"@laver/mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 17 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Aug 26 +2
- Schema quality: 8991 → 16889 ▼ functional
- Tool coverage: 71% → 100% ▲ functional
- Stability: unverified → 0.07 ▲ functional
- Package version: 0.3.1 → 0.4.0 functional
- 14 Aug 26 65
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 18 Aug 2026 · Analysed npm/@laver/mcp@0.4.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Dependencies 95 packages
| Packages resolved | 95 |
|---|---|
| Stale | 30 |
| Tree resolution | Complete |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
update_automation ~655
Edit a live automation rule: rename it, switch it off, change what triggers it, or replace its conditions or actions. `enabled: false` is the one to reach for first when a rule is misbehaving — it stops the rule immediately and reversibly, where deleting it also destroys its run history, so pause before you delete and read list_automation_runs while you still can. `conditions` and `actions` REPLACE the stored lists rather than merging into them, so send the complete array you want, built from what get_automation returned and not from memory. Requires a workspace OWNER or ADMIN and the current `version`; a stale version is a 409 carrying the current one, so re-read with get_automation and reapply rather than retrying blind. Send `version` plus at least one real change — a version on its own is a 400. `trigger_type` and `trigger_config` are two halves of one meaning: changing either alone is checked against the stored other half and refused if the pair would not make sense. Two things cannot be changed at all and are not parameters here: a rule's `task_uuid` and its `run_limit`, so a column.empty rule pointed at the wrong ticket has to be deleted and made again. Switching a rule back on clears the `disabled_reason` that a circuit breaker left, but does not give a retired run_limit rule any more runs.
| Name | Type | Req | Description |
|---|---|---|---|
| actions | array | – | The complete action list after the write, replacing the stored one. Never build it from a rule you read as a non-admin: a `call_webhook` url comes back as "[hidden]" there and would be written back l… |
| board_uuid | string | yes | The board's uuid, from list_boards |
| conditions | array | – | The complete condition list after the write — an empty array removes every condition and makes the rule fire on every occurrence of its trigger, which is usually not what someone narrowing a rule mea… |
| enabled | boolean | – | Whether the rule runs. False is the reversible way to stop a rule; it keeps the definition and the run history. |
| name | string | – | Renames the rule. |
| rule_uuid | string | yes | The rule's uuid, from list_automations |
| run_as_user_uuid | string | – | Who the rule acts as from now on. It is a standing grant of that person's permissions to anybody who can cause the trigger, and every future run is attributed to them, so repointing a rule is a bigge… |
| trigger_config | object | – | Replaces the trigger's configuration, in the same shape create_automation documents. Changing a schedule's interval or time recomputes when it next fires; enabling or disabling a rule deliberately do… |
| trigger_type | string | – | Changes what starts the rule. If the new trigger needs a trigger_config, send that too — the pair is validated together against whatever is stored. |
| version | integer | yes | The rule's version as get_automation last returned it. Required. A mismatch is a 409 whose body carries the current version. |
No output schema declared.
No examples provided.
update_comment ~259
Rewrite one of YOUR OWN comments. Only the author may edit a comment: somebody else's is a 404, exactly the same 404 as a comment that does not exist, so this never tells you who wrote what. It REPLACES the whole body rather than appending — read the comment back with get_ticket_comments and send it plus your addition if you meant to add a line. The edit is visible: the comment is marked as edited with the time, so this is not a way to make a change quietly. Comments are not versioned, so there is no `version` here and no 409 — the last edit wins, and two edits racing is simply the later one. An empty body is a 400 rather than a deletion; delete_comment is how you retract one.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | The comment's new text, Markdown, 1 to 10000 characters. It replaces everything the comment said. |
| comment_uuid | string | yes | The comment's uuid, from get_ticket_comments — or from the reply comment_on_ticket gave you, which is the cheap way to hold on to one you just wrote. |
| task_uuid | string | yes | The ticket's uuid, from list_tickets, get_board or search |
No output schema declared.
No examples provided.
update_custom_field ~299
Rename a custom field, change a select's options, change a currency field's code, or move it up the list. The `type` is deliberately not editable and is not a parameter here. `options` REPLACES the whole list rather than adding to it, and removing an option does not clear it from tickets that already hold that value — those keep a value the dropdown no longer offers, so read the tickets before you shorten a list. Send at least one field; all omitted is a 400. Requires a workspace OWNER or ADMIN, like defining one.
| Name | Type | Req | Description |
|---|---|---|---|
| board_uuid | string | yes | The board's uuid, from list_boards |
| currency | string | – | For a `currency` field, its ISO 4217 code. A field of any other type is a 404 saying so. |
| field_uuid | string | yes | The field's uuid, from list_custom_fields or get_board |
| name | string | – | Replaces the field's name. Omit to leave it as it is. |
| options | array | – | For a `select`, the complete list of choices after the write — it replaces rather than adds. A field of another type takes it without complaining and then ignores it, so sending it there does nothing. |
| position | number | – | Sort key among the board's fields — smaller sorts first. Read the neighbours' `position` off list_custom_fields and send a number between them. |
No output schema declared.
No examples provided.
update_label ~237
Rename or recolour a workspace label. It changes EVERYWHERE at once — every board, every ticket that carries it, for everybody in the workspace — because there is one label rather than a copy per board. That is the thing to be sure of before calling: a rename to something more specific may be wrong for whoever else is using it. The uuid does not change, so nothing holding one breaks. Renaming onto a name another label already has — ignoring case and surrounding space — is a 409. Send at least one of the two fields.
| Name | Type | Req | Description |
|---|---|---|---|
| color | string | – | Replaces the colour. Six-digit hex, '#334455'. |
| label_uuid | string | yes | The label's uuid, from list_labels or from a board's `labels` in get_board |
| name | string | – | Replaces the label's text. Omit to leave it as it is. |
| workspace_uuid | string | yes | The workspace's uuid, from list_workspaces. A key only ever reaches the one workspace it was issued for, so this is that one; another workspace's uuid is a 404 rather than a permission error. |
No output schema declared.
No examples provided.
update_status ~301
Rename a column, recolour it, or mark it as the one that means finished. `is_complete: true` is the interesting one: a board has at most ONE completed column, so setting it here silently clears the flag on whichever column held it, and the reply names what was unset. That flag is what `overdue` in list_workspace_tickets reads — a ticket sitting in a complete column is never overdue — so moving it changes what triage reports. Renaming is safe for tickets, which point at the uuid rather than the name, but it does break any saved text that named the old column. Send at least one of the three fields; all omitted is a 400 saying there is nothing to update.
| Name | Type | Req | Description |
|---|---|---|---|
| board_uuid | string | yes | The board's uuid, from list_boards |
| color | – | – | The column's colour as a six-digit hex string, '#334455'. Explicit null clears it and the column falls back to the default for its position; omitting it leaves the colour alone. Those are different. |
| is_complete | boolean | – | Whether tickets in this column count as finished. Only one column on a board may be the complete one, so true clears it elsewhere; false leaves the board with none. |
| name | string | – | Replaces the column's name. Omit to leave it as it is. |
| status_uuid | string | yes | The column's uuid, from get_board's `statuses` |
No output schema declared.
No examples provided.
update_subtask ~278
Tick a checklist item off, rename it, or move it up the list. `is_done: true` is the common one and is what makes the ticket's progress count move; `is_done: false` un-ticks an item that was ticked too early. Send at least one of the three — all three omitted is a 400. Renaming REPLACES the whole title rather than appending to it. An item on another ticket, or on a ticket you cannot open, is a 404 naming neither.
| Name | Type | Req | Description |
|---|---|---|---|
| is_done | boolean | – | true ticks it off, false un-ticks it. Omit to leave the tick alone rather than sending false, which is a change. |
| position | number | – | Sort key within the checklist, not an index — smaller sorts higher. Read the neighbours' `position` off the ticket's `subtasks` and send a number between them. Omit to leave the order alone. |
| subtask_uuid | string | yes | The item's uuid, from the ticket's `subtasks` in get_ticket — or from the reply add_subtask gave you. |
| task_uuid | string | yes | The ticket's uuid, from list_tickets, get_board or search |
| title | string | – | Replaces the item's text. Omit to leave it as it is. |
No output schema declared.
No examples provided.
update_ticket ~814
Change a ticket. `version` must be the one from get_ticket; a 409 means somebody wrote first and you should re-read. Markdown in `description` is parsed, and it replaces the whole description rather than appending to it. `label_uuids`, `assignee_uuids` and `custom_fields` each REPLACE the whole set rather than adding to it, so send what is already on the ticket alongside what you are adding or you will silently remove the rest. `custom_fields` is keyed by the field's uuid — read them off get_ticket, since a name will not do — and a uuid no field on that board has is DROPPED SILENTLY rather than refused: the call answers 200 and the value is simply not there. The task in the reply carries the stored `custom_fields`, so read them back to confirm a write landed rather than assuming a 200 means it did.
| Name | Type | Req | Description |
|---|---|---|---|
| assignee_uuids | array | – | The ticket's assignees, as the complete set after the write — it REPLACES rather than adds, so include whoever is already assigned. The uuids come from the board's `members`. An empty array unassigns… |
| custom_fields | object | – | Custom field values, keyed by the FIELD's uuid — read them off get_ticket, a field's name will not work. REPLACES the whole set, so send the values already on the ticket alongside the ones you are ch… |
| description | string | – | Replaces the whole body, Markdown, up to 20000 characters — it does not append. To add a line, read the current description with get_ticket and send it back with your addition included. |
| due_date | – | – | Due date as an ISO 8601 date, e.g. 2026-08-14. Explicit null clears it; omitting it leaves it unchanged. Those are different, so do not send null to mean 'no change'. |
| label_uuids | array | – | The ticket's labels, as the complete set after the write — it REPLACES rather than adds, so include the ones already on the ticket or you remove them. Bare uuids, which is the shape get_board returns… |
| position | number | – | Sort key within the column, not an index — smaller sorts higher. Read the neighbours' `position` off get_board and send a number between them; omit it to append to the bottom. Positions come back as… |
| priority | string | – | One of low, medium, high or urgent. Omit to leave it alone; there is no value here that clears a priority already set. |
| status | string | – | Move it to this column, by name as shown on the board. Send this or `status_uuid`, not both. move_ticket is the tool for a move alone. |
| status_uuid | string | – | Move it to this column, by uuid, from get_board. The exact form of `status`, unaffected by a column being renamed. |
| task_uuid | string | yes | The ticket's uuid, from list_tickets, get_board or search |
| title | string | – | Replaces the title. Omit to leave it as it is. |
| version | integer | yes | The `version` from the ticket as you last read it. Not a number you choose or increment: send back exactly what get_ticket gave you. If somebody else has written since, the call answers 409 rather th… |
No output schema declared.
No examples provided.
upload_ticket_attachment ~393
Attach a file to a ticket — the way an agent puts evidence on a ticket rather than describing it. Two ways to give it the bytes, and exactly one must be used. `file_path` reads a file from the machine THIS SERVER runs on (normally the agent's own machine, since the client starts this as a subprocess) and is the right one for anything that already exists on disk; it costs no context, so prefer it. `text` is for content the agent has just written — a log, a CSV, a diff — and needs `filename` alongside it. Laver refuses anything that is not one of application/pdf, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/vnd.openxmlformats-officedocument.wordprocessingml.document, image/gif, image/jpeg, image/png, image/webp, text/csv, text/plain, and refuses a file whose BYTES do not match the type its name claims, so renaming a zip to .png fails at the server rather than here. 25 MB is the ceiling. A workspace over its storage quota is a 402, which no retry fixes. Uploading is a write: a read-only role is a 403.
| Name | Type | Req | Description |
|---|---|---|---|
| content_type | string | – | Overrides the type guessed from the filename's extension |
| file_path | string | – | Path to an existing file on the machine running this server. Mutually exclusive with `text` |
| filename | string | – | The name to store it under. Required with `text`; defaults to the basename of `file_path`. Its extension decides the content type |
| task_uuid | string | yes | The ticket's uuid, from list_tickets, get_board or search |
| text | string | – | Literal file content, for something the agent wrote rather than something on disk. Requires `filename` |
No output schema declared.
No examples provided.