# io.github.joshidikshant/loopback (npm · loopback-mcp-server)

Feedback bus for coding agents: pin feedback on the app you're building; a fix turns the pin green

- Trust score: 64/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `loopback-mcp-server`: 64/100 (this document), [markdown](https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server.md), [page](https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server)

## Channel facts

- Registry: `npm`
- Package: `loopback-mcp-server`
- Version: `0.9.4`
- Transport: `stdio`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (94 of 95), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (94 of 95), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 66/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2144 tokens (~214/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 7/100
  - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add joshidikshant-loopback -- npx -y loopback-mcp-server
```

### Codex

```bash
codex mcp add joshidikshant-loopback -- npx -y loopback-mcp-server
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "joshidikshant-loopback": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "loopback-mcp-server"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add joshidikshant-loopback --command npx --arg -y --arg loopback-mcp-server
```

### Hermes

```yaml
mcp_servers:
  joshidikshant-loopback:
    command: "npx"
    args: ["-y", "loopback-mcp-server"]
```

### Other

```json
{
  "mcpServers": {
    "joshidikshant-loopback": {
      "command": "npx",
      "args": [
        "-y",
        "loopback-mcp-server"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 64, −3)

No change was recorded against any check on this day. Supply Chain Security went from 98 to 87. Other categories moved too: Stability & Change Management rose 4.

### 2026-08-02 (score 67, +29)

- [security regression] Known CVEs: partial → unverified
- [security regression] Provenance: fail → unverified
- [security regression] Install scripts: pass → unverified
- [functional regression] License: pass → unverified
- [functional regression] Dependency health: partial → unverified
- [functional regression] Maintenance: pass → unverified
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Stability: unverified → 0.03
- [functional improvement] Tool coverage: unverified → 100
- [functional] First check of Schema quality: excellent
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: unverified
- [functional] First check of Tool coverage: 100
- [functional] First check of Tool coverage: 100
- [functional] Licence: MIT
- [functional] Package version: 0.9.1 → 0.9.4
- [functional] Package version: 0.9.1 → 0.9.3
- [functional] Package version: 0.9.1 → 0.9.2

### 2026-08-01 (score 38)

First indexed and scored.

## MCP tools (10)

### `loopback_submit_feedback` (~482 tokens)

Submit feedback

Create a new feedback item in the Loopback bus.

Use this to file any observation about a running product: a UI defect, a backend error, a usage insight, or a UX papercut. Every item is tagged to a project so the right agent picks it up later.

Args: project (slug), type (ui|backend|usage|ux), title, and optionally body, severity (p0-p3, default p2), source, reporter, route, url, dom_selector, screenshot_path, replay_url, console[], network[], repro_steps[].

Returns the created item as JSON, including its generated id (fb_...). New items start with status 'open'.

Example: file "Pay button dead on iOS Safari" with project='shop-web', type='ui', severity='p1', route='/checkout'.

Input parameters:

- `body` (string): Full description of the feedback/observation
- `console` (array): Recent console log lines relevant to the issue
- `dom_selector` (string): CSS selector of the affected element
- `extra` (object): Free-form context object: LLM run ids/model/trace URLs for AI features, automation run metadata, viewport, element HTML snippet, etc.
- `network` (array): Relevant network requests (url, method, status, ms)
- `project` (string, required): Project/repo slug this feedback belongs to, e.g. 'appbroda-web'
- `replay_url` (string): Session replay link (e.g. PostHog replay URL)
- `reporter` (string): Who reported it
- `repro_steps` (array): Steps to reproduce
- `route` (string): App route where observed, e.g. '/checkout'
- `screenshot_path` (string): Path or URL of a screenshot
- `severity` (string): p0=critical, p1=high, p2=normal, p3=nice-to-have
- `source` (string): Where this feedback came from
- `title` (string, required): Short summary, e.g. 'Checkout button dead on mobile Safari'
- `type` (string, required): Feedback dimension: 'ui' (visual/design), 'backend' (errors/API), 'usage' (analytics/behavior), 'ux' (flow/experience)
- `url` (string): Full URL where observed

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_list_feedback` (~303 tokens)

List feedback

List feedback items, filtered and paginated. This is the entry point for "work the queue".

Args (all optional): project, status (open|triaged|in_progress|fixed|verified|wontfix), type (ui|backend|usage|ux), severity (p0-p3), source, assignee_agent, limit (default 20), offset (default 0), response_format (markdown|json).

Returns items ordered most-severe first, then newest. Pagination metadata: total, count, offset, has_more, next_offset.

Typical agent flow: loopback_list_feedback(project='X', status='open') → loopback_claim_feedback → fix → loopback_link_change → loopback_update_status(status='fixed').

Input parameters:

- `assignee_agent` (string): Filter by claiming agent, e.g. 'claude-code'
- `limit` (integer): Maximum results to return
- `offset` (integer): Number of results to skip (pagination)
- `project` (string): Filter by project slug; omit for all projects
- `response_format` (string): 'markdown' for human-readable, 'json' for machine-readable
- `route` (string): Filter by app route where observed, e.g. '/checkout'
- `severity` (string): Filter by severity
- `source` (string): Filter by source
- `status` (string): Filter by status
- `type` (string): Filter by feedback type

Output parameters:

- `count` (integer): Items in this response
- `has_more` (boolean)
- `items` (array)
- `next_offset` (integer): Pass as offset for the next page
- `offset` (integer)
- `total` (integer): Total matching the filters

### `loopback_get_feedback` (~122 tokens)

Get feedback item

Fetch one feedback item with full context: description, repro steps, console lines, network entries, screenshot/replay links, linked change (commit/PR), and the complete comment trail.

Args: id (fb_...), response_format (markdown|json).

Read this before starting a fix — it contains everything captured at report time.

Input parameters:

- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `response_format` (string): 'markdown' for human-readable, 'json' for machine-readable

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_claim_feedback` (~186 tokens)

Claim feedback item

Atomically claim a feedback item for an agent before working on it. Prevents two agents from fixing the same thing.

Args: id, agent (your name, e.g. 'claude-code', 'codex', 'gemini'), force (default false).

On success the item's assignee_agent is set and status moves to 'in_progress' (from open/triaged). If another agent already holds the claim, this fails with a message naming the holder — pass force=true only if you intend to take over.

Input parameters:

- `agent` (string, required): Name of the claiming agent, e.g. 'claude-code', 'codex', 'gemini'
- `force` (boolean): Take over even if another agent already claimed the item
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_update_status` (~166 tokens)

Update feedback status

Move a feedback item through the workflow: open → triaged → in_progress → fixed → verified | wontfix.

Args: id, status, note (optional — recorded as a comment for the audit trail), author (default 'agent').

Use 'fixed' after making the change; use loopback_resolve_feedback for final verified/wontfix closure.

Input parameters:

- `author` (string): Who is making the change (for the audit trail)
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `note` (string): Optional note recorded as a comment alongside the change
- `status` (string, required): New status. Workflow: open → triaged → in_progress → fixed → verified | wontfix

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_add_comment` (~105 tokens)

Comment on feedback

Append a comment to a feedback item's discussion trail. Use for investigation notes, questions back to the reporter, or reasoning worth preserving.

Args: id, author, body (markdown ok).

Input parameters:

- `author` (string, required): Comment author, e.g. 'claude-code' or 'dj'
- `body` (string, required): Comment text (markdown ok)
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_link_change` (~176 tokens)

Link code change

Attach the fix to a feedback item so the loop is auditable: which repo/branch/commit/PR addressed it and a one-paragraph diff summary.

Args: id, plus any of repo, branch, commit, pr_url, diff_summary. Provided fields merge into existing links.

Call this right after committing the fix, before updating status to 'fixed'.

Input parameters:

- `branch` (string): Branch name of the fix
- `commit` (string): Commit SHA of the fix
- `diff_summary` (string): One-paragraph summary of what changed
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `pr_url` (string): Pull request URL
- `repo` (string): Repository, e.g. 'dj/appbroda-web'

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_resolve_feedback` (~227 tokens)

Resolve feedback

Close a feedback item with a final outcome.

Args: id, resolution ('verified' = the fix was confirmed against the running app, tests, or the relevant metric/replay; 'wontfix' = intentionally not addressing), note (optional closing comment), agent (YOUR name — this is the write that turns the reporter's pin full green, and omitting it records the generic default instead of you).

Prefer verifying before resolving: re-check the UI via your browser tools, or confirm the error/metric cleared, then call this.

Input parameters:

- `agent` (string): Who is resolving — your agent name. Recorded on the trail; defaults to 'agent'. This is the write that turns the reporter's pin green, so name yourself.
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `note` (string): Optional closing note recorded as a comment
- `resolution` (string, required): 'verified' = fix confirmed against the running app/metric; 'wontfix' = intentionally not addressing

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_update_feedback` (~298 tokens)

Edit feedback item

Correct an item after it was filed: title, body, severity, type, project, or route.

Feedback is filed fast and imprecisely on purpose — that is what makes people file it at all. Use this to re-rank a severity you now understand, fix a mis-guessed type, correct a typo, or move an item to the right project.

Args: id, plus any of title, body, severity (p0-p3), type (ui|backend|usage|ux), project, route. Also author (default 'human') — use your agent name so the trail says who re-triaged it.

Every change is recorded as a comment naming the old and new value; nothing is silently rewritten. Fields you omit are left alone.

This is for correcting the REPORT. To record progress use loopback_update_status, and to record the fix use loopback_link_change.

Input parameters:

- `author` (string): Who is making the edit — recorded on the audit trail
- `body` (string): Corrected description
- `id` (string, required): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `project` (string): Move to another project slug
- `route` (string): Corrected route
- `severity` (string): Re-ranked severity
- `title` (string): Corrected summary
- `type` (string): Corrected dimension

Output parameters:

- `assignee_agent` (string): Agent currently holding the claim
- `attachments` (array): Files attached to this item. `intent` decides what you do with each: 'reference' is context for the fix and never ships; 'asset' is a deliverable — copy it from `path` to `target_path` in the repo, c…
- `body` (string)
- `comments` (array): Full audit trail
- `console` (array): Console lines captured at report time
- `created_at` (string)
- `dom_selector` (string)
- `extra` (object): Free-form captured context. Read `extra.failed_responses` for failing requests with up to 2KB of response body, and `extra.context` for LLM/automation run metadata (run_id, model, trace_url).
- `id` (string): Feedback id, e.g. 'fb_mabc12_3f9a1c'
- `links` (object): Repo/branch/commit/PR of the fix
- `network` (array): Network calls captured at report time
- `project` (string)
- `replay_url` (string)
- `reporter` (string)
- `repro_steps` (array)
- `resolution` (string)
- `route` (string)
- `screenshot_path` (string)
- `severity` (string)
- `source` (string)
- `status` (string)
- `title` (string)
- `type` (string)
- `updated_at` (string)
- `url` (string)

### `loopback_get_stats` (~79 tokens)

Queue stats

Overview of the feedback queue: counts by project and status. Use to orient before picking work, or to report queue health.

Args: project (optional — omit for all projects).

Returns { total, projects: [{ project, by_status, total }] }.

Input parameters:

- `project` (string): Limit stats to one project; omit for all projects

Output parameters:

- `projects` (array)
- `total` (integer)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 67
- 2026-08-01: 38

## Links

- npm package: https://www.npmjs.com/package/loopback-mcp-server
- Socket report: https://socket.dev/npm/package/loopback-mcp-server
- Repository: https://github.com/joshidikshant/loopback
- Changelog RSS feed: https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server/changelog.json
- HTML version of this page: https://verifymcp.io/servers/joshidikshant-loopback/loopback-mcp-server