Skip to main content
Glama
Sign In
mcp-skylos

mcp-skylos

by duriantaco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

Plan or apply LLM fixes

remediate
Destructive

Plans or applies LLM-generated fixes for Skylos findings in a project, defaulting to dry-run so you can review changes before files are edited.

Instructions

Plan or apply LLM-generated fixes for Skylos findings in a project.

With dry_run=True (default), static analysis returns a remediation plan without calling a model or changing files. With dry_run=False, it generates fixes and can edit files in place: this needs the skylos[llm] extra and provider configuration (including credentials when required), and sends affected code to that provider. It does not run your tests. Review every change and run trusted tests before keeping it. Costs 10 Skylos credits per real run, charged when the run starts generating fixes, right before the first model call; a run that fails after that is still charged. Dry runs, refused calls and runs with nothing to fix are free. Scan tools cost no credits.

Requires SKYLOS_API_KEY: this tool returns an authentication error unless the MCP server is started with SKYLOS_API_KEY set. Without a key only analyze works (5 calls/day). The local CLI needs no key: skylos verify <file> and skylos agent install-hooks.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "remediate"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesDirectory or file to scan. A relative path resolves against the MCP server's working directory.
modelNoLLM model name passed to the provider (e.g. gpt-4.1 or a Claude model). Configure the provider's credentials in the MCP server's environment when required by that provider.gpt-4.1
dry_runNoTrue (default) only plans the fixes. False writes the generated edits to files in `path`.
severityNoOnly fix findings at this severity or above: critical, high, medium or low.
test_cmdNoNot supported over MCP; non-empty values are rejected. Run tests yourself after reviewing the fixes.
max_fixesNoMaximum number of findings to fix in this run.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv4.49.0
    • addedInput schema / properties / dry_run / description
      Added value: +"True (default) only plans the fixes. False writes the generated edits to files in `path`."
    • addedInput schema / properties / max_fixes / description
      Added value: +"Maximum number of findings to fix in this run."
    • addedInput schema / properties / model / description
      Added value: +"LLM model name passed to the provider (e.g. gpt-4.1 or a Claude model). Configure the provider's credentials in the MCP server's environment when required by that provider."
    • addedInput schema / properties / path / description
      Added value: +"Directory or file to scan. A relative path resolves against the MCP server's working directory."
    • addedInput schema / properties / severity / description
      Added value: +"Only fix findings at this severity or above: critical, high, medium or low."
    • addedInput schema / properties / test_cmd / description
      Added value: +"Not supported over MCP; non-empty values are rejected. Run tests yourself after reviewing the fixes."
  2. Addedv4.10.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by explaining that code is sent to an external provider, that files can be edited in place, that tests are NOT run, and that credentials/`skylos[llm]` are required. The credit model is spelled out in unusual detail — 10 credits per real run, charged at first model call, failed runs still charged, dry runs free, scan tools free.

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?

Front-loaded with the plan-vs-apply distinction, then cost and auth, which is the right order for an agent. It is somewhat long and mildly repetitive — 'It does not run your tests' and 'Review every change and run trusted tests' restate the schema's own test_cmd note — but every paragraph carries distinct operational information.

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?

For a destructive, cost-incurring, credential-gated tool, the description covers the things an agent most needs: mutation risk, external data transmission, cost and charging semantics, and the SKYLOS_API_KEY precondition with its failure mode. An output schema exists, so return-value detail is correctly omitted.

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 all six parameters including dry_run, severity and test_cmd are already documented in the schema. The description reinforces dry_run semantics and provider credential needs for `model`, but adds little syntax or behavior the schema does not already carry, so the baseline 3 applies.

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 first sentence names a specific verb and resource — 'Plan or apply LLM-generated fixes for Skylos findings' — and the dry_run distinction makes the two operating modes concrete. It stops short of differentiating from the sibling 'generate_fix', which an agent could plausibly confuse with this tool, so it is clear but not fully sibling-disambiguated.

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?

It gives clear usage context: dry_run=True is the safe planning default, dry_run=False writes files, and it names 'analyze' as the only tool that works without a key. It also offers local CLI alternatives. What it lacks is an explicit rule for when to pick this over 'generate_fix' or 'validate_code_change'.

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