Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.

io.github.joshidikshant/loopback

NPM · LOOPBACK-MCP-SERVER · SCANNED AUG 3

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

Available components

64 Trust /100
Trust breakdown (6 categories)

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 Security87
  • No malware found by supply-chain analysis.Pass
  • Only part of the dependency tree could be resolved (94 of 95), so this covers what we could see, not the whole tree.Partial
  • No install/post-install scripts declared.Pass
  • Only part of the dependency tree could be resolved (94 of 95), so this covers what we could see, not the whole tree. View diagnostics → Partial
Provenance & Transparency45
Schema Quality & AI Usability66
  • AI-judged instruction clarity (excellent).Pass
  • 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. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management7
  • Stability observed for 2 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
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

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 · loopback-mcp-server

# add to Claude Code
claude mcp add joshidikshant-loopback -- npx -y loopback-mcp-server
# add to Codex CLI
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
    }
  }
}
# add to OpenClaw
openclaw mcp add joshidikshant-loopback --command npx --arg -y --arg loopback-mcp-server
# ~/.hermes/config.yaml
mcp_servers:
  joshidikshant-loopback:
    command: "npx"
    args: ["-y", "loopback-mcp-server"]
// mcp.json
{
  "mcpServers": {
    "joshidikshant-loopback": {
      "command": "npx",
      "args": [
        "-y",
        "loopback-mcp-server"
      ]
    }
  }
}
Changelog

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.

  • 3 Aug 26 −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.

  • 2 Aug 26 +29
    • Known CVEs: partial → unverified security
    • Provenance: fail → unverified security
    • Install scripts: pass → unverified security
    • License: pass → unverified functional
    • Dependency health: partial → unverified functional
    • Maintenance: pass → unverified functional
    • MCP protocol: unverified → pass functional
    • Stability: unverified → 0.03 functional
    • 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 functional
  • 1 Aug 26 38

    First indexed and scored.

Diagnostics

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 3 Aug 2026 · Analysed npm/[email protected]

Provenance none

Ecosystem: npm · Outcome: none

Dependencies 94 packages

94 packages in the resolved dependency tree · 94 deprecated · 29 stale.

The dependency tree was only partially resolved, so these counts may be incomplete.

MCP tools — 10 exposed · ~2,144 tokens

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.

Tool Tokens
loopback_add_comment ~105

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).

NameTypeReqDescription
authorstringyesComment author, e.g. 'claude-code' or 'dj'
bodystringyesComment text (markdown ok)
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_claim_feedback ~186

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.

NameTypeReqDescription
agentstringyesName of the claiming agent, e.g. 'claude-code', 'codex', 'gemini'
forcebooleanTake over even if another agent already claimed the item
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_get_feedback ~122

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.

NameTypeReqDescription
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
response_formatstring'markdown' for human-readable, 'json' for machine-readable
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_get_stats ~79

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 }] }.

NameTypeReqDescription
projectstringLimit stats to one project; omit for all projects
NameTypeReqDescription
projectsarrayyes
totalintegeryes

No examples provided.

loopback_link_change ~176

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'.

NameTypeReqDescription
branchstringBranch name of the fix
commitstringCommit SHA of the fix
diff_summarystringOne-paragraph summary of what changed
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
pr_urlstringPull request URL
repostringRepository, e.g. 'dj/appbroda-web'
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_list_feedback ~303

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').

NameTypeReqDescription
assignee_agentstringFilter by claiming agent, e.g. 'claude-code'
limitintegerMaximum results to return
offsetintegerNumber of results to skip (pagination)
projectstringFilter by project slug; omit for all projects
response_formatstring'markdown' for human-readable, 'json' for machine-readable
routestringFilter by app route where observed, e.g. '/checkout'
severitystringFilter by severity
sourcestringFilter by source
statusstringFilter by status
typestringFilter by feedback type
NameTypeReqDescription
countintegeryesItems in this response
has_morebooleanyes
itemsarrayyes
next_offsetintegerPass as offset for the next page
offsetintegeryes
totalintegeryesTotal matching the filters

No examples provided.

loopback_resolve_feedback ~227

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.

NameTypeReqDescription
agentstringWho 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.
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
notestringOptional closing note recorded as a comment
resolutionstringyes'verified' = fix confirmed against the running app/metric; 'wontfix' = intentionally not addressing
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_submit_feedback ~482

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'.

NameTypeReqDescription
bodystringFull description of the feedback/observation
consolearrayRecent console log lines relevant to the issue
dom_selectorstringCSS selector of the affected element
extraobjectFree-form context object: LLM run ids/model/trace URLs for AI features, automation run metadata, viewport, element HTML snippet, etc.
networkarrayRelevant network requests (url, method, status, ms)
projectstringyesProject/repo slug this feedback belongs to, e.g. 'appbroda-web'
replay_urlstringSession replay link (e.g. PostHog replay URL)
reporterstringWho reported it
repro_stepsarraySteps to reproduce
routestringApp route where observed, e.g. '/checkout'
screenshot_pathstringPath or URL of a screenshot
severitystringp0=critical, p1=high, p2=normal, p3=nice-to-have
sourcestringWhere this feedback came from
titlestringyesShort summary, e.g. 'Checkout button dead on mobile Safari'
typestringyesFeedback dimension: 'ui' (visual/design), 'backend' (errors/API), 'usage' (analytics/behavior), 'ux' (flow/experience)
urlstringFull URL where observed
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_update_feedback ~298

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.

NameTypeReqDescription
authorstringWho is making the edit — recorded on the audit trail
bodystringCorrected description
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
projectstringMove to another project slug
routestringCorrected route
severitystringRe-ranked severity
titlestringCorrected summary
typestringCorrected dimension
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.

loopback_update_status ~166

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.

NameTypeReqDescription
authorstringWho is making the change (for the audit trail)
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
notestringOptional note recorded as a comment alongside the change
statusstringyesNew status. Workflow: open → triaged → in_progress → fixed → verified | wontfix
NameTypeReqDescription
assignee_agentstringAgent currently holding the claim
attachmentsarrayFiles 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…
bodystringyes
commentsarrayFull audit trail
consolearrayyesConsole lines captured at report time
created_atstringyes
dom_selectorstring
extraobjectyesFree-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).
idstringyesFeedback id, e.g. 'fb_mabc12_3f9a1c'
linksobjectyesRepo/branch/commit/PR of the fix
networkarrayyesNetwork calls captured at report time
projectstringyes
replay_urlstring
reporterstringyes
repro_stepsarrayyes
resolutionstring
routestring
screenshot_pathstring
severitystringyes
sourcestringyes
statusstringyes
titlestringyes
typestringyes
updated_atstringyes
urlstring

No examples provided.