io.github.joshidikshant/loopback
NPM · LOOPBACK-MCP-SERVER · SCANNED SEP 22
Feedback bus for coding agents: pin feedback on the app you're building; a fix turns the pin green
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 → Why this is hard to 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
- 31 of 95 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
- 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 50 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability71
- 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 Management100
- No destabilizing schema changes in the last 30 days.Pass
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
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.github.joshidikshant/loopback MCP server?
io.github.joshidikshant/loopback runs locally as an npm package, launched with npx -y loopback-mcp-server. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · loopback-mcp-server
claude mcp add joshidikshant-loopback -- npx -y loopback-mcp-server
{
"mcpServers": {
"joshidikshant-loopback": {
"command": "npx",
"args": [
"-y",
"loopback-mcp-server"
]
}
}
} {
"servers": {
"joshidikshant-loopback": {
"command": "npx",
"args": [
"-y",
"loopback-mcp-server"
]
}
}
} codex mcp add joshidikshant-loopback -- npx -y loopback-mcp-server
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"joshidikshant-loopback": {
"type": "local",
"command": [
"npx",
"-y",
"loopback-mcp-server"
],
"enabled": true
}
}
} openclaw mcp add joshidikshant-loopback --command npx --arg -y --arg loopback-mcp-server
mcp_servers:
joshidikshant-loopback:
command: "npx"
args: ["-y", "loopback-mcp-server"] {
"McpServers": {
"joshidikshant-loopback": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"loopback-mcp-server"
]
}
}
} assistant mcp add joshidikshant-loopback -t stdio -c npx -a -y loopback-mcp-server
{
"mcpServers": {
"joshidikshant-loopback": {
"command": "npx",
"args": [
"-y",
"loopback-mcp-server"
]
}
}
} 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.
- 22 Sept 26 +1
- Stability: 0.97 → pass security
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 −3
- Stability: pass → 0.80 functional
- 15 Sept 26 +1
- Stability: 0.97 → pass security
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 −3
- Stability: pass → 0.80 functional
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 22 Sept 2026 · Analysed npm/loopback-mcp-server@0.9.4
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 95 packages
| Packages resolved | 95 |
|---|---|
| Stale | 31 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
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. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
loopback_add_comment Comment on feedback ~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).
| Name | Type | Req | Description |
|---|---|---|---|
| author | string | yes | Comment author, e.g. 'claude-code' or 'dj' |
| body | string | yes | Comment text (markdown ok) |
| id | string | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_claim_feedback Claim feedback item ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_get_feedback Get feedback item ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| response_format | string | – | 'markdown' for human-readable, 'json' for machine-readable |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_get_stats Queue 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 }] }.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | – | Limit stats to one project; omit for all projects |
| Name | Type | Req | Description |
|---|---|---|---|
| projects | array | yes | – |
| total | integer | yes | – |
No examples provided.
loopback_link_change Link code 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'.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| pr_url | string | – | Pull request URL |
| repo | string | – | Repository, e.g. 'dj/appbroda-web' |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_list_feedback 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').
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | Items in this response |
| has_more | boolean | yes | – |
| items | array | yes | – |
| next_offset | integer | – | Pass as offset for the next page |
| offset | integer | yes | – |
| total | integer | yes | Total matching the filters |
No examples provided.
loopback_resolve_feedback 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| note | string | – | Optional closing note recorded as a comment |
| resolution | string | yes | 'verified' = fix confirmed against the running app/metric; 'wontfix' = intentionally not addressing |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_submit_feedback 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'.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | yes | Short summary, e.g. 'Checkout button dead on mobile Safari' |
| type | string | yes | Feedback dimension: 'ui' (visual/design), 'backend' (errors/API), 'usage' (analytics/behavior), 'ux' (flow/experience) |
| url | string | – | Full URL where observed |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_update_feedback Edit feedback item ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| author | string | – | Who is making the edit — recorded on the audit trail |
| body | string | – | Corrected description |
| id | string | yes | 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 |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
loopback_update_status Update feedback 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.
| Name | Type | Req | Description |
|---|---|---|---|
| author | string | – | Who is making the change (for the audit trail) |
| id | string | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| note | string | – | Optional note recorded as a comment alongside the change |
| status | string | yes | New status. Workflow: open → triaged → in_progress → fixed → verified | wontfix |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| comments | array | – | Full audit trail |
| console | array | yes | Console lines captured at report time |
| created_at | string | yes | – |
| dom_selector | string | – | – |
| extra | object | yes | 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 | yes | Feedback id, e.g. 'fb_mabc12_3f9a1c' |
| links | object | yes | Repo/branch/commit/PR of the fix |
| network | array | yes | Network calls captured at report time |
| project | string | yes | – |
| replay_url | string | – | – |
| reporter | string | yes | – |
| repro_steps | array | yes | – |
| resolution | string | – | – |
| route | string | – | – |
| screenshot_path | string | – | – |
| severity | string | yes | – |
| source | string | yes | – |
| status | string | yes | – |
| title | string | yes | – |
| type | string | yes | – |
| updated_at | string | yes | – |
| url | string | – | – |
No examples provided.
What is the io.github.joshidikshant/loopback MCP server?
io.github.joshidikshant/loopback is an MCP server listed in the public MCP registry as io.github.joshidikshant/loopback. Feedback bus for coding agents: pin feedback on the app you're building; a fix turns the pin green. This page covers its npm package (loopback-mcp-server).
Is the io.github.joshidikshant/loopback MCP server safe to use?
io.github.joshidikshant/loopback scores 84 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 22 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.joshidikshant/loopback MCP server expose?
io.github.joshidikshant/loopback exposes 10 tools: loopback_submit_feedback, loopback_list_feedback, loopback_get_feedback, loopback_claim_feedback, loopback_update_status, and 5 more. Their descriptions and schemas cost roughly 2,144 tokens of context every time the server is loaded.
Is the io.github.joshidikshant/loopback MCP server still maintained?
io.github.joshidikshant/loopback is still listed as active in the MCP registry. We last reached this channel on 22 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.joshidikshant/loopback MCP server under?
io.github.joshidikshant/loopback declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.