Skip to content

atlas-vision-mcp v1.1.0

Choose a tag to compare

@QuangThai QuangThai released this 07 Jul 13:28
· 14 commits to main since this release

Atlas Vision MCP v1.1.0

Atlas Vision MCP 1.1.0 expands the Responses API integration surface, improves long-running tool reliability, and gives callers finer control over high-effort image analysis without changing the default lightweight workflow.

Highlights

  • Added Volcengine Ark compatibility for the openai-responses provider, including provider-specific image detail handling and configurable thinking / store request fields.
  • Added per-call reasoning_effort and model overrides to analyze_image, allowing a caller to escalate quality on the same image without reconfiguring the server.
  • Added progress-heartbeat protection for long-running MCP tool calls so compliant clients can keep requests alive beyond the SDK's default 60 second timeout.
  • Added a prebuild safety guard that blocks rebuilding while a live Atlas MCP server is still running from dist/.

Configuration and runtime changes

  • Added VISION_RESPONSES_THINKING, VISION_RESPONSES_EFFORT, and VISION_RESPONSES_STORE.
  • Raised the default VISION_TIMEOUT_MS from 60s to 300s for reasoning-enabled vision calls.
  • Updated cache key scoping so escalated retries do not reuse lower-effort or different-model cached responses.

Correctness fixes included in the merged follow-ups

  • Scoped Volcengine xhigh detail handling to the Responses provider path instead of changing the shared provider mapping globally.
  • Propagated per-call model overrides across Gemini, OpenAI-compatible, Claude, and Responses providers so the MCP tool contract matches runtime behavior.
  • Landed the formatting and import-order fixes required to restore CI cleanliness before release.

Validation

  • pnpm build
  • pnpm lint
  • pnpm typecheck
  • pnpm test (50 files, 460 tests)
  • npm pack --dry-run --json

Notes

Live provider checks such as pnpm test:e2e, pnpm test:golden, and atlas-vision doctor remain maintainer-local because they require valid provider credentials and intentionally consume API spend.