Feedback

[wrynearson]

I've shared this feedback with @yellowcap, but adding here so @ciaransweet and others can see. Opening this as a single ticket since discussions aren't enabled for this repo. Feel free to ignore, ticket them, or ask me to ticket them out.

1. A skill to help people author tools or port existing ones might help with onboarding. Maybe it was an issue with Montandon, but it’s taken many attempts to get LLMs to set up the repo correctly, and now to port over existing tools to output information into state.
2. Would a versioned repo make sense in addition to versioned tool(set)s?
3. We could be a bit more opinionated and have a plug-and-play interface with a map, if we want to focus on geospatial applications. Not sure if we do, but most of our work involves geospatial data
4. Add a brief into to the top of the readme in https://github.com/developmentseed/mcp-toolsets and https://github.com/developmentseed/mcp-toolsets-runtime to say why before what.
5. If I remember correctly, the docs say to not use the AG-UI on production (it should be local dev only). I think it’d be valuable to have this ship with an interface (see point 3) that also (subtly?) shows when state or generation was used. The provenance and "receipts" angle is very strong and compelling here – we should make that a first-class citizen in the UI

[ciaransweet]

Thanks for these @wrynearson! I'll try put my 2 cents on after I've picked kiddo up from school!

[ciaransweet]

Okay!

For starters/context, I would say this repo isn't the deployed service/thing that we should be using to point people to as an actual 'hey look at this cool DevSeed agent + tools' (Not that I think it currently is anyway)

It is an example of how to take toolsets written with the runtime and deploy them, with a full ci/cd workflow, reconciliation of services running, and an Index service that something like: https://reference.langchain.com/python/langchain-mcp-adapters/client/MultiServerMCPClient can connect to and connect an agent to multiple MCP servers at once.

Pre-amble out of the way 😄

---

1. Totally agree, out of interest @wrynearson what LLM are you using to do this porting? I know at least @yellowcap has had fairly good success with Claude (I assume Opus in this case). Which might be a symptom of Claude having written a lot of this, so it might be biased in how it documents things.
   Regardless, I definitely think a skill specifically for agents to consume to point them in the right places is needed.

2. Would a versioned repo make sense in addition to versioned tool(set)s? - Can you elaborate on what you mean here, just so I can answer this better?

3. and 5 - The AGUI example in the -runtime repo is just an example (currently). I agree though, this repo can definitely have it as the chat interface, over streamlit. As to the map, we can certainly modify the example UI to have a map as a focus too. What I might argue against is this repo being heavy on spatial. The main purpose of this repo is to show examples of how to deploy these mcp services to best utilise what the runtime provides. I think what we really want, is to rename this to something like mcp-toolsets-deployment-examples (or something better) and then have an actual instantiation of this repo (it's a template repo afterall) that is the DevSeed public agent.

4. Yep, agreed, no further comments 😅

[ciaransweet]

@wrynearson @yellowcap I added #30 and #31 to track the current actionable things.

[wrynearson]

Thanks for your thoughtful and quick response @ciaransweet, and for letting me barge in here and just open a ticket titled Feedback... 🙈

this repo isn't the deployed service/thing that we should be using to point people to as an actual 'hey look at this cool DevSeed agent + tools'

I think I have the same understanding, but I think mixed up where I should put the feedback. I'll state my understanding below to make sure:

1. https://github.com/developmentseed/mcp-toolsets-runtime is the actual library
2. https://github.com/developmentseed/mcp-toolsets is the scaffold where you can drop in a folder of LangChain tools and get an MCP server up and running.

From that, I think we have three different goals (not sure which of the three we want to go after/prioritize):

1. Reuse this architecture (langchain tools + provenance + POC UIs) on our agentic applications. Not reinventing the wheel each time.
2. Help other folks expose their data on their infra, using our runtime (and probably example mcp-toolsets repo). The eoAPI analogy.
3. Publish an MCP server ('hey look at this cool DevSeed agent + tools'). The agentic geo product, or "the DevSeed public agent"

---

out of interest @wrynearson what LLM are you using to do this porting?

Claude Sonnet 5

Would a versioned repo make sense in addition to versioned tool(set)s?

Nevermind, I see https://github.com/developmentseed/mcp-toolsets-runtime/releases now, which I think covers what I was thinking (that people to update the various pieces of what we're offering in mcp-toolsets-runtime (the state management, the UI, etc.)

---

Overall (from what I understand), I think this approach is very nice and powerful. I think making it as easy as possible for people to (1) see the data provenance/state piece in action, and (2) see how they could port it to make the data they care about accessible, would make this a very compelling package.

[ciaransweet]

Nice, yes I agree with all you said!

I think in terms of the goals, priority would probably be 1 and 3 shared, 2 after.

1 is in progress, the CDS agent is based on the runtime + the deployment repo, with the Digital Twin Assistant potentially moving over to it/using it for more mcp tools.

2 is a bit blurry in that I think we need some people to offer that to (though I'm not terribly swatted up on the business pipeline)

3 is definitely something we've been working towards - @yellowcap has been working on porting https://developmentseed.org/geo-assistant/ and other goodies over.

[yellowcap]

Thanks for all this great input and discussion! 💪🏽 x 💪🏽 indeed!

Agree with what is said here, I would add though that I think with some more polish we can get the default UI work pretty much out of the box for the default agent and api. I would emphasize the MCP views a bit more, and do some polish around how thigns are presented. I dont think it needs much to become easier to understand and thus even more educational.