Maybe I’m confused. Source/Trigger Components are essentially receivers/syncers for 3rd party events right? Props are how you configure them to do the sync, but the event payload they receive is distinct?
Check out these docs, which give a decent overview (though admittedly a lot of our docs and product are very much framed in a workflow-centric context). Re: schemas and payloads, we don’t right now have the inputs or expected outputs documented.
with the new MCP servers, can you create server urls for end customers thus calling MCP on their behalf? Or how does that work?
Not yet, but that’s coming soon! This initial phase is focused on end users directly, we’re working on publishing our app server code so that you can deploy them to your app or agent and let your customers auth and use those tools.
That’s gonna be wild, quite honestly!
What are you building?
I’m building an agent that makes agents. Will hopefully launch early version in the next few weeks.
Hey, you mentioned models (event/action input) aren’t easily known, but they must be exposed by the MCP servers - that’s kind of the whole point, so that would be interesting to explore further.
Yea, the component definition is exposed to the LLM, and we give it a tool to configure the component as well. The issue I cited is that the initial definition may change depending on the user provided values of dynamic props. This action is a good example of that.
Ohhh, I get you. I see the conundrum. The event payload is as you configured it. Which if you don’t know how you configured it, is hard to extract.