firecrawl / firecrawl/firecrawl-mcp-server
server.json package version appears out of sync with package.json and npm
- Dominant language
- JavaScript
- Stars
- 7.5k
- Forks
- 884
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 14
Description
Hi Firecrawl team,
While testing MCP server release metadata for CI linting, I noticed that the MCP registry metadata in `server.json` appears to be behind the source package and npm package.
Current checks:
```bash
curl -sL https://raw.githubusercontent.com/firecrawl/firecrawl-mcp-server/main/package.json | jq '.version'
npm view firecrawl-mcp version
curl -sL https://raw.githubusercontent.com/firecrawl/firecrawl-mcp-server/main/server.json | jq '{version, packages}'
```
Observed on 2026-05-12:
```text
package.json: 3.15.0
npm firecrawl-mcp: 3.15.0
server.json: 3.7.4
server.json packages[0].version: 3.7.4
```
Relevant files:
- https://github.com/firecrawl/firecrawl-mcp-server/blob/main/package.json
- https://github.com/firecrawl/firecrawl-mcp-server/blob/main/server.json
- https://www.npmjs.com/package/firecrawl-mcp
## Expected
`server.json` should probably be updated as part of the same release workflow as `package.json` and the npm publication, or clearly marked as intentionally pinned/stale.
## Why this matters
MCP clients and registries may use `server.json` as install metadata. If the registry metadata points to an older package version, users and CI scanners can get different behavior than the source repository suggests.
## mcp-lint context
V0 of **mcp-lint** is ready at https://github.com/agentsnative/mcp-lint. It is a CI linter for MCP servers that checks installability, registry/source version consistency, tool schemas, annotations, and high-risk tool configuration. This metadata drift is the kind of release check `mcp-lint` is designed to catch automatically.
Would you be interested in trying the V0 `mcp-lint` report for this repo? I would be happy to run it against the server and share the output in an issue or PR.
Contributor guide
No contributing guide indexed for this repository
Research direction
Compare the version and package fields in package.json and server.json, then review how npm publication and release metadata are handled. Use the curl, jq, and npm view checks from the issue to confirm the current values. Done means server.json is synchronized with the published package or the repository clearly documents why it is intentionally pinned.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- release
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100