Sqemo MCP Server

sqemo-mcp npm v1.2.1

Published by sqemo — no publish provenance, so origin is unverified, but the source is public: the repository link below is self-declared yet readable, so you can inspect the code before adopting it.

Trust grade
C
74/100
Last scanned
Trust
C · 74/100
Adoption risk for you: the threat score, then adjusted down for blast radius, publisher verification and how much the scan could see. Deterministic; every point is auditable.
Capability
Moderate
Blast radius if it went rogue — what the server’s tools could reach. Independent of trust.
Coverage
Source
How much the scan could actually inspect. Shallow coverage is stated, never hidden.
C Why this grade threat 78 − adoption risk = 74/100

The grade answers one question — how safe is this server for you to adopt — so it is computed in two auditable stages. Nothing below is an opinion or an LLM's guess; every line is a real term the deterministic engine applied, and the same input always yields the same number.

1. Threat score — 100 − 22 = 78. What the published surface and source actually contain:

PointsWhat was foundCategory
−22 Hardcoded JSON Web Token in server code MTC-SRC-008 exfiltration

2. Client adoption risk — 78 − 4 = 74. Three small, subtract-only factors that reflect your risk in adopting it — a clean scan proves less on a powerful, unverified or barely-inspectable package, so the grade says so plainly:

PointsAdoption-risk factor
−3 capability blast radius (moderate) — client exposure if the model is manipulated
−1 publisher verification (public source) — no provenance, but the source is public and inspectable
inspection depth (source) — how much of the target the scan could see

Grade capped: 1 confirmed high finding → grade capped at C. A hard gate overrides the point total — no amount of clean surface buys back a confirmed catastrophe.

Capability observations and info notes are shown under Findings but never scored. Open any row's finding below for the file, line and evidence behind a deduction.

Findings 2

high Hardcoded JSON Web Token in server code (dist/chunk-VVDZ2CVM.js)MTC-SRC-008

A live-looking JSON Web Token is hardcoded in `dist/chunk-VVDZ2CVM.js:192`. Secrets in source ship to everyone who installs the package and are a direct credential leak.

Evidence: JSON Web Token: eyJh…(redacted)

Fix: Remove the secret, rotate it, and load credentials from the environment or a secret store.

Location: server dist/chunk-VVDZ2CVM.js

low Unconstrained path parameter "file" on "create_erd"MTC-CAP-008

Tool "create_erd" takes a path parameter "file" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool create_erd · inputSchema.properties.file

Tools 34

Each tool and what it can reach — statically extracted from the published source.

  • create_erdreads sensitive data
  • import_sqlreads sensitive data
  • auto_layoutno sensitive capability
  • check_namingno sensitive capability
  • delete_attributeno sensitive capability
  • delete_dictionary_wordno sensitive capability
  • delete_domainno sensitive capability
  • delete_entityno sensitive capability
  • delete_relationshipno sensitive capability
  • diff_erdsno sensitive capability
  • export_alter_sqlno sensitive capability
  • export_dbmlno sensitive capability
  • export_sqlno sensitive capability
  • generate_physical_nameno sensitive capability
  • get_entityno sensitive capability
  • get_erd_overviewno sensitive capability
  • import_dbmlno sensitive capability
  • lint_erdno sensitive capability
  • list_domainsno sensitive capability
  • list_entitiesno sensitive capability
  • list_erdsno sensitive capability
  • list_proposalsno sensitive capability
  • list_relationshipsno sensitive capability
  • list_workspacesno sensitive capability
  • propose_dictionary_wordno sensitive capability
  • search_dictionaryno sensitive capability
  • update_naming_rulesno sensitive capability
  • upsert_attributeno sensitive capability
  • upsert_dictionary_wordno sensitive capability
  • upsert_domainno sensitive capability
  • upsert_entityno sensitive capability
  • upsert_relationshipno sensitive capability
  • validate_erdno sensitive capability
  • withdraw_proposalno sensitive capability

What this scan could not see

Versions

Scan history per published version. The engine is deterministic — the same version always yields the same score, so a changed score means the package itself changed.

VersionScoreFindingsEngineScanned
v1.2.1 latest C 74/100 2 1.8.0 2026-07-23

Embed this score

Show this server's live Trust Score in your README, docs or website. The badge is served straight from the registry and updates automatically after every rescan — no API key needed. It links back to this page, so anyone who sees the grade can also read the findings behind it instead of taking a number on faith.

MCP Trust Score: C · 74/100
Markdown (GitHub README)
[![MCP Trust Score](https://mcptrustchecker.com/registry/sqemo-mcp/badge.svg)](https://mcptrustchecker.com/registry/sqemo-mcp)
HTML
<a href="https://mcptrustchecker.com/registry/sqemo-mcp"><img src="https://mcptrustchecker.com/registry/sqemo-mcp/badge.svg" alt="MCP Trust Score" height="20"></a>
Prefer shields.io styling? Point it at https://mcptrustchecker.com/registry/sqemo-mcp/badge.json via https://img.shields.io/endpoint?url=…

Verify this score yourself

The score above is reproducible: the same package version always yields the same result. Run it locally or over the free API — no account, no LLM, fully deterministic.

npx mcptrustchecker scan sqemo-mcp --online

Use the free API → How scoring works

More in Developer Tools