A side-by-side look at the Hlido MCP and AtlaSent MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Hlido MCP for security work over a hosted endpoint; choose AtlaSent MCP Server for security as a local process. You can also run both side by side in one mcpServers block.
trust_check, find_trusted, verify_claim.ATLASENT_MODE, ATLASENT_API_KEY, ATLASENT_BASE_URL.evaluate, verify_permit, deploy_service.Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Security | Security |
| Quality signal | 49/100 · Fair | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Freemium |
| Required env vars | None listed | ATLASENT_MODEATLASENT_API_KEYATLASENT_BASE_URL |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 3 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 19 | 20 |
| Full listing | View Hlido MCP | View AtlaSent MCP Server |
trust_checkThe core Hlido trust query: is a specific AI agent trustworthy? Given one agent (by Hlido slug or product/homepage URL) it returns the independent Laddoo trust score (0-100), tier (VITAL/STEADY/FADING/FLATLINE), a one-line verdict, a claim-verification summary, and any known incidents. Call this FIRST — before delegating to, installing, or relying on another agent — to get a fast trust read. Returns no_review_found if the agent isn't in Hlido's corpus (then call request_quick_audit). For the full claim-by-claim evidence, follow up with get_scorecard.find_trustedDiscover Hlido-reviewed agents that match a free-text need, ranked by trust. Returns reviewed agents at or above a minimum tier, each with its Laddoo score, tier, and review URL. Use this for keyword/need-based discovery; for semantic task-matching prefer find_similar_agents, and for structured constraint filters (category/score/tier) prefer recommend.verify_claimFact-check one specific marketing or capability claim about an agent against Hlido's independent testing. Returns Hlido's verdict (PASS/FAIL/PARTIAL/UNKNOWN) with a quoted evidence snippet and its source surface — or an honest null when that exact claim wasn't tested (absence of evidence, not proof). Use this to validate a vendor's specific promise before you rely on it.compare_agentsHead-to-head trust comparison of 2-5 Hlido-reviewed agents. Returns each agent's Laddoo score, tier, dimension scores, and key claim verdicts side by side so you can pick the most trustworthy option for a task. Use this once you've shortlisted candidates (via find_trusted, find_similar_agents, or recommend) and need a direct comparison.submit_agentNominate a new AI agent for Hlido to review. Use this when an agent isn't in Hlido's corpus yet (trust_check returned no_review_found) and you want it added. Returns a confirmation with a tracking reference; the review is queued and produces a public scorecard. If you need a verdict right now rather than a queued review, use request_quick_audit (faster, rate-limited) instead.verify_transparencyCheck any AI agent's EU AI Act Article-50 transparency posture — including agents Hlido has NOT reviewed yet. Returns two clearly separated layers: (1) Hlido's independent register verdict when the agent is in our reviewed corpus, and (2) a live public-surface probe of the Article-50 signals (AI-interaction disclosure, machine-readable marking/provenance, deepfake/synthetic labelling, detection tool). Use before adopting or delegating to a tool ahead of the 2026-08-02 transparency obligations. The live probe is a first-pass surface read, NOT a compliance determination and NOT legal advice; an undetected signal means 'not discoverable on the public surface', not 'non-compliant'. Unreviewed agents are automatically queued for a full independent review.get_scorecardFetch the full sanitized claim-vs-evidence scorecard for one Hlido-reviewed agent. Returns every claim, verdict, evidence quote, source surface, and (for CLI/API tests) the captured command + exit_code + duration. Schema v1.0. Use this for agent-to-agent pre-flight evaluation.get_incidentsFetch published incidents from Hlido's NTSB-style failure registry — real observed agent failures (availability outages, regressions, hallucinations, safety issues) plus Hlido self-reported process incidents, each with severity, evidence, and vendor-response status. Filter by agent slug, severity, or category. Use this before delegating to an agent to check for known recent failures; an empty list means no published incidents, not a guarantee of reliability.report_review_issueReport an issue with a Hlido review (stale info, wrong verdict, missing claim, broken link). Use when calling get_scorecard or trust_check returns data you can prove is incorrect. Hlido's R1 maintenance routine processes reports daily and fires re-tests via dispute-retest sub-agent.request_quick_auditRequest that Hlido audit a NEW AI agent that has no review yet. Use this when trust_check or get_scorecard returns no_review_found and you need a verdict before delegating to the unknown agent. Returns a future scorecard URL + ETA. Free-tier rate-limited (5/day per anonymous, 50/day per identified). The audit produces signed evidence + claim verification within ~24h (sooner if founder triggers manually).find_similar_agentsSemantic search over Hlido's review corpus. Given a task description (e.g. 'I need an agent that can refactor TypeScript and edit multiple files at once'), returns the top-N reviewed agents ranked by embedding similarity, each with their Laddoo score, evidence_tier, and review URL. Use this when you have a task in mind and want Hlido's recommendation — much better than substring matching via find_trusted.subscribePreview — Wave 3 will add persistent webhook + RSS subscriptions. For now this returns the agent's current state plus advisory polling instructions (RSS at /changelog/feed.xml or polling /data/attestations/{slug}.json). Use this to register interest in being notified when a slug's verdict changes.evaluateCall this BEFORE performing any sensitive action. Returns a Decision: `allow` (verify the returned permit_token at the execution boundary before proceeding), `deny` (you MUST NOT proceed), or `hold` (do not proceed; route for review).verify_permitCall this AFTER `evaluate` returns allow and BEFORE the protected native side effect. It verifies the permit for the presented execution context. Proceed only when `valid` is true; expired, invalid, replayed, mismatched, or error outcomes must block the action.deploy_serviceExample protected tool. Every call is authorized AND its Permit is verified by AtlaSent before the deploy runs. Denied, held, expired, replayed, mismatched, or unverifiable calls are blocked and never touch the target system.atlasent_evaluateEvaluate an action against your published AtlaSent policies. Returns allow/deny/hold/escalate with a permitToken on allow. Use this when ATLASENT_MODE=remote and you need to gate an action against your hosted policy engine. For agent.* actions the result may carry bound_payload_hash and bound_actor_id: pass them to verify_permit as payload_hash and actor_id, since the permit is bound to them.atlasent_list_policiesList all constraint bundles / policies for this organization.atlasent_list_audit_eventsRetrieve recent evaluation events from the audit log.atlasent_explain_authorityExplain why a principal currently has (or lacks) authority for a scope. Answers 'why may principal P exercise scope/action A in organization O right now?' — strictly read-only, does not change /v1-evaluate, /v1-verify-permit, or any deny/hold/allow semantics; it explains the same facts those paths already read. Every matched authority mechanism (direct_grant, delegation, role_capability) is reported as its own path entry; every excluded or ambiguous relationship is reported as its own unresolved finding.atlasent_integrity_auditAudit the organization's authority graph for internal inconsistency and return the report verbatim. Strictly read-only; changes no policy, permit, or decision. THIS IS NOT A PASS/FAIL HEALTH CHECK and the tool synthesizes no verdict of its own. Each finding carries a three-way `classification`: `defect` is a genuine inconsistency; `non_exercisable` is frequently the CORRECT, healthy state (e.g. an expired grant that is supposed to be expired) and must not be read as a failure; `unresolved` means the proposition COULD NOT BE VERIFIED and must never be treated as clean. Read `summary.audited_scope` before drawing any conclusion from an empty findings list — a short decision window is not an absence of findings. If the audit cannot complete, the server refuses rather than returning a partial report, and this tool surfaces that as an error — never an empty report.atlasent_list_permitsList issued permit tokens for audit and monitoring.atlasent_await_approvalWait for a person to approve or reject a held action in the AtlaSent console. Use the approval_request_id from a 'hold' result. This tool cannot approve anything; it only waits. If approved, it returns a permit_token that you MUST verify with verify_permit before running the action. Any other outcome (rejected, expired, timed out) means the action must not run.atlasent_lookup_actionLook up canonical action specifications from the Authorization Intelligence Library. Returns the permanent canon_id, gate flags (requires_human_approval, requires_mfa, requires_verified_actor, requires_state_snapshot), authorization pattern, risk posture, AI risk classification, regulatory mappings, evidence requirements, and the action's knowledge-graph relationships (what it requires and produces, and which frameworks / control objectives it satisfies) for every governed action type in the Canon. Use `slug` for an exact match (e.g. 'production.deploy') or `query` to describe what you want to do in plain language (e.g. 'deploy the api service to prod', 'grant admin access', 'close the books'). `query` is ranked offline against the vendored Canon and returns a `retrieval` block with `confidence` = confident | ambiguous | none — act only on `confident`; the tool never invents an action type, and a `none` result means the Canon has no such action (see the hint). Omit both to list the full Canon.atlasent_atlas_lookupLook up a canonical AtlaSent concept from the Knowledge Atlas — the compiled graph of the system's own vocabulary (Caller, Authority, Policy, Decision, Permit, Verification, Evidence, Audit Chain, Gate, Trust Root, ...). Returns the concept's canonical definition (its source-of-truth doc), its relationships (what it depends on and what depends on it), the surfaces that realize it, and its ADR / API / SDK / implementation anchors — so every AI host reasons from the same canonical knowledge instead of guessing. Use `id` for an exact concept id (e.g. 'permit', 'audit-chain', 'gate') or `query` for a case-insensitive substring search across id, term, and definition. Omit both to list every concept.Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
{
"mcpServers": {
"ankitkapur1992-hlido-hlido-mcp": {
"url": "https://hlido.eu/mcp"
}
}
}
{
"mcpServers": {
"atlasent-mcp-server": {
"command": "npx",
"args": [
"-y",
"@atlasent/mcp-server"
],
"env": {
"ATLASENT_MODE": "YOUR_ATLASENT_MODE_HERE",
"ATLASENT_API_KEY": "YOUR_ATLASENT_API_KEY_HERE",
"ATLASENT_BASE_URL": "YOUR_ATLASENT_BASE_URL_HERE"
}
}
}
}