<@U090ER7JPHA> Please review the pages under the D...
# slackbot-chatter
e
@nutritious-balloon-65098 Please review the pages under the Documentation tab and generate a report (in markdown) for the page that also apply to the Agent Canvas project. There should be several. Do not make any changes; we are simply looking to do a gap analysis so we can better document which pages are related to Agent Canvas functionality. Additionally, if there is functionality in Agent Canvas that is not well documented (like the "Integrations" page on the left nav that provides an MCP directory), please indicate this as well. Docs: https://docs.openhands.dev/ Agent Canvas: https://github.com/OpenHands/agent-canvas
n
I'm on it! Joe Pelletier can track my progress here.
Final Summary I completed the documentation gap analysis you requested, comparing the OpenHands documentation (https://docs.openhands.dev/) with the Agent Canvas project. Deliverable Created File:
/workspace/project/agent-canvas/DOCUMENTATION_GAP_ANALYSIS.md
Request Completion Checklist • ✅ Reviewed all pages under the Documentation tab at docs.openhands.dev • ✅ Generated a markdown report identifying applicable documentation pages • ✅ Identified 14 highly applicable documentation pages (Key Features, LLM Settings, Secrets, MCP, Skills, Prompting Best Practices, Hooks, etc.) • ✅ Identified 4 partially applicable pages (Local Setup, Automations, Integrations) • ✅ Identified 10 not applicable pages (Cloud/Enterprise only) • ✅ Documented undocumented Agent Canvas features, specifically: ◦ MCP Marketplace/Integrations Directory (
/mcp
) - the most significant gap with 50+ pre-configured integrations ◦ Backend Management / Multi-Backend Support ◦ Workspace Management ◦ Onboarding Flow ◦ Verification Settings, Condenser Settings ◦ Environment Variables ◦ npm Package exports ◦ Task Tracker / Planner Tab • ✅ No code changes were made (read-only analysis as requested) Key Finding The MCP Marketplace Directory (labeled "Integrations" in the sidebar navigation) is the most significant undocumented feature. It provides a visual interface for discovering and installing 50+ MCP integrations (GitHub, Slack, Linear, Notion, databases, etc.) that has no coverage in the current OpenHands documentation.
c
Isn't “Integrations” the name for “IntegrationsHub” which is SaaS-only?
e
There's actually a new Integrations page that was recently added to Agent Canvas 🙂 It's an MCP directory + MCP configuration page. I think @wooden-umbrella-84098 may have added it. I think the goal is to provide both an MCP Directory and a separate Integrations Hub down the road. Here's a screenshot, I just noticed it this morning.
c
I think maybe we could avoid using the same name for different functionality. IntegrationsHub is SaaS-only according to the issue Robert posted the other day. I mean, my thinking is also that maybe we could learn from the mess we have today that SaaS functionality should be separated from OpenHands OSS 🤔 I wonder, what exactly would an Integrations Hub down the road imply?
Could we name this one… “MCP”?
e
Yep I agree, there's definitely a name collision here. I don't think we've well thought out the naming yet, or explain the differences clearly. I think the key difference with Integration Hub (SaaS) and the MCP Directory (currently named "Integration" in the nav) is that Integration Hub is available 24/7 and can listen to incoming webhook requests from third-party services. But we need to do a better job here 🙏 Renaming to MCP is a good point. I can create an issue for that. I'm sorry for the for the confusion 🙏
c
Thank you! Nothing to be sorry about, I know everyone is working hard to hash these out. 🤔 I don’t know, listening 24/7 for external services… sounds like event-driven automations to me 😅 but I’m not up to speed with canvas
e
It's a really good point. I think we need to do more explanation here. This is why community feedback is so important 👍 Separately, I uploaded the OpenHands analysis of doc gaps to an ongoing docs issue. Will breakdown the work in a bit.
w
Thanks for the feedback! This is still a WIP. I originally called it MCP, but I'm increasingly thinking Integrations Hub goes OSS and becomes this page. But we can call it MCP for now!
c
I'm increasingly thinking Integrations Hub goes OSS
nod On the other hand... just to note, I was thinking that sooner or later we might want to face the question of an agent identity. Not exactly user identity, agent... I'm not even sure what I mean. 😅 I used separate Slack and GitHub "smolpaws" accounts and that's ok; for OH Cloud automations my thinking went in the direction of "service accounts" but they seemed to me needed for individuals too, not only for orgs... In the sense that I would like to give the agent only some credentials, not all I've ever saved in my settings.
nod 1
💯 1
w
yes 100% agree!
c
Just for people to know: issues related to agent identity can meet crypto. Are we interested in solutions/possibilities/discussions in the area?
w
crypto in the sense of cryptocurrency or cryptography?
c
of cryptocurrency, too
👍 1
at least tangentially
w
I'm not super familiar but I'm curious!
c
cc @limited-student-10747 I'm still not sure if I’m missing something, but please check out this discussion too: could we please name MCPs “MCP”? Otherwise I fear that docs on “Integrations” and understanding on “Integrations” will be messy, because it reuses the same name for a different thing.
l
what’s the different thing?
i think the idea is that an integration is a connection to a different service? the reason why i opened a pr renaming “mcps” to “integrations” is because the integrations don’t necessarily need to be through mcps, they could be through regular openapi apis or webhooks
c
Sorry, does agent-canvas have webhooks? I thought it didn’t
l
Yeah, sorry, this might not be fully described yet, but we do want to add event-driven automations to agent-canvas, fully OSS
All of the information needed to implement this will be in the OpenHands/extensions repo and imported/used by agent-canvas
Then we’ll also have a SaaS integrations hub that will allow org administrators to register integrations that can be used by their org
But the main difference will just be whether there’s org/sso functionality
c
This is a tiny example I’m a bit concerned about. This kind of snippet is in multiple places in the docs. It used to be under the main Documentation tab, even; and I know people have come, started to read - met “oh actually it’s not main OpenHands, it’s on the cloud” over and over - and became unsure what’s supposed to work for them and what isn’t.
l
Yeah, fair enough, i think things are pretty difficult to grok now. Agreed that we’ll have to be careful about this. I like the word integrations to describe an integration, although Claude calls them connectors, which is also good
I’ll think a bit more about this