Mmcp.market

Is MCP Server safe?

Probably. Read the findings first.

C55/100grade C

Use with care. Some checks failed or could not be verified.

What to know before installing
  • highWrite-action tools reachable without authentication

Public scan report

scanner v0.1.9 · 2026-09-24 · same rubric, same numbers if you re-run it

1 high2 low
  • –Code scanremote-only server, no package to scann/a
  • Live reliabilityremote reachable in 534ms20/20
  • Tool poisoning18 tool descriptions checked13/15
  • Auth qualityopen endpoint exposes 9 write-action tools with no auth3/15
  • Maintenanceno repository listed3/15
  • Maintainer identityno repository or website to verify2/10

Findings (3)

  • highWrite-action tools reachable without authenticationauth.open-write
  • lowUnusually long tool description (over 2,000 characters)poison.long-description
    tool manage_trigger: …Create, list, update, delete, or fire a workspace job trigger. Four types: - "sftp"/"aws_s3": pulls files from a connection (sftp: remote server; aws_s3: S3 bucket/prefix) into an already-analyzed data spec on a schedule (hourly/daily/monthly, UTC). Type must match the connection's type; aws_s3 also requires s3Bucket (s3Prefix optional). Natural-language preRules (which files to pick up) and postRules (what to do after upload) are compiled into executable code server-side — never pass raw code. The connection must already exist and have passed test (see manage_connection). For a first-time "set up a daily/scheduled pull" request, prefer setup_scheduled_pull, which sets up the connection and trigger together. - "spec_success": fires a spec automatically whenever a DIFFERENT spec's job completes successfully (set upstreamSpecName to that spec). No connection/frequency. Use this when the request ties the run to another job finishing (e.g. "run this after the customers load finishes"). - "schedule": fires a spec directly on a plain frequency (hourly/daily/monthly, UTC), no connection and no upstream spec. Use this when the request is time-based with no dependency (e.g. "run this every morning"). IMPORTANT: "spec_success" and "schedule" triggers can only target a table-source (sourceType: "tables") or compaction (sourceType: "compaction") spec (see onboard_data_source) — they have no file to load, only a generated query to re-run or a set of tables to compact. If asked to set up a scheduled/recurring job that reads from an already-loaded table (e.g. "keep a daily summary of the orders table up to date"), create that as an onboard_data_source sourceType "tables" spec first, THEN create the trigger here. Same for a recurring compaction — create the sourceType "compaction" spec first. Prefer "spec_success" when the user's phrasing implies "after X loads/finishes"; prefer "schedule" when they just want a cadence with no stated dependency; ask if genuinely ambiguous. For sftp/aws_s3, the referenced spec must already have been analyzed once (see onboard_data_source). After firing a trigger (action "run-now") — or any one-off manual run — use action "run-history" to monitor its outcome: it starts as `status: running` and settles to `success`, `failed`, or `no-files`, with `filesPulled` and a `message`.…
  • lowNo source repository listedmaint.no-repo
Overall 55/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

MCP Server reviews, tools and install