Community MCP — Trusted AI for Real Communities

Trusted AI for real communities, governed by people.

Comment

Inspiration

We didn't start with an AI chatbot looking for a problem. We started with a real community and responsibilities that mattered.

Chandaikona M. L. High School in Bangladesh is preparing to celebrate its centenary. For generations, the school has connected students, teachers, families, and friends. But like many alumni communities, reconnecting former students, sharing reliable information, organizing events, and coordinating support across generations remain difficult.

As a former student, an active member of the alumni community, and a software engineer, I wanted to contribute something meaningful. I had been planning a digital platform for our community, but the opportunity to turn that idea into a working system had not yet arrived.

The Amazon Alexa+ Hackathon became the catalyst.

During the hackathon, I began building GotiHub Alumni, the real community platform, and developed Community MCP as a separate open-source project to explore how conversational AI could connect people to trusted community information and governed actions.

Amazon Bedrock and the Model Context Protocol (MCP) made it possible to approach the problem differently. Instead of relying on AI-generated answers alone, the assistant could retrieve structured information from community systems while respecting authentication, authorization, and human decisions.

A former student might ask about the centenary celebration. Another member might need blood or financial assistance. These situations require more than intelligent conversation—they require accurate information, privacy, consent, and responsible human oversight.

That shaped our central principle: AI should help communities find information and coordinate support, but people must remain in control of sensitive decisions.

Today, GotiHub Alumni is independently deployed for our school community, and Community MCP demonstrates the AI integration through a public simulator and a separate authenticated Alumni assistant.

What began as a commitment to one school has become a broader vision: making trustworthy AI infrastructure accessible to alumni associations, nonprofits, and other community organizations.

Built for one real community. Designed with the potential to serve many. Powered by AI, governed by people.

What it does

Alexa+ track: We built a simulated Alexa+ conversational experience to demonstrate how an assistant can retrieve trusted community information through authenticated MCP tools.

Community MCP connects conversational AI to approved community capabilities through authenticated MCP tools. The public browser simulator demonstrates event discovery and approved assistance context using synthetic data and Amazon Nova Micro through Amazon Bedrock. A separate authenticated integration connects the AI experience to the independently deployed GotiHub Alumni application.

Real community assistance, governed by people

The Alumni platform supports structured requests for blood donation, medical support, family support, financial support, and other community assistance. An eligible member can submit a request, but submission does not make it public.

The approval and visibility workflow is deliberately staged:

  1. Submit: A member describes the help needed and chooses an appropriate audience.
  2. Batch review: A responsible batch representative reviews the request. After approval, it can be shown to authorized members of that batch.
  3. Escalate: If broader help is needed, the batch representative requests wider support from a batch coordinator.
  4. Community-wide visibility: The batch coordinator's approval permits publication across the wider Alumni community.

This is not unrestricted AI automation. Human reviewers determine when sensitive assistance information can be shared and how widely. The platform's dashboard exposes review responsibilities to authorized people; unapproved requests are not listed as active requests for ordinary members.

Blood donation with consent

Blood donation participation is voluntary. The platform's consent settings distinguish willingness to be considered as a donor from permission to receive notifications about relevant requests. Neither means a member has committed to donating blood. Separately, members responding to assistance requests can choose whether to share their contact information. The application returns a responder's phone number to the request creator only after the response is confirmed and contact-sharing consent is recorded. Medical eligibility and compatibility must be confirmed by appropriate healthcare professionals.

The public simulator does not expose private donor records or execute the entire Alumni approval workflow. It demonstrates governed retrieval of approved community context. The real assistance and approval workflow belongs to the separate Alumni platform.

Events and participation

The assistant can retrieve event context through MCP rather than inventing institutional information. The school centenary is the real-world use case; dates and responses shown in the public simulator are synthetic demonstration data, not official school announcements.

How we built it

  • Python 3.12, FastAPI, and MCP: An authenticated Streamable HTTP MCP service exposes structured event and approved assistance context, including get_event_context and get_assistance_context.
  • Amazon Bedrock / Nova Micro: The reasoning layer interprets questions and composes responses using retrieved context. The model does not grant permissions or become the source of institutional truth.
  • RS256 JWT / JWKS: MCP authentication validates issuer, audience, and the required community.read scope.
  • Data-provider separation: A synthetic demo provider enables public evaluation without access to the private Alumni database; a separate controlled provider supports institutional integration.
  • Public simulator: A browser experience communicates with the authenticated MCP service and displays tool activity.
  • Usage controls: SQLite-backed usage records, daily request and token budgets, concurrency limits, and reservations help manage AI consumption. Public and Alumni usage are accounted for separately.
  • Docker and tests: Containerized services, deployment examples, automated tests, and developer documentation make the system reproducible.

Alexa+ track: The browser-based simulated Alexa+ experience demonstrates authenticated community tools and Amazon Bedrock reasoning. Direct Alexa+ integration is part of our future roadmap.

Challenges we ran into

  • Authority versus reasoning: A model can understand a request, but it cannot decide whether someone is entitled to see a private medical or financial assistance record. We separated AI interpretation from deterministic permissions and human approval.
  • Graduated visibility: Assistance needs can start within a single graduating batch and expand to the wider community only after an additional approval. That required more than a single public/private switch.
  • Donor privacy: Willingness to donate, notification preferences, and contact disclosure are different decisions. We designed them as separate consent and authorization concerns, rather than treating every member as a discoverable donor.
  • A safe public demonstration: We wanted to show real architecture without publishing private production information. The synthetic simulator and controlled provider boundary let us do that.
  • Operational costs: Bedrock usage needs measurable limits, not just application logs. We added persistent accounting and budget reservations.

Accomplishments that we're proud of

  • Built Community MCP around a real school community and real assistance requirements, not an invented use case.
  • Delivered authenticated MCP event and assistance context tools with Amazon Bedrock reasoning.
  • Built a separate public simulator that runs on synthetic data.
  • Implemented a human-governed Alumni assistance workflow with batch-level review and an escalation path to community-wide publication.
  • Designed privacy-conscious, voluntary blood donor participation and contact-visibility boundaries.
  • Separated the public hackathon repository from the independently deployed Alumni platform and its private records.
  • Added persistent AI usage accounting, configurable budgets, deployment documentation, and automated tests.

What we learned

Trusted AI is not just about producing a good answer. It's about knowing who is allowed to see information and who is responsible for acting on it.

A helpful assistant must retrieve authoritative information, acknowledge missing details, and respect the organization's approval process. Human governance becomes especially important when the subject is medical, family, or financial assistance. We also learned that demo isolation and cost controls are product features, not afterthoughts.

What's next for Community MCP

We plan to extend Community MCP beyond one school to multiple communities and organizations, each with independent identity, permissions, and approved data providers. Future integrations will use permissioned, documented APIs rather than direct access to private databases.

Our long-term goal is a reusable integration platform for schools, alumni associations, nonprofits, and other membership-based organizations. We see opportunities for managed infrastructure, organization-specific integrations, and developer APIs while preserving each community's control over its data and decisions.

A developer API and documentation portal is planned at mcp.gotihub.com/api; it is not presented as an existing public API. We also plan to expand authorized assistance coordination, operational reporting, and verified integrations with supported voice-assistant platforms, including Alexa+.

One real community today. A reusable foundation for many trusted communities tomorrow.

Built With

Share this project:

Updates

Submission history