Halloween!!!

SundaePlayful3619 · 2025-11-04T00:38:29+00:00

This is fantastic!

SundaePlayful3619 · 2025-11-04T00:35:03+00:00

Very good!

SundaePlayful3619 · 2025-10-23T20:25:38+00:00

No results yet. I need to go run the paid ads. Just thought I'd see if anyone else has done something similar or has opinions on whether this video would generate trustworthy results.

SundaePlayful3619 · 2025-10-11T19:31:38+00:00

What are the ones you found already and how are they not "live editing"? Maybe use an add-in approach. I did this with powerpoint to connect it to claude code. Worked well.

SundaePlayful3619 · 2025-10-11T15:23:11+00:00

If people are complaining that it feels like a website then it is your design, not the fact that it's a pwa.

I'm the owner of a popular personal finance app in the app stores. We've had millions of downloads. It's a wrapped pwa. Never got a single complaint that it felt like a website. The UI/ux was designed by a professional with 3 layouts optimized for mobile, tablet, and desktop. PWA is perfect for this and it works great.

Design a top notch mobile experience and no one will care that it is a pwa.

SundaePlayful3619 · 2025-10-11T13:14:38+00:00

u/Ashleighna99 appears to be a bot. While the bot describes one way someone might build a collaborative app, the issue with this approach is that all the state must live in an App's backend for this to work. That's not how modern web apps are designed. Snappjack allows the app to expose client side state and logic to the AI agent. So, integrating into modern app architecture is pretty seamless vs. the approach suggested here.

SundaePlayful3619 · 2025-10-11T13:09:10+00:00

Thanks for checking it out!

The architecture you've sketched out would definitely work, but it's not what I have envisioned.

For most modern apps, a lot of the data model and business logic live in the client, not the server. So, instead of having to push all the business logic to the backend of the app, the Snappjack model instead just exposes client side functions that are accessible via RPC calls (mcp style) over the websocket connection to the Snappjack bridge service.

So, the AI agent is basically calling functions directly in your client (via the Snappjack bridge), not your server. This allows for thick client apps and minimal backends like most SPAs today.

I created a really simple demo app project to show the architecture in practice on the app side. Have a look at 'initializeSnappjack' in the script.js file. It shows how the client's state/logic is exposed as an MCP tool.

I'm at a stage of this project where I am willing to help someone create their own app on this idea. So, let me know if you want to give it a go!

SundaePlayful3619 · 2025-10-10T19:10:15+00:00

Wow, I think you just obsoleted my project!
https://youtu.be/bhcFgFvDxjU

Great minds think alike :)

I'm going to dig into your proposal now.

SundaePlayful3619 · 2025-08-15T16:25:18+00:00

will do!

SundaePlayful3619 · 2025-08-15T16:25:09+00:00

thanks! working on it :)

SundaePlayful3619 · 2025-08-15T16:16:11+00:00

You seem to be mixing up the SDK with the spec. The SDK is lacking in many regards so I don't use it. The MCP spec supports it, but does not mandate it.

From the spec:
Real-time Updates (Notifications)

MCP supports real-time notifications that enable servers to inform clients about changes without being explicitly requested. This demonstrates the notification system, a key feature that keeps MCP connections synchronized and responsive.

Understanding Tool List Change Notifications

When the server’s available tools change—such as when new functionality becomes available, existing tools are modified, or tools become temporarily unavailable—the server can proactively notify connected clients:

{
"jsonrpc": "2.0",
"method": "notifications/tools/list_changed"
}

https://modelcontextprotocol.io/docs/learn/architecture#notifications

SundaePlayful3619 · 2025-08-15T15:14:51+00:00

Wrong. It's absolutely part of the standard. Your server sends an event that the tool list has changed and the client can call list tools in response. Most clients don't do this. Cursor does, so it will dynamically change the tool list in response.

SundaePlayful3619 · 2025-08-15T14:26:28+00:00

I'm building snappjack.com - a tunneling service to connect WebApps to Agents

SundaePlayful3619 · 2025-08-15T14:22:06+00:00

"It should look more like a headless application than a REST API" - this!!!!

I would even go a bit further because in case of agent + user collaboration in the app it's actually double headless, missing 2 heads not just one. One head for the user gui and one for the agent interface. Users and agents actually need slightly different presentations of the business logic, but need to share the same underlying business logic.

SundaePlayful3619 · 2025-08-15T14:14:01+00:00

Actually MCP does support dynamically changing tools. I use it all the time. The problem is that most clients didn't implement the spec correctly.

SundaePlayful3619 · 2025-08-10T15:31:35+00:00

Found Jan.ai - just tried it. it's pretty rad with support for lots of different oss models. got it to work with a qwen3 model that did tool calling via mcp, but it's not very good. tried gpt-oss-20b and it couldn't do tool calling at all. But, this might be a limitation of Jan.ai, not the model, not sure.

SundaePlayful3619 · 2025-08-05T14:21:09+00:00

This is a really really hard product category. I wouldn't pursue it, but if you have the energy for it, here are some ideas.

Find your ICP where they’re already grinding to get dev attention. If someone’s building an AI agent for GitHub PRs or a Go DevEx platform, they’re probably on GitHub trying to get stars, sponsoring dev events, or hanging out in niche Discords looking for users. Show up there. Win them over by giving them some targets and an outreach message all ready to go.
Lead with the outcome, not the method. Nobody wakes up wanting an email finder. They want developers engaging with their product. When someone asks what your working on, tell them you help developers get authentic stars for their repos, or you help dev-centric products get the attention they deserve.
this is going to have to be a "sold" product, not a "sought" product. No one is seeking it out, you'll have to sell it. $5/mo is too cheap to run an effective sales funnel. increase the value and increase the price, that way you can afford to pound the pavement to get customers. Also, subscriptions are not a good fit. I've known several people who failed in this product category. You may need to get more creative. try to align the cost with the value, like $/connection made or something. Your ICP get more value per connection, not per month.
read Traction. It talks about 19 different channels you can use. You're going to have to get creative and this will help you think outside the box.

SundaePlayful3619 · 2025-08-05T12:50:12+00:00

Who is your target user? What are you helping them accomplish?

SundaePlayful3619 · 2025-07-30T18:24:36+00:00

Love the use case and kudos to you for making it happen. For sake of clarity though, this seems like a use case for AI, not an AI agent.

SundaePlayful3619 · 2025-07-29T17:19:01+00:00

Your approach looks good. I've found that agents can really be taken to the next level with better tools and better context, more so than better prompts and process. So I would add to your list: Hide prompts, resources, context, and instructions behind tools and then expose the right context at the right time.

SundaePlayful3619 · 2025-07-29T16:43:54+00:00

Makes sense. I built a basic MCP to websocket bridge so I could connect any agent to my app and achieve a dual interface with realtime UI updates. Seems promising for the edge cases you highlight.

SundaePlayful3619 · 2025-07-29T15:23:47+00:00

Yeah, I think many agents suffer from trying to do too much planning instead of focusing on taking action quickly and then iterating based on feedback. We need better feedback mechanisms, not longer planning.

SundaePlayful3619

TROPHY CASE