Skip to main content
Glama
vschernoff

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, clients that launch servers through npx generally need "command": "cmd" with "args": ["/c", "npx", "-y", "solhint-mcp"].

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, Claude Code requires cmd /c:

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.

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.

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_ruleB

Explain a known Solhint rule and suggest a correction.

ParametersJSON Schema
NameRequiredDescriptionDefault
ruleIdYesSolhint rule ID

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does add one useful behavioral fact — it only *suggests* a correction rather than applying one, distinguishing it from fix_solidity — but says nothing about whether it requires a config, a network lookup, or how the explanation is returned.

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 tight sentence with the primary action front-loaded and the secondary capability following it. Zero filler.

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 tool this is close to adequate, but with no annotations and no output schema the description should say more about what comes back (explanation text only? code sample? suggested replacement?) and whether an unknown rule errors.

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% for the single ruleId parameter, so the schema already documents it fully. The description adds nothing about rule ID format or lookup behavior, making the baseline 3 appropriate.

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 (explain) and resource (a known Solhint rule), plus a second capability (suggest a correction). This clearly separates it from the lint_* and fix_* siblings, though it never names them explicitly.

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?

No when-to-use or when-not-to-use guidance. The word 'known' faintly implies the rule ID must be valid, but there is no statement about when to reach for this instead of lint_solidity, fix_solidity, or get_config, leaving routing to inference.

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

fix_fileA

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

ParametersJSON Schema
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
Behavior3/5

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

With no annotations, the description carries the burden and does disclose the key safety trait: the default is a non-mutating preview and mutation only occurs with write:true. However it does not say whether saved fixes are reversible, what happens on unfixable files, or how failures are reported.

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 tight sentences with the action front-loaded and the mutate-vs-preview distinction immediately following; nothing is wasted.

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 two-parameter tool with a fully documented schema and no output schema, the description covers action, scope, and the safety-relevant default. Only minor gaps remain, such as behavior when no fixes apply or what the preview returns.

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 both parameters are already documented. The description's 'pass write: true to save it' merely restates the schema's own default note, adding no format or edge-case detail beyond it — the baseline 3.

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?

States a specific verb ('Apply Solhint autofixes') and a specific resource scope ('one Solidity file'), which separates it from the project-wide lint_project and the family of lint_* siblings at a glance.

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?

Explains how to use the tool (preview by default, write:true to save) but gives no guidance on when to choose fix_file over siblings like fix_solidity or lint_file, nor any prerequisite or post-fix verification advice.

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

fix_solidityA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSolidity source code to fix
configNoOptional complete Solhint config object

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the important non-destructive trait (operates on a string, does not touch files) and states the return value, which is genuinely useful. It is silent on what happens with unfixable violations, whether an invalid config errors out, and whether a Solhint config is required or defaulted.

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 tight sentences with zero padding; the primary action and the key non-destructive caveat are front-loaded in that order. Nothing can be removed without losing information.

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?

There is no output schema, but the description explicitly says it returns the corrected source, which covers the return contract. For a 2-parameter tool with full schema coverage the definition is nearly sufficient, with only edge-case failure behavior left undescribed.

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 both parameters (code, config) are already documented in the schema, establishing the baseline of 3. The description restates that the input is a Solidity source string but adds no extra semantics, such as whether config is merged with defaults or which rules apply when it is omitted.

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?

The description names a specific verb (apply Solhint autofixes), a specific resource (a Solidity source string), and the return value (the corrected source). The clause 'Does not touch any file' implicitly disambiguates it from the sibling fix_file, so an agent can select between them without opening schemas.

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 implied rather than stated: the tool is the in-memory counterpart to fix_file, and 'Does not touch any file' hints at that boundary. However, there is no explicit when-to-use/when-not guidance relative to lint_solidity or fix_file, so the agent must infer the routing.

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

get_configB

Read the Solhint config for this server instance project.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. "Read" implies a safe non-mutating call and "this server instance project" clarifies that it resolves the server's configured project rather than the cwd, but it says nothing about failure behavior when no Solhint config exists, caching, precedence resolution, or the shape of the returned data.

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 stating the action and scope with no filler. It is efficient, though its brevity edges into under-specification rather than tightly packing useful detail.

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 tool is simple (no params, no nested objects) and the description covers the core action and scope. With no output schema, however, the agent gets no indication of what the returned config looks like or what happens if the project has no Solhint config, leaving a modest gap for a read tool.

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 schema defines zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies a no-argument call.

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+resource: "Read the Solhint config" with a stated scope of "this server instance project." An agent can distinguish it from the lint/fix/explain siblings since none of them read configuration, though the description never names an alternative explicitly.

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?

