Skip to main content
Glama
Sign In
sphior-code-mcp

sphior-code-mcp

by Toraastrta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_fix_context

Scan local code for security issues and return deterministic remediation steps, exact locations, and references so an AI agent can review and apply fixes without source transmission.

Instructions

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; also lists the others and one fix must satisfy all. A human must review before merge.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_fix_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoLocal mode only: directory to scan. Omit to scan the directory this server was launched in. Use it to narrow a large repository.
repoNoCloud mode only: repository full_name (owner/repo). Omit for the latest scanned repo.
severityNoFilter to one severity.
findingIdNoA specific finding fingerprint to fix. Omit for all findings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/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 behavioral burden and does well: it states no account is required, that the bundled engine scans the local workspace, that SPHIOR neither generates code nor transmits source, that same-line findings are merged with one fix required to satisfy all, and that a human must review before merge. Gaps remain around whether the tool mutates anything, timeouts/scan duration on large repos, and cloud-mode authentication expectations.

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 purpose and the key constraint (the agent, not the server, applies fixes) are front-loaded, and nearly every sentence adds distinct information. It is dense with several clauses per sentence, which is efficient but slightly reduces scannability.

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

Completeness4/5

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

For a four-parameter, zero-required, no-output-schema tool, the description covers modes, source-privacy behavior, merged findings, and the review gate, so an agent knows enough to call it and act on results. It stops short of describing cloud-mode credentials and how to choose between findingId and a full scan, leaving a small completeness gap.

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

Parameters3/5

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

Schema description coverage is 100%, so each of the four parameters is already documented, and the description adds little per-parameter meaning beyond noting that missing path defaults to the launch directory and that severity narrows results. The mention of the `also` field relates to the merge behavior of findingId but describes output rather than parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a concrete verb+resource ('Scan for security problems') and adds the differentiator that the result is remediation guidance with exact locations. It is clear what the tool returns and that the agent is expected to apply the fix. It does not explicitly contrast with siblings like get_finding or list_findings, which keeps it from 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 Guidelines3/5

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

Usage context is implied through the mode discussion: without SPHIOR_API_KEY it scans the local workspace, and the path/repo parameters let you narrow scope or target a cloud repo. However, there is no explicit 'use this instead of get_finding when...' routing, and no stated ordering relative to list_findings or get_security_summary. The human-review-before-merge note is a useful precondition but is process guidance, not tool selection guidance.

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

Deploy Server

Other Tools