sphior-code-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPHIOR_DEBUG | No | Verbose logs to standard error. Off by default. | |
| SPHIOR_API_KEY | No | Optional. Connects to your SPHIOR account to enable the account tools (list_findings, get_finding, get_security_summary, resolve_finding, mark_false_positive, verify_evidence). Keys start with sk_live_. The local scan never contacts SPHIOR's servers in either mode. | |
| SPHIOR_TIMEOUT | No | Scan or request timeout in ms (1000–300000). Default: 30000. | |
| SPHIOR_API_BASE | No | Override the account API endpoint. Default: https://sphior.com/api/v1 | |
| SPHIOR_WORKSPACE | No | Directory to scan. Defaults to the directory the client started in. |
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 |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_findingsA | List security vulnerabilities (SAST + SCA) detected by SPHIOR CODE across the user's GitHub repositories. Use this when the user asks about security issues, vulnerabilities, or CVEs in their code. Returns up to 100 findings ordered by detection date (newest first). |
| get_findingA | Fetch full details of a single security finding by ID — includes CVSS score, CWE classification, exact file path and line number, vulnerability message, and fix hint. Use when the user wants to investigate a specific issue from list_findings. |
| get_security_summaryA | Get the user's overall security posture: counts by severity, last scan time, and number of monitored repos. Use this when the user wants a high-level overview of their security health. |
| resolve_findingA | Mark a finding as resolved (e.g., after applying a fix). Use only when the vulnerability has actually been remediated. For false positives, use mark_false_positive instead. |
| mark_false_positiveA | Mark a finding as a false positive (the reported vulnerability is not actually exploitable). Use this when the AI's detection is incorrect for a specific code context. |
| health_checkA | Report the server's mode and reachability. Works with no account: without SPHIOR_API_KEY it confirms local mode and lists which tools are usable. With a key it also returns the current security summary. Use this to debug connection issues. |
| get_fix_contextA | Scan for security problems and get deterministic remediation guidance so YOU (the AI agent) can fix them. Works with no account: without SPHIOR_API_KEY it scans the local workspace with the bundled engine. SPHIOR does not generate code or transmit source — open the referenced file in your workspace, read the code yourself, and apply the fix. Returns why-it-matters, remediation steps, exact location, and references. Findings at the same line are merged into one entry; |
| verify_evidenceA | Independently verify SPHIOR's tamper-evident code evidence chain (Merkle root + hash-chain + commit anchor). Confirms the deterministic scan records were not altered — for auditors. No source code is returned. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The tools mostly target distinct actions: listing findings, fetching one finding, summarizing posture, changing status, health checking, getting fix context, and verifying evidence. The main overlap is between list_findings and get_fix_context, both of which surface vulnerabilities, though the descriptions differentiate read-only listing from scan-and-remediate guidance.
Most names follow a consistent snake_case verb_noun pattern: list_findings, get_finding, resolve_finding, mark_false_positive, get_fix_context, verify_evidence. The exception is health_check, which is a noun phrase rather than a verb-led tool name, but the overall convention is still predictable.
Eight tools is well-scoped for a security findings server. Each tool maps to a meaningful operation across listing, investigation, remediation, triage, auditing, and diagnostics, without obvious filler.
The server covers the core vulnerability lifecycle: listing, detail inspection, summary posture, resolution and false-positive triage, remediation context, evidence verification, and health diagnostics. Minor gaps remain, such as no explicit tool to trigger or manage remote scans, no repo/monitored-repository listing beyond summary counts, and no reopening or status-history operation.