Skip to main content
Glama
Sign In
solhint-mcp

solhint-mcp

by vschernoff
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

solhint-mcp

Lint and autofix Solidity smart contracts with Solhint, from any MCP client — Claude Code, OpenAI Codex, Cursor, Windsurf, Claude Desktop, and anything else that speaks the protocol. Nothing in it is specific to one vendor.

Your agent gets seven tools: lint_solidity, lint_file, lint_project, fix_solidity, fix_file, explain_rule and get_config.

Solhint's CLI points users at this package — protofire/solhint#801, shipped in Solhint 6.2.5.

Installation

Add this to your MCP client's configuration, with the Solidity project as the working directory:

{
  "mcpServers": {
    "solhint": {
      "command": "npx",
      "args": ["-y", "solhint-mcp"]
    }
  }
}

Requires Node.js 20 or newer. On native Windows, a client that cannot start the server may need "command": "cmd" with "args": ["/c", "npx", "-y", "solhint-mcp"]: Node cannot spawn npx.cmd directly without a shell.

One server process lints one project: its working directory is the project root, so start another process for a different project. A Solhint installed in that project takes precedence over the copy bundled here.

The server calls Solhint through its JavaScript API. It does not start a shell, invoke npx solhint, make update checks, or parse CLI output.

Client-specific shortcuts

Claude Code — from the Solidity project directory:

claude mcp add solhint -- npx -y solhint-mcp

The default local scope associates the server with the current project. Use --scope project before -- if the configuration should be committed in .mcp.json. On native Windows, if the server fails to start, wrapping npx in cmd /c is the usual fix — Node cannot spawn npx.cmd directly without a shell:

claude mcp add solhint -- cmd /c npx -y solhint-mcp

OpenAI Codex — Codex uses TOML, not the JSON block above, and shares one configuration across the Codex CLI, the ChatGPT desktop app and the IDE extension. From the Solidity project directory:

codex mcp add solhint -- npx -y solhint-mcp

Or add it by hand to ~/.codex/config.toml, or to .codex/config.toml to scope it to one project:

[mcp_servers.solhint]
command = "npx"
args = ["-y", "solhint-mcp"]

Cursor / Windsurf — add the JSON block above to the editor's MCP settings.

Claude Desktop — installation is separate from Claude Code. This package is a stdio npm server, not a packaged Desktop Extension (.mcpb). Configure it as a local development MCP server only if the client launches it with the Solidity project as its working directory. See Anthropic's current local-server instructions.

Related MCP server: glintefy

Tools

Tool

Input

Description

lint_solidity

{ code, config? }

Lint a Solidity source string

lint_file

{ filePath }

Lint one .sol file inside the project

lint_project

{ pattern? }

Lint a project-relative glob

fix_solidity

{ code, config? }

Autofix a Solidity source string

fix_file

{ filePath, write? }

Autofix one .sol file

explain_rule

{ ruleId }

Explain any rule the linter ships

get_config

{}

Show the project's Solhint config

