Which integrations are available for this server?

Enables integration with GitHub code scanning by outputting SARIF reports, showing attack chains inline on pull requests. Supports Helm charts as input for attack path analysis across resources and relationships. Analyzes Kubernetes manifests for exposure via LoadBalancer/NodePort services, privileged pods, cluster-admin ServiceAccounts, and mounted secrets. Analyzes OpenTofu configurations for attack paths, similar to Terraform support, detecting multi-hop chains to sensitive resources. Analyzes Pulumi programs (TypeScript and Python) for attack paths, enabling auditing before deployment. Analyzes Terraform configurations for multi-hop attack paths from the public internet to crown jewels, such as data stores and secrets.

How do I use cloud-pathfinder?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cloud-pathfinder audit main.tf and k8s.yaml for internet to admin attack paths" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cloud-pathfinder

by Baneado98

Overview Schema Related Servers Score Discussions

Remote

cloud-pathfinder 🛰️

License: MIT MCP Registry npm Pay SARIF

Attack-path auditor for Infrastructure-as-Code — Terraform, CloudFormation, Kubernetes, CDK, Pulumi, Bicep/ARM. Not a linter. It parses your IaC into a resource graph, resolves cross-resource (and cross-file) relationships, and searches for the multi-hop chains from the public internet to your crown jewels (data stores, secrets, admin). It returns a BREACHABLE / EXPOSED / HARDENED verdict and the concrete route an attacker would walk.

Example chain it finds: open security group (SSH 0.0.0.0/0) → EC2 instance-profile role → iam:PassRole privilege escalation to admin → S3 exfiltration

Available as an MCP server (Claude, Cursor, any MCP agent) and a pay-per-call x402 API (autonomous AI agents with a wallet).

🔐 Privacy & data model (read this first)

Sending your IaC to a third party is sensitive — so here is exactly what happens:

Your IaC is never stored and never logged. Every audit runs in memory on the hosted service and is discarded when the response is sent. No database of your templates, no retention, no analytics on file contents.
What is sent: only the IaC text you pass (the files map or source blob). Nothing is read from your machine, your cloud account, or your credentials — cloud-pathfinder never touches a live cloud (see "honest limits" below). There are no cloud keys to provide because it analyzes the declared templates only.
Free tier vs deep tier — both run server-side, here's why and what differs:
- The thin npm client ships zero analysis logic (no graph engine, no IAM privesc knowledge base). It is a pure HTTP caller. So even the free verdict + counts are computed on the hosted service, then your IaC is dropped. This is the honest tradeoff that keeps the moat off your machine — we say so plainly rather than claim a fake "100% local" mode.
- Deep analysis is strictly opt-in (deep: true, behind payment). Only then are the full chains, file:line evidence and remediation returned. You send the same IaC either way — nothing extra leaves your machine for the deep tier.

Hosted service: https://cloud-pathfinder.vercel.app — all analysis runs server-side. This npm package is a thin MCP client: it sends the IaC text to the hosted endpoint and renders the verdict. No analysis logic ships to your machine.

Related MCP server: aegis

⚡ How it works (30 seconds)

Your MCP agent calls audit_iac_attack_paths { files: { "main.tf": "..." } }.
The thin client POSTs the IaC text to https://cloud-pathfinder.vercel.app.
The hosted engine builds a typed resource graph, runs a BFS from an INTERNET node to every data store / secret / admin sink, and resolves IAM privilege-escalation reachability along each hop — in memory.
The IaC is discarded; nothing is persisted.
The deep tier returns every full chain with per-hop file:line evidence; the free tier returns the verdict, score and counts.

The npm tarball contains only the HTTP caller — so nothing, free or deep, runs offline. Without the server it degrades to a clear network error.

🆚 Why this isn't a linter (and why a local one can't replace it)

A linter flags resources one at a time: "this SG is open", "this role is broad". cloud-pathfinder reasons about how those facts connect — work a per-file local tool structurally cannot do:

