Skip to main content
Glama
README.md
# TASIE MCP

TASIE — autonomous SAST + real exploit + human-gated remediation — exposed as an
**MCP app** (NitroStack + NitroCloud), so ChatGPT and other MCP clients can scan
code for vulnerabilities and get proof-carrying remediation.

This Node/TypeScript service is a **thin MCP surface** over the TASIE FastAPI
backend (`demo/backend/`). All detection, live exploitation and patching happens
in the Python engine; this app forwards tool calls over HTTP.

## Architecture

```
ChatGPT / Studio  ──MCP──▶  tasie-mcp (this app)  ──HTTP──▶  TASIE FastAPI backend
                                                              (~90 engines + Docker
                                                               exploit sandbox)
```

The backend URL is `TASIE_API_BASE` (default `http://localhost:8000`).

- **Stateless tools** (`scan_code`, `scan_dependencies`, `detect_frameworks`)
  send the code/manifest inline — they work against any reachable TASIE host.
- **Backend-state tools** (`remediate_file`, `scan_repo`) act on files that live
  on the TASIE host and need the full Docker-enabled deployment.

## Tools

| Tool | Backend route | Needs Docker host | Purpose |
|------|---------------|-------------------|---------|
| `scan_code` | `POST /api/analyze` | no | Static scan of inline source → ranked findings (renders **scan-report** widget) |
| `scan_dependencies` | `POST /api/depscan` | no | SCA over an inline dependency manifest |
| `detect_frameworks` | `POST /api/frameworks` | no | Fingerprint web framework(s) + attack surface |
| `remediate_file` | `POST /api/remediate` | yes | Detect → live-exploit → patch → re-verify a host file |
| `scan_repo` | `POST /api/scan-repo` | yes | Route discovery + scan of a repo on the host |
| `tasie_health` | `GET /health` | no | Backend reachability + which endpoint is wired |

## Setup

```bash
npm install                 # main app
npm --prefix src/widgets install   # widget subpackage (or run `npm run dev`)
cp .env.example .env        # then set TASIE_API_BASE
```

Start the TASIE backend first (from `demo/backend`):

```bash
.venv/Scripts/python.exe -m uvicorn app:app --host 127.0.0.1 --port 8000
```

## Run

```bash
npm run dev        # MCP server (STDIO) + widget dev server (:3001)
```

Then connect in **NitroStudio** → Add Server → Nitro Project → this folder →
Studio App Canvas. Test `scan_code` on the Tools page; the **TASIE Scan Report**
widget renders the findings.

## Deploy (NitroCloud → ChatGPT)

1. Set `TASIE_API_BASE` to a **publicly reachable** TASIE host (a cloud VM/Docker
   host running `demo/backend`). NitroCloud deploys only this Node app — the
   Python engine + exploit sandbox must be hosted separately.
2. In Studio App Canvas: **Link to app / Create Cloud App → Deploy**.
3. In ChatGPT: Settings → Plugins → **Developer mode** (Plus/Pro) → **+** →
   Server URL = `{serviceUrl}/sse` → Create → Connect.

> Cloud builds run on **Node 20** (`engines` pins `20.x`). Local dev on newer
> Node works but test against 20 before deploying.

## Config

| Var | Default | Meaning |
|-----|---------|---------|
| `TASIE_API_BASE` | `http://localhost:8000` | TASIE backend base URL |
| `TASIE_API_KEY` | — | optional bearer token (`Authorization: Bearer …`) |
| `TASIE_TIMEOUT_MS` | `120000` | per-request timeout |

## Notes

- `ctx.logger` only inside tools — `console.*` breaks the STDIO transport.
- Verified end-to-end: `scan_code` on a Flask SQLi sample returns
  `critical / CWE-89 / OWASP A03` from the live backend.

TDQS

A4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct action: framework detection, vulnerability scanning (code, dependencies, repo), remediation, and health checking. No two tools appear to do the same thing, and their descriptions clearly delineate the use cases.

Naming Consistency4/5

Five of six tools follow the verb_noun pattern (detect_frameworks, remediate_file, scan_code, scan_dependencies, scan_repo). The outlier is tasie_health, which uses a noun_health format and breaks the predictable verb-led pattern.

Tool Count5/5

With six tools, the set is well-scoped for a security scanning MCP server. Each tool covers a distinct and necessary capability without redundancy or bloat.

Completeness4/5

The tool surface covers the core workflow: detect frameworks, scan code and dependencies, scan full repos, remediate, and check health. Minor gaps exist (e.g., no tool for managing or re-listing past findings), but no critical dead ends are present.

Maintenance

ActivitySlowing
ResponsivenessNo issues