lint_project autodetects contracts/**/*.sol, then src/**/*.sol, and finally **/*.sol. Paths and patterns outside the project root are rejected.

The optional config argument accepts rule maps and the built-in solhint:recommended and solhint:all presets. It does not accept an extends path, a shareable config package name, or plugins: Solhint loads those with require, so honouring them from a tool argument would let anything able to call the tool run code in the server process. Declare them in the project's own .solhint.json, which carries the same trust as running npx solhint in that directory.

Run health

Solhint reports a plugin it cannot load, or a rule id it does not recognise, as a warning and then lints anyway — checking less than the project asked for. A tool result that showed only the findings would be read as a clean pass over a broken config.

Those warnings are captured and reported above the findings instead:

⚠️ This run was degraded — Solhint checked less than the project asked for.
- Could not load solhint-plugin-foo, make sure it's installed and exports valid rules. Ignoring it.
- Rule 'no-such-rule' doesn't exist

Treat the result below as incomplete until this is fixed. A finding that is absent may
only mean the rule never ran.

get_config provokes the same diagnostics with a throwaway lint, since Solhint only emits them when it loads rules, and get_config is where someone looks to find out whether the config is sound.

The fix_* tools apply Solhint's own autofixes and then re-lint, so what they report as remaining is what is genuinely left rather than the pre-fix report. fix_solidity returns the corrected source and touches nothing on disk. fix_file previews by default and only writes when called with write: true — Solhint's CLI asks for a backup before --fix, and an MCP client should not rewrite someone's contracts without being asked either.

explain_rule reads the documentation Solhint ships with each rule, so it covers the whole registry and always describes the version this project runs: description, category, default severity, configurable options, notes and the good/bad examples when the rule defines them.

If your repository already documents a lint command

An agent follows an explicit instruction in your repository over a tool description. If AGENTS.md, CLAUDE.md, .cursorrules or a similar agent playbook says how to lint, for example:

- Solidity lint: `npm run lint:sol`

the agent will run that command and never reach for these tools. That is reasonable behaviour, not a misconfiguration, but it means the server goes unused until you say it is there. Mention it alongside the command:

- Solidity lint: prefer the `solhint` MCP tools (`lint_file`, `lint_project`,
  `fix_file`, `explain_rule`, `get_config`) when that server is configured; they run this project's
  own Solhint with its config. Fall back to `npm run lint:sol` when the server is
  unavailable.

The two are complementary. The command is what a person and CI run. The tools are what an agent runs, and their advantage is that the invocation cannot drift: no unquoted ** collapsing to a single level, no forgotten config, no stray flag. A shell glob written by hand can silently cover a fraction of a project; lint_project cannot.

Configuration

lint_solidity uses configuration in this order:

  1. The complete config object supplied to the tool.

  2. The configuration found in the project root.

  3. { "extends": "solhint:recommended" }.

An explicit config replaces the project config; it is not merged. File and project linting use Solhint's per-file configuration hierarchy and the same recommended fallback when no configuration exists.

The server prefers a compatible solhint (>=6.1.0 <7.0.0) installed by the project. If none exists, it uses its bundled, tested version. An installed but incompatible project version produces an explicit error. Pass --bundled-solhint only when you intentionally want the bundled version.

Solhint 6.0.x is excluded because its plugin loader can terminate the host process when a configured plugin cannot be loaded, which is unsafe for an in-process MCP server.

Protocol and current limitations

The server uses @modelcontextprotocol/server 2.x over stdio. It supports the current 2026-07-28 lifecycle and the SDK's legacy compatibility path.

Solhint currently resolves shareable configs and plugins relative to process.cwd(). That is why this release supports one project per process. A third-party plugin that writes to stdout synchronously is redirected to stderr while linting so it cannot corrupt the MCP channel. Full plugin isolation, cancellation, and lint timeouts are deferred to a worker-based release.

Docker

docker build -t solhint-mcp .
docker run -i --rm -v "$PWD":/project solhint-mcp

The server lints whatever directory it starts in, so the Solidity project is mounted at /project, which is the image's working directory. -i is required because the server speaks MCP over stdio; no port is exposed. A Solhint installed in the mounted project takes precedence over the image's own copy.

MCP Registry

Listed as io.github.vschernoff/solhint-mcp. server.json in this repository is the registry manifest; its name must stay identical to mcpName in package.json, and both version fields must match the published npm version, or a registry publish is rejected.

Related

  • solhint-mcp-plugin — this server as a Claude Code plugin. One command installs and configures it, and it adds a skill so the agent lints Solidity without being asked: /plugin install solhint --marketplace vschernoff/solhint-mcp-plugin

  • solidity-ai-kit — a wider setup that configures several Solidity tools for an agent at once, with this server as its linting component.

  • Solhint — the linter itself, maintained by Protofire. This package depends on it; it is not part of it.

Credits and licence

MIT. The linting runner, tool surface and test suite are Diego Bale's (@dbale-arg) implementation, used here with his agreement under MIT. See NOTICE for the file-level breakdown.

Solhint is maintained by Protofire. This package depends on it; it is not part of it.

Available Tools

7 tools
explain_ruleA
Read-onlyIdempotent

Explain a known Solhint rule and suggest a correction.

NameRequiredDescriptionDefault
ruleIdYesSolhint rule ID

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that the response includes a suggested correction, which is useful behavioral context, but says nothing about error behavior for unrecognized rule IDs or whether the suggestion is advisory only (not applied).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler; the primary action and the secondary output are both front-loaded.

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 single-parameter, read-only lookup tool with full schema coverage and rich annotations, the description covers purpose and output shape adequately. The only real gap is the absence of guidance on invalid/unknown rule IDs, which matters because the tool only works on 'known' rules.

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?

Single parameter with 100% schema description coverage, so baseline is 3. The description's 'known' qualifier adds the only semantic signal beyond the schema — that the ID should reference an existing Solhint rule — but gives no format hints (e.g. plugin-prefixed IDs).

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?

States a specific verb+resource ('Explain a known Solhint rule') plus a second concrete output ('suggest a correction'), which is more informative than the title alone. It does not explicitly contrast itself with the lint_*/fix_* siblings, so an agent must infer that this is the only explanatory, non-linting tool.

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 is only implied: the word 'known' hints that the rule ID must be a real Solhint rule, and the tool is naturally a follow-up to a lint finding. There is no explicit statement of when to use this instead of fix_solidity/fix_file or what to do when the rule ID is unknown.

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