Capability	Local linter	cloud-pathfinder
Flag one open SG / one broad role	✅	✅
Graph — which SG attaches to which instance, which role it assumes, what it reads	❌	✅
Reachability BFS internet → crown jewel, full multi-hop chain + file:line	❌	✅
IAM privilege-escalation KB (20+ primitives: PassRole, CreatePolicyVersion…)	❌	✅
Multi-cloud — AWS / GCP / Azure in one graph	❌	✅
Choke-point analysis (the one hop that, fixed, cuts the most paths)	❌	✅
Diff mode — what a PR INTRODUCES / ELIMINATES / AGGRAVATES	❌	✅
Kubernetes LB/NodePort → privileged pod → cluster-admin SA → Secret	❌	✅
SARIF 2.1.0 for GitHub code scanning (inline chains on the Security tab)	❌	✅

🔗 Graph, not lint. Builds a typed resource graph and resolves the real relationships across files and clouds.
🧭 Reachability search. BFS from INTERNET to every data store / secret / admin sink, returning the full multi-hop chain with per-hop file:line evidence.
👑 IAM privilege-escalation knowledge base. Knows AWS managed-policy permissions and 20+ privilege-escalation primitives (PassRole+RunInstances, CreatePolicyVersion, AttachRolePolicy, SSM SendCommand, UpdateFunctionCode, UpdateAssumeRolePolicy…).
☸️ Kubernetes attack surface. LoadBalancer/NodePort exposure → privileged / hostPath / hostNetwork pods, cluster-admin ServiceAccounts, and mounted Secrets.

Formats are auto-detected per file and analyzed together — mix .tf, CloudFormation .yaml/.json and Kubernetes manifests in one call.

🚀 Quickstart — add it to your MCP client

{
  "mcpServers": {
    "cloud-pathfinder": { "command": "npx", "args": ["-y", "cloud-pathfinder-mcp"] }
  }
}

