LockSpec

LockSpec

Provides AI coding agents with accurate OpenAPI contract details to prevent hallucinated API calls, supporting multi-version pinning, endpoint discovery, and request validation.

Category
访问服务器

README

LockSpec

Your AI coding agent writes code that calls your API, but it guesses parts of the contract that it can't see and doesn't know about. It invents field names, calls paths that don't exist, and gets the types wrong. LockSpec is an MCP server that gives the agent the real contract from your OpenAPI spec. When the agent needs an endpoint signature or a type, it gets the exact shape your API accepts.

Most API context tools for agents cover public libraries. LockSpec is for any API that you have a spec for, regardless of whether it's private, internal, or a third party's.

v1 supports OpenAPI 3.0 and 3.1.

Why

You might ask why the agent can't just read the spec from your repo. This works fine in many cases. But if you're working with a spec that the agent can't access (because it's not in the repo, or because it's too large to fit into context), the agent can't get accurate information about the contract it needs to fulfill. You might also want the agent pinned to a specific spec version you choose, not whatever is currently the latest version in the repo. LockSpec loads the spec you provide, indexes it, and serves answers from a pinned snapshot that you control. It returns only the slice that the agent asked for, so an agent can ground the code it writes in the actual contract rather than hallucinating it.

LockSpec can also help agents prevent API version skew. Suppose prod runs v1, a few services already moved to v2, and both are live. You want the agent to write against the right one the first time around. Writing against the wrong one breaks tests, or worse, ships a broken call. With LockSpec, you can load multiple versions of the same API spec at once. You control which one the agent uses. When more than one version of a spec is loaded, the tools that feed code-writing stop before writing code to ask which version should be used. The agent commits to a version on purpose instead of using the one that it saw most recently.

When the agent has a draft request, validate_call checks it against the pinned spec and reports any structural problems it finds. It's a check that catches structural mistakes in the draft before they fail tests and burn extra turns.

Install

Requires Node 22 or newer. Your MCP client runs it through npx:

npx lockspec

From source

git clone https://github.com/LockSpec/lockspec.git
cd lockspec
npm install
npm run build      # compiles TypeScript to dist/
node dist/index.js # starts the server over stdio

Connect your agent

LockSpec runs locally over stdio. Point your MCP client at the lockspec command:

{
  "mcpServers": {
    "lockspec": { "command": "npx", "args": ["lockspec"] }
  }
}
  • Claude Code: claude mcp add lockspec -- npx lockspec
  • Gemini CLI: gemini mcp add lockspec npx lockspec
  • Codex: codex mcp add lockspec -- npx lockspec
  • Cursor: add the block above to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global).
  • Cline / Windsurf: add the block above to the client's MCP settings (cline_mcp_settings.json for Cline).

To run from a source checkout instead of npm, point command/args at the built entrypoint:

{
  "mcpServers": {
    "lockspec": { "command": "node", "args": ["/absolute/path/to/lockspec/dist/index.js"] }
  }
}

The tools

Tool What it does
load_spec Ingest an OpenAPI file, URL, or text; normalize, index, and pin a version.
find_endpoint Find operations by intent or by exact path/operationId.
find_type Find named schemas and types.
get_signature Exact request and response shape: params, required fields, types.
validate_call Structurally validate a draft request against the spec and report what's wrong.
list_specs What's loaded, and which version is active.
activate_version Switch the active (pinned) version.
remove_spec Remove a spec or a single version.
diff_versions Structural diff of two versions, classified breaking or non-breaking.

How it works

load_spec fetches a spec once, normalizes it (bundles external $refs, reconciles 3.0 and 3.1), hashes the result to use as the version's identity, and stores it under ~/.lockspec/. After that everything is pinned and offline. Your specs never leave your machine.

Multiple specs, and multiple versions of one spec, coexist and are queried independently. Each spec has one active version, used when you don't name one. When more than one version is loaded, get_signature and validate_call won't guess. They return an error asking you to pin a version. find_endpoint and find_type use the active version and tell you which one they used.

Examples

Discovering an operation

