Is Remoet MCP server safe?
Yes, with the usual care.
Safe to use. Minor gaps such as a missing repository or slower maintenance.
What to know before installing
- highWrite-action tools reachable without authentication
How Remoet compares
Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.
- Safety score
- 80/100
- higher than 60% of 48,255 servers
- Tools that change things
- 29%
- typical: 0%. Fewer write tools means less an agent can break
- Uptime
- 96%
- of our recent checks; the typical remote server answers 100%
What its tools let an agent do: 12 read · 5 create · 4 change · 2 delete · 1 run or deploy
Public scan report
scanner v0.1.9 · 2026-09-27 · same rubric, same numbers if you re-run it
1 high1 low
- –Code scanremote-only server, no package to scann/a
- Live reliabilityremote reachable in 280ms20/20
- Tool poisoning24 tool descriptions checked13/15
- Auth qualityopen endpoint exposes 7 write-action tools with no auth3/15
- Maintenancelast push 11 days ago15/15
- Maintainer identityregistry namespace matches repository owner; GitHub account older than a year9/10
Findings (2)
- highWrite-action tools reachable without authentication
auth.open-write - lowUnusually long tool description (over 2,000 characters)
poison.long-descriptiontool search_jobs: …Works without a Remoet account. Search Remoet's PUBLIC job catalogue: every role on the open board at remoet.dev/jobs, across all companies, not just the ones the user has starred. No star is needed and none is consumed. Use this to answer "what is out there" for any technology, title or company; use get_starred_jobs instead for the user's own curated feed. Each result carries the role's public Remoet URL, which is a real page anyone can open, plus applyUrl (the employer's own posting, where an application actually happens) and companySlug (the same slug get_listing takes, for company detail). Roles that Remoet is not permitted to publish never appear here. Duplicate postings of one role at a company are collapsed into a single result, so totalCount is the number of distinct roles, not raw postings. duplicateCount is how many postings collapsed into it; boards usually duplicate a role per location, but nothing guarantees that, so do NOT report it as a number of locations. firstSeenAt is when Remoet first saw the role, not when the employer posted it, and lastVerifiedAt is the last time Remoet confirmed it was still open. Filters are searchQuery (title, Remoet summary and tech stack), techStack (ANY of the given technologies, or EVERY one under techStackMatch: "all", which is how you express a must-have stack), companySlug, location, remotePolicy, experienceLevel and salaryMin. A salaryMin floor drops every role Remoet holds no numeric salary for, which is roughly 45% of the board, so use it when salary is a hard requirement and leave it off otherwise. location matches the canonical places Remoet stores per role rather than the free-text location string, so a country also finds roles that name only one of its cities; searchQuery does NOT read location, so filter by place with location and not by typing the place into searchQuery. When a search returns nothing, the hint says which filter emptied it and how many roles dropping that one filter would return, so act on the hint rather than guessing at which filter to relax. Results are newest-first unless you ask otherwise: sortBy takes "newest" or "salary", with sortOrder asc or desc. Start broad and narrow: a single heavily filtered query misses good roles. Use save_job to bookmark anything worth keeping. Example: search_jobs({ searchQuery: "platform engineer", techStack: ["Go", "Kubernetes"], location: ["Berlin"], remotePolicy: ["remote"] }).…
Overall 80/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON