Feature request: Allow MCP tools for OpenAI (Compatible) provider when the model supports tool calls

DEVONthink Artificial Intelligence
1

Summary

The Chat assistant’s Allow MCP tools option is unavailable (greyed out) when the provider is OpenAI (Compatible), even for models that demonstrably support function/tool calling. Request: enable MCP tools for this provider when the model’s capabilities allow it, like the built-in providers.

Environment

  • DEVONthink 4.4 (Pro), macOS 27.0
  • Provider: OpenAI (Compatible) → local OpenAI-compatible proxy on 127.0.0.1 serving GLM-class models
  • Settings > AI > Chat: “Allow MCP tools” enabled; MCP server running (local, default port)

What works / what doesn’t

Works via OpenAI (Compatible):

  • Regular chat, streaming, reasoning-content stripping (by the proxy)
  • Internal assistant tools — the request body contains the built-in tools (e.g. tool_get_contents, tool_get_property) and the model calls them correctly. So tool calling itself works fine through this provider.
  • get chat capabilities for engine … model … reports tool calls: true and a 1,000,000-token context window for the model.

Not available:

  • The per-chat Allow MCP tools checkbox in the Chat assistant stays disabled for every model offered by this provider (glm-4.5 … glm-5.3, and even a model renamed to a GPT-style name). MCP tools are never included in the tools array of the request.
  • For comparison: with OpenAI directly, MCP tools are available on all GPT models; via OpenRouter they’re available on GPT models but not GLM (consistent with the documented model whitelist).

The what’s new notes for 4.4 say MCP tools require “a model that supports tool calls with a context window of at least 64,000 tokens (currently ChatGPT, Claude, Mistral, Gemini, and Qwen 3.x and Muse Spark via OpenRouter)”. That leaves OpenAI (Compatible) users without MCP tools even when a capable model is behind it — in this case a local proxy that merely forwards to a subscription-based endpoint.

Why this matters

OpenAI (Compatible) is the natural provider for self-hosted or proxied setups (LiteLLM, LM Studio server, one-api-style gateways, vendor-specific proxies). Many of these serve models with solid tool calling (GLM, Qwen, DeepSeek, Llama…). Since DEVONthink already probes model capabilities for this provider (context window, tool calls, vision are cached per model), the information needed to gate MCP tools safely seems to be there.

Suggestion

Enable the Chat assistant’s MCP tools for OpenAI (Compatible) when the known capabilities for the selected model report tool calls = true and context window ≥ 64k — the same criteria the notes describe for the whitelisted providers. If reliability with unknown models is the concern, an opt-in toggle per model would be a good middle ground.

Happy to provide request/response traces from the proxy if useful.

1 Like
2

The OpenAI (compatible) endpoint covers a wide range of models & providers - from the dumbest local models with tiny context windows up to the latest cloud frontier models. Therefore it’s currently limited by the lowest common denominator. And in addition to the context window and support for tool calls there are additional requirements, e.g. support for vision tool call results (not probed) and tool call reliability (usually getting worse in case of local models after every tool call cycle).

However, we’ll consider this for future releases. But the next release will enable supports for MCP tools & skills via LM Studio as support for vision tool call results has been recently added.

2 Likes