find_endpoint scores and ranks operations by intent, returning the match or matches the agent will work with.

find_endpoint({ query: "create" })

<!-- demo:find_endpoint -->

{
  "ok": true,
  "spec_id": "petstore",
  "version_id": "sv_f403f8b0c4465bd7db52a4cd",
  "results": [
    {
      "operation_key": "POST:/pets",
      "operation_id": "createPet",
      "summary": "Create a pet"
    }
  ],
  "truncated": false
}

Reading the operation's request shape

get_signature returns the exact request body schema: required fields, types, and allowed values.

get_signature({ operation_id: "createPet" })

<!-- demo:get_signature -->

{
  "ok": true,
  "spec_id": "petstore",
  "version_id": "sv_f403f8b0c4465bd7db52a4cd",
  "operation_key": "POST:/pets",
  "method": "POST",
  "path": "/pets",
  "operation_id": "createPet",
  "summary": "Create a pet",
  "deprecated": false,
  "parameters": [],
  "responses": {
    "201": {
      "description": "Created",
      "content": {
        "application/json": {
          "schema": "…"
        }
      }
    }
  },
  "truncated_paths": [],
  "requestBody": {
    "required": true,
    "content": {
      "application/json": {
        "schema": {
          "type": "object",
          "required": ["id", "name"],
          "examples": [
            {
              "id": 1,
              "name": "Rex",
              "status": "available"
            }
          ],
          "properties": {
            "id": {
              "type": "integer"
            },
            "name": {
              "type": "string"
            },
            "tag": {
              "type": ["string", "null"]
            },
            "weight": {
              "type": "number",
              "exclusiveMinimum": 0
            },
            "status": {
              "type": "string",
              "enum": ["available", "pending", "sold"]
            }
          }
        }
      }
    }
  }
}

Confirming a correct draft

A structurally valid draft body returns valid: true with no errors.

validate_call({ operation_id: "createPet", request: { body: { id: 1, name: "Rex" } } })

<!-- demo:validate_call_pass -->

{
  "ok": true,
  "valid": true,
  "spec_id": "petstore",
  "version_id": "sv_f403f8b0c4465bd7db52a4cd",
  "operation_key": "POST:/pets",
  "errors": [],
  "warnings": []
}

Validating a draft request

validate_call collects all structural violations in one pass. Missing required fields, type mismatches, enum failures:

validate_call({ operation_id: "createPet", request: { body: { id: "1", status: "unknown" } } })

<!-- demo:validate_call -->

{
  "ok": true,
  "valid": false,
  "spec_id": "petstore",
  "version_id": "sv_f403f8b0c4465bd7db52a4cd",
  "operation_key": "POST:/pets",
  "errors": [
    {
      "location": "body",
      "pointer": "/id",
      "code": "type",
      "message": "Expected integer, got string.",
      "expected": "integer",
      "actual": "string"
    },
    {
      "location": "body",
      "pointer": "/name",
      "code": "required",
      "message": "Missing required property 'name'."
    },
    {
      "location": "body",
      "pointer": "/status",
      "code": "enum",
      "message": "Value is not one of the allowed values [available, pending, sold].",
      "expected": ["available", "pending", "sold"],
      "actual": "unknown"
    }
  ],
  "warnings": []
}

Multiple versions loaded

When two versions of the same spec are loaded, get_signature and validate_call refuse to guess which one you mean:

get_signature({ operation_id: "createInvoice" })

<!-- demo:ambiguous -->

{
  "ok": false,
  "error": {
    "code": "ambiguous",
    "message": "Spec \"billing-api\" has 2 loaded versions (1.0.0, 2.0.0) — pass version (version_id or version_label) to choose one.",
    "details": {
      "loaded_versions": [
        {
          "version_id": "sv_a5a2fdfa11e7038e6eb6b4b1",
          "version_label": "1.0.0",
          "active": false
        },
        {
          "version_id": "sv_bcfbfdc5783f3292208c9dc7",
          "version_label": "2.0.0",
          "active": true
        }
      ]
    }
  }
}

License

Apache-2.0.

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选