fix_fileA
DestructiveIdempotent

Apply Solhint autofixes to one Solidity file. Previews the result by default; pass write: true to save it.

NameRequiredDescriptionDefault
writeNoWrite the fixed source back to the file. Defaults to false (preview only).
filePathYesPath relative to the project root

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description usefully qualifies that risk by explaining the default is a non-writing preview and only write:true mutates on disk — context the annotations alone cannot convey. It stops short of saying what is overwritten, which Solhint config/rules apply, or whether unrelated formatting is touched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero padding, with the primary action first and the safety-relevant default/write distinction immediately after. Every clause carries information an agent needs.

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 2-parameter tool with no output schema and annotations that already cover safety, the essentials (what it fixes, preview-by-default, write opt-in) are present. The main remaining gap is what the preview actually returns, which matters for deciding whether to follow up with write:true.

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 coverage is 100% and both parameters are documented, including the write default, so the description's "pass write: true to save it" is largely a restatement. Baseline 3 applies since the schema does the heavy lifting and no extra syntax or constraint detail is added.

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?

"Apply Solhint autofixes to one Solidity file" names a specific verb (autofix), a specific engine (Solhint), and a scope (one file). It does not distinguish itself from the sibling fix_solidity, so an agent must guess between the two by name alone.

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?

It clearly states the default mode (preview) and the opt-in flag for persistence, which is genuine invocation guidance. However, it never says when to prefer this over fix_solidity, or whether to run lint_file/lint_solidity first, which is the more consequential routing decision.

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

fix_solidityA
Read-onlyIdempotent

Apply Solhint autofixes to a Solidity source string and return the corrected source. Does not touch any file.

NameRequiredDescriptionDefault
codeYesSolidity source code to fix
configNoOptional complete Solhint config object

TDQS

A4.5/5.0
Behavior4/5

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

While annotations cover readOnlyHint and destructiveHint, the description adds the key behavioral constraint that the operation is memory/string-based rather than filesystem-based. This is important context for a modification tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is extremely concise. Every sentence is direct, active, and serves to define the tool's scope or function without filler.

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?

With 100% schema coverage and annotations clearly defining safety and constraints, the description effectively wraps the functionality, leaving no critical gaps for an agent to successfully invoke the tool.

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?

The schema coverage is 100%, establishing a baseline of 3. The description does add context by specifying that the output will be the 'corrected source,' clarifying the outcome of the input parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

It uses a specific action (Apply Solhint autofixes) on a specific resource (Solidity source string). It clearly distinguishes itself from 'lint_solidity' and file-based tools like 'fix_file'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description provides an explicit operational boundary: it works on source strings and 'Does not touch any file,' which is a critical piece of usage guidance for an agent.

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

get_configA
Read-onlyIdempotent

Read the Solhint config for this server instance project.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered without the description's help. The description adds only the scoping detail that the config is per server-instance project; it says nothing about return shape, defaults, or fallback when no config exists.

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?

A single front-loaded sentence with no filler. It is efficient but minimal to the point that it could have absorbed one more clause about the returned config without bloat.

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

Completeness3/5

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

With no output schema and no annotations about the response, the description leaves the return format unspecified (structured rule set vs. raw config text, and what happens if no config is present). For a zero-parameter read tool this is acceptable but not complete.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. Nothing in the description incorrectly implies inputs exist.

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?

States a specific verb (Read) and resource (the Solhint config) scoped to 'this server instance project', which is unambiguous. No sibling tool reads config, so overlap risk is low, but the description never explicitly contrasts itself with the lint/fix family.

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 is only implied: an agent can infer this is the tool to call when it needs to inspect the current Solhint configuration before or after linting. There is no explicit when-to-use statement or precondition (e.g., that a project must be loaded first).

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

lint_fileB
Read-onlyIdempotent

Lint one Solidity file inside this server instance project.

NameRequiredDescriptionDefault
filePathYesPath relative to the project root

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds one useful constraint (the file must reside within this server instance project), but says nothing about what diagnostics are produced or how failures are surfaced.

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?

A single sentence with zero waste and the scope qualifier front-loaded. It is efficient, though extremely terse relative to the routing problem among similarly named siblings.

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

Completeness3/5

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

For a one-parameter read-only lint operation with rich annotations, the essentials are present. With no output schema, however, the description could have stated what a lint run returns (diagnostics list, counts) and it never disambiguates file-level from project-level linting.

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 coverage is 100% and the schema already documents filePath as 'Path relative to the project root'. The description only reinforces the project-internal constraint without adding format or edge-case detail, so the baseline of 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?

Specific verb and resource: lint one Solidity file, with the scope narrowed to 'inside this server instance project'. The singular 'one ... file' implicitly contrasts with the sibling lint_project, but no sibling is named explicitly.

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 is only implied by the 'one file'/'inside this project' scope; there is no explicit when-to-use or when-not-to-use guidance, and the close siblings lint_solidity and lint_project are never referenced to route the agent.

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

lint_projectC
Read-onlyIdempotent

Lint Solidity files in this server instance project.

NameRequiredDescriptionDefault
patternNoOptional project-relative glob

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's contribution is the scoping detail that linting is confined to the server instance's project (no arbitrary paths), which is useful but not much beyond the annotation set; it says nothing about output, report format, or whether it also auto-fixes.

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?

A single short sentence with the scope qualifier front-loaded; nothing is wasted. It is perhaps too terse for a tool with five similar siblings, but structurally sound.

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

Completeness3/5

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

With a complete schema and rich annotations, the description only needs to add routing and scoping, and it partially does so via "this server instance project." Fleet context (lint_solidity, lint_file, fix_solidity, fix_file) means an agent still lacks the cues to select this tool confidently.

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 the single optional `pattern` glob is already documented inline as a project-relative glob. The description adds no extra meaning about the parameter (e.g., what happens when omitted, glob syntax support), so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (lint Solidity files) plus a scope ("in this server instance project"), which hints at a project-wide sweep. However, it never distinguishes itself from the near-identical siblings lint_solidity and lint_file, so an agent cannot tell which lint variant to choose from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this versus lint_solidity or lint_file, and no mention of prerequisites. The only implied usage signal is the phrase "in this server instance project," which the agent must interpret as project-scoped rather than file-scoped.

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

lint_solidityA
Read-onlyIdempotent

Lint a Solidity source string with the project or supplied Solhint config.

NameRequiredDescriptionDefault
codeYesSolidity source code to lint
configNoOptional complete Solhint config object

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by note that the config falls back to the project's Solhint config when not supplied, but it says nothing about what findings are returned or how they are reported, which matters since there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler; the scope (source string) and the config fallback are both packed in.

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

Completeness3/5

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

The call itself is fully specified: what to pass, what happens without config, and that it is a safe read. The remaining gap is the return value, since no output schema exists and the description never hints at the diagnostics shape.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning to the optional config parameter by clarifying that omitting it uses the project config rather than producing an error or empty rule set.

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?

States a specific verb ('Lint') and resource ('Solidity source string'), which implicitly separates it from lint_file and lint_project, which operate on files and projects. It does not name those siblings, so the differentiation is inferred rather than explicit.

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?

The phrase 'source string' implies use when code is in memory rather than on disk, but the description never says when to prefer lint_file or lint_project, nor any prerequisites. Usage is implied, not stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv0.1.3
    • First observedexplain_rule
    • First observedfix_file
    • First observedfix_solidity
    • First observedget_config
    • First observedlint_file
    • First observedlint_project
    • First observedlint_solidity
Deploy Server
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Tools are cleanly split along two axes: action (lint vs fix) and target (source string, single file, project), plus explain_rule and get_config which are clearly unique. The main potential confusion is lint_file vs lint_project, but descriptions clarify scope (one file vs all files).

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: lint_*, fix_*, explain_rule, get_config. The target suffixes (solidity/file/project) are used predictably across lint_* and fix_* pairs.

Tool Count5/5

Seven tools is well-scoped for a Solidity linter, covering lint, fix, rule explanation, and config reading without redundancy. Each tool earns its place.

Completeness4/5

The surface covers linting (string/file/project), autofixing (string/file), rule explanation, and config reading. A project-wide fix (fix_project) and a way to list available rules are minor gaps, but core workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers