Skip to content

Add support for "object" type parameters in tool manifests #321

@komatsuna4747

Description

@komatsuna4747

Prerequisites

What are you trying to do that currently feels hard or impossible?

I'm using toolbox-core v0.4.0.
When loading the looker-query tool (or other tools that declare parameters with type: "object"), the toolbox client raises a ValueError during initialization.

Example manifest

sources:
  my-looker-source:
    kind: looker
    base_url: http://looker.example.com
    client_id: ${LOOKER_CLIENT_ID}
    client_secret: ${LOOKER_CLIENT_SECRET}
    verify_ssl: true
    timeout: 600s
tools:
  execute_query:
    kind: looker-query
    source: my-looker-source
    description: |
      Executes a query against the Looker instance and returns the results.
toolsets:
  my-looker-toolset:
    - execute_query

Code to reproduce

from toolbox_core import ToolboxSyncClient
client = ToolboxSyncClient("http://127.0.0.1:5000")
tools = client.load_toolset("my-looker-toolset")

Error

ValueError: Unsupported schema type: object

Looker queries often require a filters dictionary with dynamic key-value pairs. Without native support for the "object" type, users must resort to workarounds like JSON-encoded strings or key-value arrays, which compromise type safety and developer experience.

Suggested Solution(s)

Extend the type mapping in protocol.py to handle "object" types by mapping them to Python's dict type, similar to how "array" types are currently handled.

def __get_type(self) -> Type:
base_type: Type
if self.type == "string":
base_type = str
elif self.type == "integer":
base_type = int
elif self.type == "float":
base_type = float
elif self.type == "boolean":
base_type = bool
elif self.type == "array":
if self.items is None:
raise Exception("Unexpected value: type is 'list' but items is None")
base_type = list[self.items.__get_type()] # type: ignore
else:
raise ValueError(f"Unsupported schema type: {self.type}")

If the "object" type was intentionally omitted from the supported types for specific reasons, please let me know so I can better understand the design constraints and explore alternative solutions.

Alternatives Considered

No response

Additional Details

No response

Metadata

Metadata

Assignees

Labels

priority: p0Highest priority. Critical issue. P0 implies highest priority.type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions