Dataset with JSON property results in build_spec_error

[davidebbo]

In my very simplified repro, I have an app with the following dataset:

The app itself is trivial, with just an INPUT block that uses this dataset:

I then have an agent that uses this app. When trying to use the agent, I consistently get:

ERROR: Failed to build the specification for action pynkiTnxhr, (code: build_spec_error)

I've fiddled with it in various ways, and the presence of the JSON prop is definitely what triggers it. My test app is dXi49W8WCQ (I can give you the whole URL, but not sure if sharing the workspace ID is in any way sensitive).

[albandum]

I've moved this community card to eng-runner. Not the first time someone tells us JSON format is broken in Dust apps - maybe the mitigation is just to remove the possibility to pick it?
wdyt @spolu ?

[davidebbo]

The obvious workaround is to use a string arg to hold the json instead of a JSON arg. The challenge is that as it stands, if you have a string type arg and you enter a string that happens to be valid JSON, it automatically changes the type back to JSON when you Update.

Though presumably, if you remove JSON type arguments support, that would no longer happen.

[spolu]

Yes JSON input is unsupported for agents. This is a known limitations due to the fact that we have no good place to put the JSON spec to define what JSON we want even if front does support now JSON specs to define full inputs.

This was a shortcut that I took as I plugged Dust apps as actions of agents.

One immediate fix would be to add a warning message when JSON is selected in the dataset view saying that this is not supported when used as action for agents.

From there we could work on adding the ability to define a JSON spec here (very related to what @frankaloia has been working on). It all depends on much we believe in the future of dust apps as agent actions of course.

[davidebbo]

This is a known limitations due to the fact that we have no good place to put the JSON spec to define what JSON we want even if front does support now JSON specs to define full inputs.

@spolu FWIW, in my scenario as well as in this other user's, the JSON is not schematized and could be anything.

Here is what I ended up doing in the curl's body block to work around the problem:

function fixUpJSONString(s) {
    // HACK: If it starts with a backquote, remove it. This is an arbitrary character that can be prepended
    // in the dataset sample data to prevent it from being treated as JSON (which is broken)
    if (s.startsWith('`')) {
        s = s.slice(1);
    }

    // Convert it to an object, since we have to use a string prop to get around the JSON issue
    return JSON.parse(s);
}

_fun = (env) => {
  return JSON.stringify({
    data: fixUpJSONString(env.state.INPUT.data)
  });
}

[spolu]

Yep in that case the workaround is to describe the input as a JSON object but type it as a string and fix up the world in code. With a good description of the input + instructions in the agent that should work but this is obv not perfect.

@davidebbo We're working on supporting MCP servers to expose new actions to Dust. If you're interested we can definitely feature flag you in very soon?

[davidebbo]

@davidebbo We're working on supporting MCP servers to expose new actions to Dust. If you're interested we can definitely feature flag you in very soon?

@spolu sure, that'd be great! Right now, I'm playing around with my own MCP integration to see how far I can get, but it's more of a hack than a solution :)

[spolu]

cc @Fraggle ^

[Nosrob]

Hello, I also faced the exact problem described in this issue, thank you @davidebbo for the proposed workaround I finally managed to achieve my goals even if it's not ideal.
Would it be possible to activate the feature flag for the MCP servers on my workspace as well? I really want to see if it can help me unlock certain use-cases 🙏🏼

[davidebbo]

@fontanierh adding the warning is a small step forward, but the problem is that the UI forces you into using JSON whether you want it or not.

From observation, the way it works is that if the first sample data value of a string type property happens to be valid JSON, the property type gets auto-changed to JSON when you click Update.

My suggestion is to just remove this logic for now, and let users who want a JSON prop choose that type explicitely. WDYT?

PS: @Fraggle when can we hope to get the MCP feature flag? 😃

[spolu]

@davidebbo agreed that this is a minor step for now. This is a known limitation and our upcoming (in preview) MCP server integration should cover most needs related to extending agents.

The big question is what is the future of Dust apps. ATM Dust as a platform would surely benefit from seeing them removed to reduce the product surface and complexity 👍

[davidebbo]

@spolu I'm a big fan of MCP, and I got to try the Preview, which worked well (thanks @Fraggle for adding me!).

That being said, I don't see this as being a full replacement for Apps, and in particular for the curl block. How would we then call out to all the various web services out there that are not MCP? Though I'm sure I'm missing some context on the grand plan 😄