No key needed for the free tier. Restart your client and the audit_iac_attack_paths + diff_attack_paths tools appear. (Remote server: https://cloud-pathfinder.vercel.app/mcp.)

Tool: `audit_iac_attack_paths`

{
  "files": {
    "main.tf": "resource \"aws_security_group\" \"web\" { ingress { ... cidr_blocks = [\"0.0.0.0/0\"] } } ...",
    "k8s.yaml": "apiVersion: v1\nkind: Service\n..."
  }
  // or: "source": "<a single IaC blob>", "filename": "main.tf"
}

Example — input → output

audit_iac_attack_paths { "files": { "main.tf": "<SG open to 0.0.0.0/0 on 22 +
                          EC2 with instance-profile role that can s3:* + iam:PassRole>" } }

→ FREE:  verdict: BREACHABLE · risk 86/100 · 1 attack path · 1 crown jewel · 3 misconfigs

→ DEEP (deep:true):  verdict: BREACHABLE
   PATH #1 (internet → admin):
     [1] INTERNET → aws_security_group.web   (main.tf:4  — ingress 22 from 0.0.0.0/0)
     [2] → aws_instance.app                  (main.tf:19 — attaches sg web)
     [3] → aws_iam_role.app_role             (main.tf:31 — instance profile)
     [4] → iam:PassRole + ec2:RunInstances   (privesc → launch instance as admin role)
     [5] → s3:* on aws_s3_bucket.data        (main.tf:52 — exfiltration sink)
   CHOKE POINT: tighten main.tf:4 ingress → cuts this entire path.
   FIX: restrict ingress CIDR; split the role; add a permissions boundary.

The free tier returns the verdict, risk score, and the counts (how many attack paths, crown jewels and misconfigurations). The deep tier returns every full chain with hops, file:line evidence, privilege-escalation reachability and remediation.

Tool: `diff_attack_paths` — the CI/CD gate

Give it the IaC before and after a change (a PR's base and head trees) and it reports exactly what the change did to your attack surface: which internet→crown-jewel chains it INTRODUCES, which it ELIMINATES, and which it AGGRAVATES — with an INTRODUCES_BREACH / REDUCES_RISK / NEUTRAL / MIXED verdict.

{
  "before": { "files": { "main.tf": "...security group admits 10.0.0.0/16..." } },
  "after":  { "files": { "main.tf": "...security group admits 0.0.0.0/0..." } }
  // deep: true → full introduced/eliminated chains + before→after exploitability + which choke points now matter
}

A per-file linter or a single-state scan cannot answer this: it needs the full graph

privesc reachability on both states and a semantic cross-state path match. HTTP: POST /diff (free, counts only) / POST /pro/diff (deep).

Free HTTP API

POST /audit
Content-Type: application/json

{ "files": { "main.tf": "resource \"aws_security_group\" ..." } }

Rate-limited to 30 requests/hour/IP. For unlimited/commercial/deep use, call /pro/audit.

Input formats: Terraform / OpenTofu, CloudFormation, Kubernetes, Helm, Kustomize, Pulumi (TS/JS/Python), Bicep/ARM, and AWS CDK — both the synthesized cdk.out/*.template.json and the un-synthed CDK program (TypeScript + Python), so a CI gate runs on the PR diff before cdk synth.

SARIF 2.1.0 → GitHub code scanning

Add ?format=sarif (or { "format": "sarif" }) to /audit, /pro/audit, /diff or /pro/diff to get SARIF 2.1.0 you can upload to GitHub code scanning — every attack chain shows up inline on the PR's Security tab.

Each chain is one SARIF result with a codeFlow (a step-through walk: internet → SG → instance role → privesc → S3), anchored to the IaC file:line, plus security-severity/CVSS so the badge colors correctly.
The diff SARIF only fails the check on introduced/aggravated routes (error-level); eliminated/eased land as note.
The free tier returns a redacted-but-schema-valid SARIF (counts only — no chains, no code-flows, no route file:line); the full code-flows are premium.

# .github/workflows/cloud-pathfinder.yml (sketch)
- run: curl -s -X POST "$CPF/pro/diff?format=sarif" -H "Authorization: Bearer $KEY" \
       --data @payload.json -o cloud-pathfinder.sarif
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: cloud-pathfinder.sarif }

💳 Unlock `/pro` — two ways to pay (dual-pay)

The deep /pro/audit returns the full attack chains, per-hop evidence, privilege-escalation analysis and remediation. Two payment lanes coexist:

Lane	For	How
💳 Card (Stripe)	Humans / teams	Buy a prepaid key at `/pro/checkout`, then send `Authorization: Bearer <key>` (or set `CLOUD_PATHFINDER_KEY`).
🪙 x402 (USDC)	AI agents with a wallet	Pay $0.30 per call automatically. Settles on Base. No signup, no key.

POST /pro/audit          # 402 (shows BOTH lanes) → pay → result

What it catches (selected)

Class	Detail
Public → role → data	Open SG on a sensitive port (SSH/RDP/DB) → instance role that can read S3/Dynamo/RDS/Secrets → exfiltration
IAM privilege escalation	`iam:PassRole`+`ec2:RunInstances`, `iam:CreatePolicyVersion`, `iam:AttachRolePolicy`, `ssm:SendCommand`, wildcard `` on ``, and ~15 more
Public data stores	`publicly_accessible = true` RDS, world-open buckets
Kubernetes	LoadBalancer/NodePort → privileged pod → cluster-admin ServiceAccount → Secret
CloudFormation	`!Ref`/`!GetAtt` intrinsics resolved; `ManagedPolicyArns`/inline policies analyzed

How it stays honest

The premium engine and knowledge base never ship in the npm package — the published client is a thin renderer that calls the hosted analysis service. The free tier is genuinely useful (verdict + counts); the deep chains, evidence and privesc analysis are server-side behind payment.

Heuristic static analysis of declared IaC, not a live cloud assessment. It reasons over what the templates declare (no runtime SCP/permissions-boundary/condition evaluation). Treat findings as prioritized leads, not a guarantee.

MIT · github.com/Baneado98/cloud-pathfinder

Available Tools

2 tools

audit_iac_attack_pathsAInspect

Find real ATTACK PATHS in Infrastructure-as-Code (Terraform, CloudFormation, Kubernetes) — not a linter. Give it your IaC files (a map of filename→content, or a single source blob) and it parses them into a resource graph, resolves cross-resource relationships, and searches for chains from the public INTERNET to your crown jewels (data stores, secrets, admin). It returns a BREACHABLE / EXPOSED / HARDENED verdict and the concrete multi-hop routes an attacker would walk — e.g. 'open security group (SSH 0.0.0.0/0) → EC2 instance-profile role → iam:PassRole privilege escalation to admin → S3 exfiltration'. Understands AWS managed-policy permissions, 20+ IAM privilege-escalation primitives, public security groups / RDS, and Kubernetes LoadBalancer/NodePort exposure + privileged pods + cluster-admin ServiceAccounts. Use it before applying IaC or in a PR to catch breach paths a per-resource linter misses. Heuristic static analysis of declared IaC.

ParametersJSON Schema

Name	Required	Description
`deep`	No	When true, runs the PREMIUM deep audit: full attack chains with per-hop evidence (file:line), privilege-escalation reachability and remediation. Requires an API key (set CLOUD_PATHFINDER_KEY in your MCP env); without one you'll get unlock instructions. The free verdict + counts need no key.
`files`	No	Map of filename → file content. Mix Terraform (.tf/.tf.json), CloudFormation (.yaml/.json) and Kubernetes (.yaml) freely; formats are auto-detected. Cross-file references are resolved.
`source`	No	Optional: a single IaC blob to analyze when you don't have separate files. Format auto-detected.
`filename`	No	Optional filename hint for `source` (helps format detection, e.g. main.tf).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It discloses the heuristic nature: 'Heuristic static analysis of declared IaC,' explains it resolves cross-resource relationships, describes the output verdict and attack routes, and notes the API-key requirement for deep scans. It does not cover potential limitations like false positives or performance, but the core behavior is well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but well-organized: it opens with the core purpose, explains the process, lists supported formats and attack primitives, provides usage guidance, and closes with the heuristic caveat. It is slightly long but every sentence adds useful information; the structure is front-loaded and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description fully explains the return value (verdict and routes) and the deep audit's additional evidence. It covers input flexibility, format auto-detection, cross-file resolution, API-key requirements, and known limitations. For a tool with 4 optional parameters and no output schema, the description is comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% description coverage for all four parameters. The description adds extra value by clarifying that 'files' can mix formats and cross-file references are resolved, and that 'source' is an optional alternative. It also explains the 'deep' parameter's premium behavior and key requirement, which goes beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool 'Find real ATTACK PATHS in Infrastructure-as-Code' with concrete formats (Terraform, CloudFormation, Kubernetes) and differentiates it from 'a linter.' The verb is specific and the resource is clearly identified, making it distinct from the sibling tool 'diff_attack_paths' by focusing on full attack-path auditing rather than diffing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use it before applying IaC or in a PR to catch breach paths a per-resource linter misses.' It also explicitly excludes its primary alternative ('not a linter') and implies when to use it. However, it does not explicitly mention the sibling tool 'diff_attack_paths' or explain when to prefer this over a diff-based analysis, which would be a stronger guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diff_attack_pathsAInspect

DIFFERENTIAL attack-path analysis for a change to Infrastructure-as-Code — the CI/CD gate. Give it the IaC BEFORE and AFTER a change (e.g. a pull request's base and head trees, each a map of filename→content) and it builds the full resource graph + runs the internet→crown-jewel reachability search on BOTH states, then reports exactly what the change did to your attack surface: which breach chains it INTRODUCES (e.g. 'this PR opens a NEW Internet→admin route via a newly-public security group + an over-broad IAM grant'), which it ELIMINATES, and which it AGGRAVATES (makes more exploitable). Returns an INTRODUCES_BREACH / REDUCES_RISK / NEUTRAL / MIXED verdict — the single check to wire into PR review so a change that opens a path to your data/secrets/admin is caught before merge. This is something a per-file linter or a single-state scan cannot answer: it needs both graphs and a semantic cross-state path match. Heuristic static analysis of declared IaC.

ParametersJSON Schema

Name	Required	Description
`deep`	No	When true, runs the PREMIUM deep diff: the full changed chains with per-hop file:line evidence, before→after exploitability scores, and which choke points newly matter. Requires CLOUD_PATHFINDER_KEY; without one you get unlock instructions. The free diff verdict + counts need no key.
`after`	Yes	The IaC state AFTER the change (the PR head). Same shape as `before`.
`before`	Yes	The IaC state BEFORE the change (the PR base). Provide { files: {filename: content} } or { source, filename }.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavior disclosure. It accurately describes what the tool does (builds resource graphs, runs reachability searches, reports changes) and includes important limitations like 'Heuristic static analysis of declared IaC.' It also transparently explains the deep parameter's requirement for a CLOUD_PATHFINDER_KEY and the free tier behavior. It does not explicitly state it has no side effects, but as an analysis tool this is well implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured paragraph that leads with the core purpose, then explains the input shape, process, output verdict, and use case. While it is relatively long, every sentence adds valuable information for a complex tool. It is front-loaded with the key differentiator ('DIFFERENTIAL') and remains focused, earning a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the absence of an output schema, and no annotations, the description is impressively complete. It covers inputs (before/after IaC), the analytical process (graph building, reachability search), outputs (introduces/eliminates/aggravates, verdict types, deep-mode evidence), and usage context (PR gate). It also notes the heuristic nature and key requirements, leaving few gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains 'before' and 'after' as PR base and head trees with filename→content mapping, and clarifies the deep parameter's premium behavior (requires key, free version still yields verdict and counts). This enhances the schema's brief descriptions, justifying a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'DIFFERENTIAL attack-path analysis for a change to Infrastructure-as-Code' with a specific goal: reporting introduced, eliminated, and aggravated breach chains. It is specific about the verb, resource, and output verdict. However, it does not explicitly differentiate from the sibling tool 'audit_iac_attack_paths', so it misses the explicit sibling distinction that would warrant a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'the CI/CD gate', 'PR review', and explicitly contrasts it with 'a per-file linter or a single-state scan'. It states that this tool is needed for changes because it requires both graphs and semantic cross-state path matching. However, it does not mention when not to use it or compare directly with the sibling tool, so it lacks explicit exclusions/alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.1.0Aug 2, 2026
- First observedaudit_iac_attack_paths
- First observeddiff_attack_paths

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct task: audit_iac_attack_paths performs a single-state static scan, while diff_attack_paths analyzes changes between two states. Their descriptions clearly separate use cases (pre-apply/PR vs. CI/CD gate), leaving no ambiguity.

Naming Consistency5/5

Both tool names follow the verb_noun pattern (audit_attack_paths, diff_attack_paths) with a consistent suffix. The inclusion of 'iac' in one name is a minor, non-disruptive variation that still aligns with the overall naming scheme.

Tool Count3/5

With only two tools, the set feels minimal, but each tool is essential and non-redundant for the server's narrow purpose of IaC attack-path analysis. The count is at the borderline of what is considered appropriate.

Completeness5/5

The two tools cover the complete lifecycle: a static snapshot audit and a differential change analysis. No obvious gaps exist, as both core operations for the domain are represented and no dead ends are apparent.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
111
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
VerifyMCP A
io.verifymcp
Independent trust scores, tool surfaces and change history for MCP servers.
91
Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2

Related MCP Servers

mcp-tfstate-reader
Cloud Platforms Security
berkayildi
A
license
Not graded
quality
C
maintenance
A local MCP server that parses Terraform .tfstate files and lets AI agents audit enterprise infrastructure for security misconfigurations without requiring direct cloud credentials.
Updated 6 months ago (2026-03-14 15:48 UTC)
MIT
aegis
Security Code Analysis Penetration Testing
cognis-digital
F
license
Not graded
quality
B
maintenance
MCP server for auditing AI agent permissions and access by scanning for the trifecta of credentials, injection, and reach without heavy infrastructure.
Updated 8 days ago (2026-08-29 10:45 UTC)
-
mcp-audit-server
Security Penetration Testing
joepangallo
A
license
Not graded
quality
A
maintenance
This MCP server enables security auditing for MCP configurations and AI agents, including prompt injection testing, data flow tracing, and security policy generation.
Updated 13 days ago (2026-08-23 23:59 UTC)
485
MIT
pathhound-mcp
Penetration Testing Databases
iabdullah215
A
license
Not graded
quality
C
maintenance
An MCP server that enables LLMs to query and reason over Active Directory attack graphs collected by BloodHound, providing attack paths, blast radius analysis, choke points, and defender remediation advice.
Updated 2 months ago (2026-07-07 11:50 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Baneado98/cloud-pathfinder'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

cloud-pathfinder 🛰️

🔐 Privacy & data model (read this first)

⚡ How it works (30 seconds)

🆚 Why this isn't a linter (and why a local one can't replace it)

🚀 Quickstart — add it to your MCP client

Tool: audit_iac_attack_paths

Example — input → output

Tool: diff_attack_paths — the CI/CD gate

Free HTTP API

SARIF 2.1.0 → GitHub code scanning

💳 Unlock /pro — two ways to pay (dual-pay)

What it catches (selected)

How it stays honest

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mcp-tfstate-reader

aegis

mcp-audit-server

pathhound-mcp

Latest Blog Posts

MCP directory API

Tool: `audit_iac_attack_paths`

Tool: `diff_attack_paths` — the CI/CD gate

💳 Unlock `/pro` — two ways to pay (dual-pay)