Provides tools for running Biome's formatting, linting, and assist checks on TypeScript and web projects, with structured, compact diagnostics and a searchable cache of Biome documentation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@biome-mcp Run biome check on src and show me the errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for running Biome on TypeScript and web projects with token-efficient output.
biome-mcp gives LLMs direct access to Biome's formatting, linting, and assist checks without shelling out to the CLI. Diagnostic output is parsed structurally and reduced to compact, grouped results before it reaches the model, so long check runs stay readable and cheap.
The server also caches the Biome CLI, configuration, and JavaScript linter documentation and exposes it as searchable resources.
Related MCP server: Code Search MCP
biome_check - Run formatting, linting, and assist checks in one pass
biome_lint - Lint-only diagnostics with an all / error / warning severity filter
biome_format - Verify formatting without modifying files
Structured parsing - json-pretty output avoids fragile parsing of human-readable text
Adaptive aggregation - large result sets include rule/file rollups before flat diagnostics
changed_only - Check only staged, unstaged, and untracked web files (*.ts, *.tsx, *.js, ...)
Documentation cache - Searchable, version-aware cache of Biome docs
Bundled Agent Skill - Install biome-mcp skill into .agents/skills with one command
biome-mcp implements the Model Context Protocol
to expose Biome through read-only tools. Every check tool returns a
CheckResult with compact output text and the underlying exit_code; it
never writes to source files.
Tool | What it runs |
|
|
|
|
|
|
| Search the cached Biome docs |
| Refresh the cached docs from biomejs.dev |
To start the server:
uvx biome-mcpOr from a checkout:
uv run biome-mcpConfigure an MCP client to launch the server in the project directory to check, e.g. for opencode:
{
"mcp": {
"biome-mcp": {
"type": "stdio",
"command": "uvx",
"args": ["biome-mcp"]
}
}
}The server checks the project in its working directory. To target another
directory, set BIOME_MCP_PROJECT_DIR.
Biome is invoked through bunx @biomejs/biome by default. Set
BIOME_MCP_COMMAND_PREFIX to use another project-local invocation (see
docs/configuration.md).
Install the bundled biome skill in a project when the agent client discovers
skills from .agents/skills:
uvx biome-mcp skill install biome --target .The skill directs agents to the server's read-only tools and the cached documentation resources.
Environment variables, all optional:
Variable | Default | Purpose |
|
| Logging level (stderr) |
| server working directory | Project directory to check |
|
| Invocation for Biome; empty string uses binaries from |
| none | Optional per-command timeout in seconds |
|
| Documentation cache location |
See the docs for the full picture:
Architecture - components, request flow, and output processing
Configuration - environment variables and client setup
Tools & resources - complete catalog with signatures
Development - layout, tests, and contributing
This project is built with FastMCP and uv.
uv sync --extra dev
uv run ruff check
uv run ruff format --check
uv run ty check
uv run pytestRun Biome formatting, linting, and assist checks without writing files.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | ||
| changed_only | No |
| Name | Required | Description |
|---|---|---|
| issues | No | |
| output | Yes | |
| fixable | No | |
| warnings | No | |
| exit_code | Yes | |
| saved_tokens | No | |
| savings_percent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, while the description adds the specific scope (formatting, linting, assist) and confirms no files are written. This aligns with the annotations and provides additional behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and a key constraint. Every word earns its place, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary function and non-destructive behavior, and an output schema exists to explain return values. However, the absence of any parameter semantics and explicit guidance relative to sibling tools leaves the overall context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'paths' and 'changed_only' parameters. The agent must infer their meaning solely from the parameter names, which is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Run') and resource ('Biome formatting, linting, and assist checks'), and explicitly states it does not write files. This clearly distinguishes it from sibling tools like biome_format and biome_lint, which focus on individual operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a combined check covering multiple Biome operations, but it does not explicitly state when to prefer biome_check over biome_format or biome_lint, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Biome formatting without modifying files.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | ||
| changed_only | No |
| Name | Required | Description |
|---|---|---|
| issues | No | |
| output | Yes | |
| fixable | No | |
| warnings | No | |
| exit_code | Yes | |
| saved_tokens | No | |
| savings_percent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'without modifying files', reinforcing the read-only nature but without additional behavioral detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded, with no redundant wording. Efficient but could carry more information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no schema description coverage, the description should explain parameter usage and differentiate from sibling tools. Output schema and annotations mitigate some gaps, but the description remains insufficient for full usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no explanation for 'paths' or 'changed_only' parameters, leaving the agent to infer meaning solely from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Check' with resource 'Biome formatting' and specifies 'without modifying files', distinguishing it from mutation tools and aligning with its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use biome_format vs sibling tools like biome_check or biome_lint. The description doesn't mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Biome lint diagnostics without modifying files.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | all | |
| paths | No | ||
| changed_only | No |
| Name | Required | Description |
|---|---|---|
| issues | No | |
| output | Yes | |
| fixable | No | |
| warnings | No | |
| exit_code | Yes | |
| saved_tokens | No | |
| savings_percent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description simply restates the non-modifying behavior. It adds no additional behavioral context such as output format, rate limits, or side effects beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, scannable sentence with zero wasted words. It efficiently communicates the primary action and the read-only safety guarantee.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools and three optional parameters, the description is too sparse. It does not explain how to scope the lint run, what the output contains, or when to prefer this tool over biome_check. The output schema and annotations partially compensate, but important gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not mention the level, paths, or changed_only parameters. An agent must infer meaning from parameter names and defaults, which is insufficient for a three-parameter tool with no other explanatory text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as running Biome lint diagnostics and explicitly states it does not modify files, making the core purpose obvious. However, it does not explicitly distinguish itself from sibling tools like biome_check or biome_format, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus biome_check or biome_format. The read-only nature is implied, but there are no prerequisites, exclusions, or contextual clues to help an agent choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cached Biome documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the search is against 'cached' documentation, implying a local, read-only operation, but it does not elaborate on staleness, caching behavior, or any side effects. The word 'cached' adds some transparency, but the description remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary information. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, a short description might be adequate. However, the lack of query-format guidance and any usage context leaves gaps. It is adequate but could benefit from a note about what the query should contain or that the search is against a local cache.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description contains no additional meaning about the 'query' parameter. It does not clarify what format the query should take (e.g., natural language, keyword, regex) or how to construct effective searches. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and identifies the resource as 'cached Biome documentation', clearly distinguishing it from sibling tools like biome_check, biome_lint, and biome_format. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (searching documentation) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Since the tool's purpose is self-evident from its name and description, it earns an implied-usage score rather than a lower one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the cached Biome documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Refresh' without explaining side effects, whether the operation is destructive, permission requirements, or the effect of the 'force' parameter. The lack of detail leaves the agent guessing about runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose. However, it is so terse that it borders on under-specification, lacking any supporting details that would make it truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter), the description still leaves major gaps: no explanation of when to refresh, what 'force' does, what the operation modifies, or any side effects. The presence of an output schema mitigates return-value ambiguity, but the description is too sparse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'force' parameter at all. The parameter name gives a hint ('force' implies overriding something), but the description adds no meaning beyond the schema, which itself provides no description. The tool fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refresh') and the resource ('cached Biome documentation'). It distinguishes itself from sibling tools that perform code checks, linting, formatting, or search, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. There is no mention of prerequisites, recommended frequency, or scenarios where the cache should be refreshed. The usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: biome_check runs all checks, biome_lint and biome_format focus on specific aspects. The hierarchical overlap (check includes lint/format) is clear from descriptions, so misselection is unlikely. No two tools appear to do the same thing.
Three tools use a biome_ prefix (biome_check, biome_lint, biome_format) while two do not (update_cache, search_documentation). The actions follow a readable verb_noun pattern, but the mixed prefix usage creates inconsistency.
Five tools is well-scoped for a Biome utility server. Each tool serves a clear purpose: three for running checks and two for documentation cache management. No unnecessary bloat or thin coverage.
The server covers the main Biome check categories (format, lint, assist via biome_check) and documentation needs (update and search). Minor gaps exist: no separate assist-only tool or ability to write/fix files, but the read-only design makes this acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Structured web research tool for AI agents: search, fetch and shape web data into the JSON schema…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yriveiro/biome-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
