Root cause hypothesis
The Jina read_url schema declares url as a union type (per Jina docs):
json{
  "url": {
    "anyOf": [
      {"type": "string", "format": "uri"},
      {"type": "array", "items": {"type": "string", "format": "uri"}}
    ]
  }
}
Jina's docs explicitly note: "Models like Qwen3-Next prefer calling singleton tools with multiple queries in an array. The singleton versions accept either a single string or an array of strings."
Qwen3.6 likely emits the URL as an array, which is valid per the schema. Hermes then double-encodes it on the way out.
Code investigation
In /opt/hermes/model_tools.py (around line 532-539), the argument-coercion loop:
pythonfor key, value in list(args.items()):
    prop_schema = properties.get(key)
    if not prop_schema:
        continue
    expected = prop_schema.get("type")

    # Wrap bare non-list values when the schema declares array.
    # Strings still go through _coerce_value first so JSON-encoded
    # ...
prop_schema.get("type") returns None for anyOf/oneOf schemas (the type lives inside the variants). The coercion logic then takes the wrong branch.
Patch attempted (does NOT fix)
pythonexpected = prop_schema.get("type")
if not expected:
    # Handle anyOf/oneOf schemas where type lives inside variants
    for union_key in ("anyOf", "oneOf"):
        variants = prop_schema.get(union_key)
        if variants:
            expected = [
                v.get("type")
                for v in variants
                if isinstance(v, dict) and v.get("type")
            ]
            break
Result: bug still present. The double-encoding happens elsewhere in the pipeline — probably upstream (parsing of Qwen's tool-call output from --jinja chat-template) or downstream (MCP HTTP request builder). The argument arrives at this coercion loop already malformed.
Suggested investigation areas

Tool-call parsing of model output — where Hermes parses tool calls emitted by the LLM via llama.cpp's --jinja. Look for places where arguments is processed as a string and possibly json.dumps'd a second time.
MCP HTTP tools/call request builder in tools/mcp_tool.py — check whether it calls json.dumps on values that are already JSON-serializable.
anyOf/oneOf schema awareness in model_tools.py — the patch above is necessary but not sufficient.

Why only read_url
Among the 17 Jina tools, read_url is one of the few whose primary parameter uses anyOf: [string, array]. The tools that work (search_web, etc.) likely receive a plain string from the model and take a different (working) coercion branch.
This is consistent with the failure mode: immediate (0.2-0.5s, no timeout), clean validation error from the server (not a 500 or generic failure).
Workarounds
For users hitting this:

Use mcporter via a custom skill that calls the same MCP server via npx mcporter call ... (mcporter's serialization is simpler and works).
Use Jina's HTTP Reader API directly (https://r.jina.ai/{url}) via a Python or bash skill, bypassing MCP.
Switch to a different web-extract provider (Tavily, Firecrawl) that uses Hermes's native web toolset rather than MCP.

Environment

Hermes Agent version: v0.13.0 (2026.5.7) — also reproduced on v0.11.0 (2026.4.23)
OS: Linux (Docker container, base image Debian)
Python: 3.13.5
OpenAI SDK: 2.24.0
Model: Qwen3.6-27B-UD-Q4_K_XL via llama.cpp b9050 with --jinja
Provider type: custom OpenAI-compatible endpoint (http://host.docker.internal:8080)
MCP server: Official Jina AI Remote MCP at https://mcp.jina.ai/v1, HTTP transport
Install method: Docker

Severity
Medium-high. Affects any MCP server with anyOf/oneOf argument schemas. Many community MCP servers use this pattern (especially "single value or list" parameters). Silent failure mode makes it hard to diagnose.
Related

Jina MCP server source & schemas: https://github.com/jina-ai/MCP
Hermes MCP config reference: https://hermes-agent.nousresearch.com/docs/reference/mcp-config-reference
Confirmed not fixed in v0.11 → v0.12 → v0.13 (PRs #19785 and #21204 fixed mcp add but not the serialization issue)

---