tasie-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TASIE_API_KEY | No | Optional bearer token for TASIE backend | |
| TASIE_API_BASE | No | TASIE backend base URL | http://localhost:8000 |
| TASIE_TIMEOUT_MS | No | Per-request timeout in milliseconds | 120000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_codeA | Statically scan a source file for security vulnerabilities using TASIE. Returns ranked findings (SQLi, command injection, SSTI, XSS, path traversal, deserialization, and ~90 more classes) with severity, CWE and OWASP tags. Send the code inline — no files need to exist on the server. |
| scan_dependenciesA | Software Composition Analysis: scan a Python dependency manifest (requirements.txt / Pipfile / pyproject) for known-vulnerable packages. Send the manifest text inline. |
| detect_frameworksA | Fingerprint the web framework(s) in a source file (Flask, FastAPI, Django, …) and report where the request-handling attack surface is. Send the code inline. |
| remediate_fileA | Full verified remediation loop on a file already loaded on the TASIE host: detect -> live-exploit in a sandbox -> assemble patch -> re-verify. Requires the full Docker-enabled TASIE deployment (TASIE_API_BASE). Returns the proof and the proposed patch for human review. |
| scan_repoA | Ingest a multi-file repository on the TASIE host: discover routes and scan every module for vulnerabilities. Requires the path to exist on the TASIE backend (full deployment). |
| tasie_healthA | Check that the TASIE backend is reachable and report which endpoint the MCP app is wired to. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Health Checks | Current health status of all registered health checks |
| Scan Report | UI component for Scan Report |
| Widget Examples | Provides metadata and examples for all registered UI widgets |
TDQS
Scored across 6 tools
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.
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.
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.
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.