Skip to content

call_tool passes object-valued query params straight to aiohttp, raising an unhandled TypeError instead of JSON-encoding them #107

Description

@AmirF194

Split off from #106. cubic-dev-ai flagged that a content-form query parameter (application/json) loses its serialization metadata in the generated tool schema, I fixed that on the converter side, but there's a matching gap one layer down that #106 doesn't touch.

HttpCommunicationProtocol.call_tool builds query_params = remaining_args (http_communication_protocol.py:322) and hands it straight to aiohttp's params=. aiohttp only accepts str/int/float, or a sequence for repeated params, as a query value, so any object- or array-typed argument raises a TypeError before the request is even sent. The except Exception block at the end of call_tool logs and re-raises it as-is, so a caller sees a raw TypeError instead of a normal tool-call error.

Repro against current main (6b4f364), calling HttpCommunicationProtocol.call_tool directly with tool_args={"filter": {"status": "open"}} against a plain GET template:

TypeError: Invalid variable type: value should be str, int or float, got {'status': 'open'} of type <class 'dict'>

A fix needs to special-case list values (aiohttp already turns those into repeated ?k=v1&k=v2 params correctly) and JSON-encode everything else, the same split #106 makes on the schema side. Happy to send a PR for this if useful.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions