Hi everyone. I’m relatively new to Kling and have been testing it for a few weeks to automate some internal reporting workflows. I was relying pretty heavily on a custom tool-calling function I built to format and push data to our BI tool.
After the latest platform update (I think it was v2.1.3?), that function just stopped working. The agent doesn’t error out, but it completely ignores the tool definition and falls back to a generic response.
My setup is straightforward:
- A Python function decorated with `@tool`
- It expects specific parameters (like `report_date` and `metrics_array`)
- It was registered via the CLI and worked perfectly before the update
Has anyone else run into broken custom tools after this update? I’m trying to figure out if this is:
* A known bug with a workaround
* A change in how tool schemas are now defined
* Something specific to the deployment method
I’m also curious how this compares to other platforms you might have used (like LangChain or even OpenAI’s assistants API) in terms of stability during updates. Do they usually deprecate things with more notice?
What I’ve tried so far:
- Re-registering the tool
- Simplifying the parameter types
- Checking the activity logs (no permissions errors shown)
Any pointers would be really helpful. I’m stuck on a deadline and considering whether to roll back or switch approaches.
Typical. They push an update, break core functionality, and call it a feature. Check the changelog for v2.1.3, they probably quietly changed the schema validation rules. I'd bet your `metrics_array` param type is now considered "invalid" by their new, overly strict parser.
Stability compared to others? They're all bad, but Kling is worse about silent failures. At least LangChain throws a real error you can debug.
Your stack is too complicated.
Totally get the frustration with silent failures, they're a nightmare to debug. You might be onto something about stricter schema validation.
I did spot a note in the changelog about them tightening the parameter type definitions for arrays. Could you try wrapping your `metrics_array` in a Pydantic model with explicit typing? Sometimes that forces the parser to recognize it.
Still, comparing stability to LangChain isn't quite fair - they're built for different levels of control. Kling's abstraction is great until it fails quietly like this. 😕
Raise the signal, lower the noise.
Yeah, the Pydantic wrapper trick can definitely help the schema generation. I've found you sometimes need to be even more explicit with the List type hint now.
Instead of just `metrics_array: list`, try:
```python
from typing import List
from pydantic import BaseModel
class MetricsParams(BaseModel):
values: List[str] # or List[float] etc.
@tool
def push_report(report_date: str, metrics_array: MetricsParams):
# your logic here
```
The stricter parser seems to really want those nested type hints. Silent failures are the worst part of this - the CLI should at least warn you about schema mismatches during registration.
Clean code, happy life
Oh, that Pydantic wrapper example is super helpful. Thanks for writing it out.
So if I'm understanding right, the core issue is that `list` or even `List` alone is too vague now? It needs to know what's *inside* the list, like `List[str]`? That seems... kind of obvious in hindsight, but I can see why the old version let it slide. Silent failures on registration would save a ton of headache.
Quick question about your fix, would using `list[str]` directly in the function signature work the same way, or does it have to be wrapped in a Pydantic model to be recognized?
Yep, you're spot on about the core issue being the vague `list` type. The new parser is demanding to know what's *in* the list.
Great question about `list[str]` directly! It *should* work in theory, but in my testing, I've had mixed results. Sometimes the CLI's schema generator still misses it, especially with more complex nested structures. The Pydantic model just seems to be the most reliable hammer right now.
It's a bit clunky, but until they add proper validation warnings on registration, it's the quickest way to get back up and running. Hope that unblocks you
It's almost certainly the schema definition change. The update tightened validation on container types, and a generic `list` parameter will now be silently dropped from the generated JSON schema. The agent then falls back because it thinks your tool takes zero arguments.
The Pydantic model wrapper others suggested is the fix. For a direct comparison to LangChain, they handle this differently - their `@tool` decorator would throw a validation error at *decorator time*, not fail silently at runtime. It's a trade-off in developer experience.
Have you tried checking the actual schema output from the CLI registration command? You can pipe it to a file. That'll confirm if your `metrics_array` is missing from the final definition.
benchmark or bust