No when-to-use or when-not-to-use guidance is given, and no sibling is referenced as an alternative. The only hint is the scope phrase "this server instance project," which implies the call is about inspecting configuration rather than running a lint pass, but that inference is left entirely to the agent.

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

lint_fileB

Lint one Solidity file inside this server instance project.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesPath relative to the project root

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It never states that linting is non-mutating/report-only (fix_file and fix_solidity exist as mutating siblings), nor how results or errors are surfaced for a file outside the project root.

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 the scope constraint ('one Solidity file') stated immediately. Every word earns its place and nothing is padded.

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, non-nested tool with full schema coverage this is close to adequate, but with no output schema and no annotations the description should at least indicate that the call is a read-only analysis returning diagnostics, which it does not.

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% (filePath is documented as 'Path relative to the project root'), so the schema already does the heavy lifting. The description adds nothing about the path parameter beyond reinforcing that the file lives inside the project instance.

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 pairs a specific verb (lint) with a specific resource (one Solidity file), and the phrase 'one ... file' implicitly sets it apart from the whole-project sibling lint_project. However, it never addresses the sibling lint_solidity, so an agent cannot fully resolve which of the two file-level linters to pick.

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 when-to-use guidance, no conditions, and no mention of the alternatives (lint_solidity, lint_project, fix_file). The agent must infer that this is the single-file variant purely from the word 'one'.

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

lint_projectC

Lint Solidity files in this server instance project.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternNoOptional project-relative glob

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the lint is read-only or writes/auto-fixes files (a real ambiguity given fix_solidity and fix_file exist as siblings), what the result contains, or whether any setup is required. Only the project-scoped nature of the operation is conveyed.

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?

One short sentence with the verb front-loaded and no filler; every word serves the scope statement. 'This server instance project' is slightly wordy but not wasteful.

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

Completeness2/5

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

With no annotations and no output schema, the description is the only place an agent could learn behavior, and it omits whether files are modified, what the lint results look like, and what happens when no pattern is supplied. For a lint tool with sibling fix/explain tools, that leaves the agent guessing at the core semantics.

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% and the single 'pattern' parameter is fully documented in the schema as an optional project-relative glob. The description adds no format, default, or matching semantics beyond that, 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?

States a specific verb (Lint) and resource (Solidity files) plus a scope qualifier ('in this server instance project'), which implicitly separates it from the file-level sibling lint_file. It stops short of naming or contrasting with siblings, but an agent can infer project-wide vs. file-level scope from the text.

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 when-to-use guidance, no mention of the alternatives lint_file, lint_solidity, or fix_solidity, and no stated preconditions (e.g., must the project be configured/compiled first). The only hint is the word 'project', which is inference rather than guidance.

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

lint_solidityA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSolidity source code to lint
configNoOptional complete Solhint config object

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does add one genuinely useful trait beyond the schema: that the config falls back to the project's Solhint config rather than being required. However, it never states the nature of the operation (read-only diagnostic), the shape of the lint result (violations, severities), or determinism/latency characteristics.

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 sentence with the action front-loaded and every clause earning its place; no filler or restatement of the title.

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, the description should ideally say something about what a lint returns (errors/warnings list, their format), which it omits entirely. The nested config object is also left unexplicated. It is adequate for a two-parameter diagnostic tool but leaves the result contract unspecified.

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 both parameters are already documented, which sets the baseline at 3. The description adds marginal value by clarifying the fallback semantics of "config" (project config when not supplied), but supplies no details on how a supplied config merges with or replaces the project config.

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?

The description pairs the specific verb "lint" with the specific resource "Solidity source string," and the phrase "source string" cleanly separates it from the file- and project-oriented siblings lint_file and lint_project. An agent can choose correctly without opening any schema.

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 mention of "the project or supplied Solhint config" hints that config is optional and defaults to project settings, but there is no explicit when-to-use statement and no exclusion or routing advice relative to siblings like lint_file or fix_solidity (e.g. that fix_* should be used when the caller wants corrections applied).

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: linting versus fixing, and string versus file versus project scope are explicitly separated. The naming (e.g., lint_solidity vs lint_file, fix_solidity vs fix_file) and descriptions make selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: lint_*, fix_*, explain_rule, get_config. The convention is predictable throughout with no mixed styles.

Tool Count5/5

Seven tools are well-scoped for a Solhint MCP server, covering linting and fixing at multiple scopes plus rule explanation and config reading. No tool feels redundant or extraneous.

Completeness4/5

Core lint and fix operations are covered across source, file, and project scopes, and config reading plus rule explanation are present. Minor gaps exist for listing all available rules and applying autofixes to an entire project, but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers