DEV Community: Mindy Jen

Bridging the Rigidity Gap: Deploying Secure Agentic RAG in Healthcare Governance

Mindy Jen — Thu, 04 Jun 2026 22:08:34 +0000

In the healthcare industry, data is both an organization's most valuable asset and its most heavily guarded liability. While industries like e-commerce and retail fast-track generative AI prototypes into production overnight, healthcare operates under strict regulatory constraints.

When healthcare stakeholders try to adopt Retrieval-Augmented Generation (RAG) and autonomous AI agent architectures, they face a frustrating paradox: the clinical front lines demand flexible, intelligent context, while the governance board demands strict, unyielding infrastructure controls.

By analyzing the technical realities of building a secure RAG application with Amazon Bedrock AgentCore and Terraform, we can reveal the deep friction points, operational pain points, and compliance challenges that healthcare organizations must navigate.

1. The Architectural Pain Point: "Flat" Prototypes vs. High-Stakes Clinical Realities

Most generative AI applications start as a proof-of-concept (POC) where an LLM is connected to a single vector database. However, when this flat architecture is introduced to a multi-disciplinary healthcare ecosystem, it fails completely.

The Menace of Prompt Injection and Semantic Collision: In a standard RAG setup, an agent is often given "all-powerful" access to scan documents. In a hospital environment, if a clinical lead asks a chatbot about patient metrics on an inpatient ward, a poorly architected agent can be manipulated or experience a semantic collision—inadvertently leaking restricted human resources documents, financial metrics, or data from separate clinical units.
Context Overload and Hallucination: Healthcare data is sprawling and diverse, ranging from patient-reported experience measures (PREMs) and clinical handovers to localized pharmacy guides. Dumping all this multi-modal information into a single flat repository leads to massive lookup noise. The LLM becomes overwhelmed by irrelevant chatter, increasing the risk of hallucination—a flaw that is minor in retail but potentially dangerous in a clinical setting.

2. The DevSecOps Dilemma: Fragmented Infrastructure and Configuration Drift

Healthcare IT departments are notorious for being risk-averse, and for good reason: an unstable system directly impacts patient care and data accessibility. Deploying a production-grade agentic system requires a complex suite of components, including serverless agent runtimes, multi-modal knowledge bases, identity user pools, and granular access management policies.

The Nightmare of Manual Orchestration: Setting up an AI agent runtime by executing one-off cloud commands works for developers in a sandbox environment. But a week later, it becomes impossible to track if the strict policy engines are still correctly attached to the data gateway.
The Burden of Configuration Drift: Without code-driven automated tracking, manual updates to API gateways, memory resources, or user authorization systems create untraceable infrastructure mutations. In a heavily audited healthcare sector, a single undocumented resource configuration can shut down an entire digital pipeline during a compliance review.

3. The Security Barrier: Zero-Trust Identity and Data Perimeters

Healthcare stakeholders demand an absolute zero-trust framework. The core difficulty lies in translating conversational, fluid AI interactions into rigid, mathematically verifiable security policies.

The Lack of Strict Identity Propagation: When a doctor or executive queries a RAG system, the agent cannot operate using a single master admin key. The system must verify exactly who is asking. If an agent makes downstream tool calls or accesses an S3 storage bucket containing sensitive text files, it must carry that user's specific JSON Web Token (JWT) credentials all the way through the execution pipeline. Integrating these complex identity federation flows across legacy healthcare networks is a major technical hurdle.
The PII and Data Sovereignty Trap: Patient narratives and free-text summaries are heavily restricted. Organizations face severe legal liabilities if any clinical or patient information leaves sovereign cloud boundaries. Any automated RAG pipeline must process and scrub data within strict national perimeters while masking personal details, yet somehow preserve critical routing tokens like specific hospital and ward codes so data can still be directed to the correct local dashboard.

4. Human-In-The-Loop Governance and the "Autonomous" Fear

The final hurdle isn't technological; it is cultural and regulatory. Hospital boards and clinical governance committees are inherently deeply skeptical of autonomous operations.

The Boundary of Automated Inference: Algorithms excel at parsing thousands of documents to surface complex patterns, but they cannot bypass existing human governance. If a RAG application flags an apparent medicine safety issue or an operational failure on an inpatient ward, it cannot automatically execute a systemic change on its own.
The Accountability Void: When an AI agent triggers an API tool call, the legal responsibility remains with the institution. Designing an agent platform that restricts the AI's role to an informational assistant—while providing an immutable, auditable logging trail for every single document retrieval and tool invocation—is a persistent challenge for digital health executives.

The Path Forward: Turning Infrastructure into Code

To overcome these challenges, healthcare organizations must move past fragile, hand-built prototypes. The solution requires decoupling the AI's reasoning from the underlying infrastructure management.

By adopting centralized, hierarchical orchestration platforms—such as Amazon Bedrock AgentCore to run isolated, specialized worker agents under a strict zero-trust policy engine—and codifying the entire structure using Terraform, healthcare enterprise clients can ensure their systems are repeatable, secure, and fully auditable. This approach allows healthcare teams to confidently bridge the gap between unstructured text and structured, compliant clinical value.

Beyond Vibe Coding Trap: Are you still only playing with plain text attempting to solve multi-million dollar "info friction" problems in healthcare?

Mindy Jen — Thu, 04 Jun 2026 17:17:32 +0000

When we analyze the healthcare sector, it appears to be a massive machine running on data. Jurisdictions invest millions in patient-reported experience measures (PREMs) and data collection pipelines, generating vast data lakes filled with valuable free-text clinical insights and customer sentiment.

Yet, beneath this massive volume of data lies a structural failure. Healthcare stakeholders—from front-line ward managers and interdisciplinary discharge teams to executive board members—are drowning in a "plain-text trap." They are forced to manage high-stakes operations using fragmented, text-heavy reports and static dashboards that are detached from real-time workflows.

By synthesizing the operational realities of healthcare governance with the architectural insights of modern Model Context Protocol (MCP) Apps, we can expose the deep friction points plaguing healthcare clients and stakeholders.

1. The Operational Pain Point: High-Level Reporting Meets Localized Blindspots

In healthcare administration, macro-level governance analytics are standard practice. Systems can statistically aggregate thousands of qualitative patient survey text files to present high-level trends. But for a clinical ward manager or a nursing lead, these reports suffer from a fatal flaw: they are too generic to drive local Quality Improvement (QI).

The Problem of Aggregated Variance: A regional dashboard might show that "Wait Times" or "Communication Gaps" are operational bottlenecks across a dozen hospitals. However, the underlying clinical reasons differ drastically between a Surgical ward, an Emergency Department, and a Gynaecology unit.
The "One-Size-Fits-None" Trap: When positive and negative feedback points are flattened into a macro report, the nuance is lost. Clinical teams are left with an awareness that a problem exists, but lack any localized context to apply targeted clinical interventions.

2. The AI & Tech Dilemma: The Fragility of Fragmented Web Apps

To solve this data opacity, healthcare systems are increasingly turning to AI agents and natural language chat interfaces to let staff query clinical insights. For instance, a hospital administrator might ask an AI agent, "What are the main causes of discharge delays on Ward 4B this month?"

However, text-based AI agent chatflows introduce a severe technical challenge known as the external app breakout.

Disruptive Context Switching: Right now, when a text-based AI agent answers a query, the only way to let the user interact with that data (like filtering data by clinical themes or signing off on a protocol) is by forcing them out of the chat context and into an external legacy web application.
The Integration Engineering Tax: For enterprise healthcare developers, forcing users into external systems means wrestling with custom APIs, building redundant authentication layers across strict medical perimeters, and taping together fragile state management systems.

3. User Experience Challenges: Walls of Text and Conversational Fatigue

Healthcare professionals—especially doctors, pharmacists, and nursing leads—operate in high-stress, time-poor environments. When interacting with modern LLM conversational agents, they face severe conversational fatigue.

The Plain-Text Wall: Forcing an emergency doctor or hospital executive to read through massive walls of text, markdown tables, or bulleted descriptions of complex clinical data is fundamentally inefficient.
The Ambiguity of Manual Parsing: If a hospital coordinator needs to schedule staff shifts or log a Plan-Do-Study-Act (PDSA) quality improvement cycle via a chat tool, typing out unstructured text back-and-forth leads to massive parsing errors. Text-based AI chats struggle to efficiently capture specific, structured multi-parameter values (like dates, ward codes, and metric selectors) without multiple iterations.

4. Severe Compliance and Governance Difficulties

No industry faces a more complex web of governance, safety, and privacy mandates than healthcare. Moving toward autonomous AI agent pipelines introduces massive friction with standard operating regulations:

Strict PII Redaction Demands: Clinical records and qualitative patient feedback are riddled with Personally Identifiable Information (PII) like patient names, addresses, Medicare numbers, and phone numbers. Healthcare entities face strict regulatory liabilities if any data leaks past secure perimeters. Yet, any filtering engine must selectively keep key routing tokens unmasked—such as hospital names and ward identifiers—so insights can reach the correct local dashboard.
Sovereign Cloud Data Control: Medical data compliance dictates that no patient records, text files, model inputs, or model outputs may leave national or state sovereign cloud infrastructure.
The "Side-Effect" Liability: In a clinical setting, an AI cannot simply execute an action autonomously—such as registering a medication safety flag or altering a patient care pathway. Doing so without explicit human-in-the-loop clinical governance is a massive legal and operational risk. Every single data shift, clinical approval, and context update requires a transparent, completely auditable paper trail.

Moving Forward: The Interface Transformation

The core problem for healthcare stakeholders isn't a lack of raw data or analytical intelligence—it is an interface failure. To make qualitative data useful at the frontline, healthcare systems must bridge the gap between AI text reasoning and real-world clinical action.

By breaking out of the text-only paradigm and integrating secure, bidirectional interactive tools—such as MCP Apps that render interactive metrics and localized forms directly within a secure chat interface—healthcare organizations can finally empower their staff to move seamlessly from insight to clinical intervention without leaving their secure environments.

Moving from Feedback to Interventions using AI + NLP: A Blueprint for Transforming Patient Insights into Clinical Action

Mindy Jen — Thu, 04 Jun 2026 07:18:16 +0000

The true test of a healthcare data pipeline isn't how gracefully it visualizes problems—it’s how reliably it translates data points into actionable solutions. Having established that traditional high-level governance reporting often obscures localized pain points, the immediate question remains: How do we fix it?

A look behind the curtain of Clinical Excellence Healthcare Provider’s Q1 2026 semantic analysis data shows exactly how healthcare systems can transition from passive surveillance to data-driven, continuous quality improvement (CQI). By utilizing automated analysis tools paired with structured, localized action frameworks, we can effectively address key institutional friction points.

Solution 1: Mitigating Emergency Room Distress via "Real-Time Waiting Communication"

The Pain Point: Long Emergency Department wait times cause deep patient anxiety. However, semantic engines reveal that the real trigger for distress isn't always the capacity wait itself—it’s the "information blackout" patients feel while sitting in the triage room.

The Solution: Rather than waiting on long-term infrastructure overhauls, healthcare leaders can roll out a targeted, Real-Time Waiting Communication Protocol.

The Framework: Piloted using a structured 30-minute proactive update protocol for waiting patients, coupled with real-time ED status board integrations and modernized clear physical signage.
The Proof (Data Signal): In pilot Hospital and Health Services (HHSs) that deployed this communication protocol, negative comments surrounding ED updates dropped significantly from 71% to 53% (a massive -18 percentage point improvement). Meanwhile, comparison hospitals saw stagnant, minimal movement (-2 pp).

Solution 2: Standardizing "Teach-Back" Care Transitions Beyond Medication

The Pain Point: Patients leaving inpatient wards are frequently disoriented regarding medication updates, post-discharge warning signs, and exactly who to call if they take a turn for the worse at home.

The Solution: Deploy a multi-disciplinary Discharge Teach-Back Expansion Protocol.

The Framework: Standardize clinical workflows where discharge coordinators and ward teams don't just hand patients an informational packet; they utilize a formalized "teach-back" validation step. Patients explain back in their own words their understanding of their follow-up care, emergency escalation contacts, and medication updates.
The Proof (Data Signal): Targeted medication reconciliation pilots using this method yielded a dramatic 57% reduction in medication-related red flags. To solve the broader discharge gap, scaling this clinical teach-back strategy to non-medication discharge guidelines can systematically drive down avoidable readmission risks across any medical-surgical unit.

Solution 3: Reclaiming Inpatient Healing Environments with "Night-Time Rest Protocols"

The Pain Point: Constant beeping equipment alarms, loud staff conversations at central desks, and poorly-timed midnight interventions cause sleep deprivation on inpatient wards, directly impacting patient recovery.

The Solution: Enforce a strict, structured ward-level Night-Time Rest and Sleep Bundle.

The Framework: Implement a hard-guided 10 PM to 6 AM protected rest window across inpatient units. This requires clinical teams to execute clustered nursing tasks (reducing non-essential room entries), practice quiet bedside-handover discipline, and engage in telemetry/alarm rationalization to curb sensory overload.
The Proof (Data Signal): Across 41 pilot inpatient wards that rolled out this quiet rest framework, negative patient comments regarding sleep plummeted from 78% to 49% (a stark -29 percentage point shift). Non-participating comparison wards saw virtually no shift, confirming that ward-level operational change yields definitive experience improvements.

Solution 4: Bridging Vulnerabilities via Culturally Stratified Liaison Program Management

The Pain Point: Fragmented communication barriers continue to marginalize access and undermine clinical safety for CALD, Aboriginal, and Torres Strait Islander patient populations.

The Solution: Expand embedded Cultural Liaison Evaluation Frameworks.

The Framework: Integrate proactive cultural liaison outreach directly inside high-risk service loops (such as Emergency Departments or complex Outpatient clinics) instead of relying on standard reactive, check-the-box interpreter requests.
The Proof (Data Signal): Early semantic evaluations tracked an immediate 8 percentage point reduction in negative cultural safety and language friction at pilot sites compared to flatlines at comparison sites, providing clear programmatic justification to continue funding stratified equity programs.

The Infrastructure Enabler: Closed-Loop PDSA Governance Tracking

Behind all of these operational fixes sits a programmatic infrastructure requirement: you cannot fix what you do not track in a closed loop. To successfully provide these solutions, a healthcare system must embed text-analytics platforms directly into a Plan-Do-Study-Act (PDSA) registration cycle.

PLAN: Register intervention (e.g., ED Update Protocol) and tag target themes.
   │
   ▼
  DO: Roll out protocol to designated pilot units.
   │
   ▼
  STUDY: Semantic analysis engine automatically filters subsequent free-text 
         and compares pilot vs. comparison ward sentiment (Pre vs. Post).
   │
   ▼
  ACT: If validated (e.g., -18pp negative shift), deploy statewide adoption guidance.

By connecting qualitative text engines directly to localized PDSA templates, healthcare executives don't just see a static snapshot of what went wrong. They gain an ongoing validation engine that tells them exactly if what they tried is working. This shifts qualitative patient feedback from a standard administrative metric to the ultimate driver of clinical change.

The Macro Failure of "One-Size-Fits-None" Reporting: Why Healthcare Providers Fail to Act on Patient Feedback

Mindy Jen — Thu, 04 Jun 2026 00:36:16 +0000

Every month, healthcare jurisdictions pool millions of dollars into collecting Patient-Reported Experience Measures (PREMs). Millions of text files and survey comments flood central data lakes, yet front-line nursing staff and clinical leads rarely see any change. Why? Because the current system suffers from a classic structural failure: jurisdictional data is too generic to drive local quality improvement.

When high-level governance reporting irons out localized friction, it masks the acute pain points felt at the hospital floor or ward level. Based on real-world semantic data and deployment insights from Clinical Excellence Healthcare Provider (Q1 2026), let's unpack the core stakeholder pain points, system challenges, and friction points across today's healthcare operations.

The Core Pain Points from Patients (The Consumer Stakeholders)

When analyzing massive text datasets via automated inference engines (such as The Clinician’s Q Engine), positive remarks tend to highlight compassionate, respectful staff interactions. However, statistical variance confirms that negative nuances are easily lost in aggregated data. At the patient level, the loudest, most persistent pain points center around operational communication gaps:

The Distress of "The Waiting Room Silence": In Emergency Departments (ED), wait times are a known hurdle. Yet, semantic tracking shows that long waits are exacerbated by an institutional lack of communication. As one patient shared: "I waited over [time] and nobody told us what was happening... the care was good once I was seen, but the silence made it frightening." Uncertainty breeds distress, turning a capacity challenge into an experience failure.
The Discharge Disconnect: Leaving the hospital is a critical care transition, yet it remains highly fragmented. Patients frequently express confusion regarding medication updates, warning signs to watch for, and who to contact if they become unwell post-discharge. They leave feeling medically cleared but informationally stranded.
Environmental Obstacles to Recovery: Inpatient wards are failing to protect fundamental recovery conditions, like sleep. Night-time noise caused by continuous medical equipment alarms, staff conversations, and a lack of quiet bedside-handover discipline severely impacts ward-based rest.
Marginalized Access Barriers: Cultural safety, accessibility, and language support remain significant pain points. Patients from culturally and linguistically diverse (CALD) or Aboriginal and Torres Strait Islander backgrounds often must ask multiple times for basic language help or an interpreter before understanding their immediate care plan.

Operational & Systems Challenges for Healthcare Providers

For hospital executives, ward managers, and clinicians, the problems aren't born out of a lack of empathy; they stem from systems failures:

The Data Aggregation Disconnect: Standard macro reports offer great board-level data but contain virtually zero actionable value for local Quality Improvement (QI). For instance, looking across a macro system, patients might be statistically twice as likely to report positive aspects over negative ones. However, look closer at the ward level: a Surgical ward and a Gynaecology ward can both report issues on "Wait Times," but the underlying clinical context and administrative workflow causing those delays differ wildly.
Cross-Functional Quality Risks: Discharges are interdisciplinary tasks. When post-discharge care falls short, it demands cross-functional alignment across pharmacy departments, ward nurses, and specific discharge programs. If these units operate in isolation, positive inpatient care can immediately deteriorate into avoidable readmission risks.
Clinical Safety Gaps: The sheer volume of incoming free-text data makes it impossible for manual staff review to identify critical red flags instantly. Severe safety issues like medication confusion, medication omissions, and potential infection prevention breaches get buried in stacks of paperwork.

Data Privacy & Governance Difficulties

Implementing automated tools to parse through clinical notes and text feedback brings forth stringent governance and compliance difficulties:

Strict PII Masking Demands: Before any free-text narrative can be pushed to clinical dashboards, it must run through a rigorous data redaction engine. Names, phone numbers, addresses, emails, URNs, and Medicare numbers must be scrubbed automatically. However, engines must keep hospital or Health Service names unmasked to preserve regional routing. Managing this balance without human intervention requires highly fine-tuned orchestration pipelines.
Data Sovereign Compliance: In modern healthcare infrastructure, strict compliance protocols dictate that no patient feedback, model inputs, or model outputs may leave sovereign cloud jurisdictions.
The Human-in-the-Loop SLA Burden: Relying strictly on automated artificial intelligence or semantic models creates legal and operational liabilities. If an algorithm flags a candidate "red flag" (e.g., an omitted dose), it cannot trigger an automated incident report directly. It requires strict clinical governance—meaning authorized clinical or pharmacy staff must manually audit these flags within Service Level Agreements (SLAs). Managing the backlog of these pending reviews is an ongoing administrative strain.

The Bottom Line

To move from free-text to frontline action, healthcare systems must stop looking at aggregated regional averages. When clinical teams utilize automated pipelines to extract context at the exact level where action occurs—the ward—they can transform passive patient feedback into immediate, structured quality improvements. Structured waiting room protocols, quiet night routines, and teach-back discharge models prove that when we address localized operational points, patient care outcomes shift globally.

Building LinkedIN Job Application Agents - Part 3

Mindy Jen — Sun, 05 Apr 2026 23:34:17 +0000

🎯 Project Overview

HunterAgent transforms the tedious job application process into an intelligent, automated workflow. Instead of spending hours crafting resumes and cover letters for each position, candidates can focus on interview preparation while AI handles the repetitive tasks.

🧠 AI Agent Architecture

The system consists of 6 specialized AI agents, all using OpenAI’s Responses API:

🔍 JobDiscoveryAgent: Real web search for job opportunities on LinkedIn, Indeed with URL validation
📄 ResumeOptimizerAgent (ResumeManager): AI-powered resume customization with industry research and ATS optimization
✍️ CoverLetterAgent (LetterWriter): Personalized cover letters with live company research and multiple tone variations
🚀 ApplicationSubmitterAgent: Automated form filling and submission using Playwright MCP integration [planned; not implemented yet]
📧 EmailNotificationAgent: Send a daily digest with all matching jobs to your Gmail. [Gmail MCP integration for workflow updates and application confirmations. (planned - not implemented yet)]
👥 NetworkContactsAgent: Identify 3 people or the employee directory in the target company.

🛠️ Technology Stack

Frontend: Streamlit + Pandas (Python web framework)
Backend: Integrated Python application
Database: Supabase (PostgreSQL + Storage)
AI: OpenAI SDK for intelligent agents
LinkedIn Scraping: linkedin-mcp-server via MCP for web scraping
Indeed Scraping: requests + BeautifulSoup4
Browser Automation: Playwright
Email: Python smtplib for notifications (Gmail SMTP)

🚀 Recent Achievements (April 5, 2026)

✅ ALL 6 AI agents migrated to OpenAI Responses API
✅ Real web search integration working in production
✅ Fixed all broken imports and API references
✅ Complete multi-agent orchestration system implemented
✅ Production-ready foundation for automated job applications

📈 Technical Metrics

Agents: 6 production-ready AI agents
API Migration: 100% Responses API adoption
Web Search: Real-time job discovery implemented
Import Issues: All resolved (0 broken imports)
Test Coverage: All core components verified
Architecture: Unified BaseAgent pattern established

Building LinkedIN Job Application Agents - Part 2

Mindy Jen — Sat, 04 Apr 2026 22:32:21 +0000

The Technology Stack

Here’s what I built the MVP with:

Frontend: Streamlit + Pandas (Python web framework)
Backend: Integrated Python application
Database: Supabase (PostgreSQL + Storage)
AI: OpenAI SDK for intelligent agents
LinkedIn Scraping: linkedin-mcp-server via MCP for web scraping
Indeed Scraping: requests + BeautifulSoup4
Browser Automation: Playwright
Email: Python smtplib for notifications (Gmail SMTP)

✅ Working Features:

Multi-page Streamlit Application

Dashboard with metrics and analytics
Navigation between Resume Manager, Job Search, Applications, etc.
Clean, professional UI with sidebar navigation

Database Layer with Smart Fallbacks

Complete ORM with Supabase integration
Mock mode for development without database
Proper error handling and graceful degradation

Configuration Management

Environment-based configuration
Secure credential storage
Easy deployment setup

Developer Experience

Comprehensive test suite
One-command startup script
Automated health checks

Resume Optimization Agent: AI that tailors resumes to job descriptions

Stop Losing Jobs to ATS Filters: How AI Resume Tailoring Changes Everything

Getting past Applicant Tracking Systems (ATS) is one of the biggest challenges in today's job market. Even highly qualified candidates get filtered out simply because their resume doesn't contain the right keywords. That's where AI-powered resume tailoring makes a real difference.

With the Resume Optimizer, you can tailor your resume to any specific job in seconds — no manual rewriting required.

Just navigate to the Resume page, open the Optimize tab, select a job from your list, and choose your optimization mode.

Three modes are available depending on what your resume needs most:

Keyword mode analyzes the job description and naturally injects missing ATS keywords into your existing content — without making it sound robotic or keyword-stuffed.
Skills mode intelligently reorders your skills section so the most relevant abilities appear first, instantly signaling to both ATS systems and recruiters that you're a strong match.
Experience mode rewrites your bullet points using language that mirrors the job description, highlighting achievements and responsibilities most relevant to the role.

Each optimization preserves your actual experience — nothing is invented. The result is a resume that speaks the employer's language, passes ATS filters, and puts your best qualifications front and center.

Cover Letter Agent: Personalized cover letter generation

Never Send a Generic Cover Letter Again: AI-Powered Personalization at Scale

A great cover letter can be the difference between landing an interview and being overlooked. But writing a tailored letter for every application is exhausting — most job seekers either skip it or send the same generic template everywhere. AI changes that entirely.

With the Cover Letter Generator, you can produce a fully personalized cover letter for any job in seconds. Simply select a job from your scraped listings, choose a tone that matches your personality and the company culture, and let GPT-4o-mini do the writing.

Four tones are available to suit any situation. Professional delivers a formal, polished letter built around concrete achievements. Enthusiastic channels genuine excitement about the role while staying appropriate. Confident leads with impact statements and asserts your value directly. Creative opens with a memorable hook that makes your application stand out.

Behind the scenes, the generator researches the company — its culture, tech stack, and values — and cross-references your resume to highlight the most relevant experience. Every letter is three focused paragraphs, written specifically for that company and role.

The result is a cover letter that feels human, reads naturally, and speaks directly to what the employer is looking for — generated in under 30 seconds.

Building LinkedIN Job Application Agents - Part 1

Mindy Jen — Sat, 04 Apr 2026 15:49:46 +0000

The Problem: Job Applications Are a Time Sink

Job searching is broken. Candidates spend hours crafting resumes for each position, writing personalized cover letters, and manually filling out repetitive application forms. What if we could automate this entire process using AI?

That’s exactly what I set out to build: HunterAgent — an AI-powered system that automatically discovers jobs, optimizes resumes, generates cover letters, and submits applications on behalf of job seekers.

My Plan (Mar. 2026): Full Automation Stack

The vision was ambitious:

Job Discovery Agent: Scrape job sites using web automation
Resume Optimization Agent: AI-powered resume customization for each job
Cover Letter Agent: Generate personalized cover letters
Application Submission Agent: Automate form filling and submission
Email Notification Agent: Keep users informed of all activities

A technical deep-dive into integrating AI agents with Streamlit UI and Supabase for job application automation -

The Journey So Far...

Today marks a significant milestone in the HunterAgent project — I’ve successfully transformed three standalone AI agents into a fully integrated web application with persistent data storage. This blog post chronicles the technical challenges, architectural decisions, and breakthrough moments that brought our job application automation system to life.

What had been Built Today:

Core Achievement: Complete System Integration

3 AI Agents fully integrated with Streamlit UI
Supabase Database with 11 production tables
Real-time Processing with async/await patterns
Persistent Data Storage for all agent results
Production-Ready Application running at localhost:8501

Three AI Agents

Resume Optimization Agent

Purpose: AI-powered resume customization for specific job applications

Key Features:

Resume parsing and content extraction
AI-powered optimization with company research
Quality scoring and match analysis
Multiple optimization approaches (keyword-focused, skills-based, experience-focused)
Downloadable optimized resumes

Cover Letter Generation Agent

Purpose: Personalized cover letter creation with company research

Key Features:

Multiple letter tones (professional, enthusiastic, confident, creative)
Company research integration
Candidate information processing
Cover letter library with search and filtering
Quality scoring and personalization metrics

Job Discovery Agent

Purpose: Intelligent job search with market analysis

Key Features:

Multi-criteria job search
Market trend analysis
Company research capabilities
Saved jobs management
Real-time filtering and sorting

Technical Architecture

OpenAI Responses API Integration

We chose OpenAI’s new Responses API for its structured output capabilities and web search integration. This allows our agents to:

Access real-time company information
Generate structured JSON responses
Handle complex multi-step reasoning
Integrate web search seamlessly

Streamlit UI Framework

Streamlit provided the perfect balance of simplicity and functionality:

Rapid Development: Built complete UI in hours, not days
Session State Management: Persistent data across user interactions
Async Support: Native support for async/await patterns
Component Ecosystem: Rich set of UI components out of the box

Supabase Database Integration

Supabase offered the ideal backend solution:

PostgreSQL: Full SQL capabilities with JSON support
Real-time Features: Live updates and subscriptions
REST API: Easy integration with Python
Row Level Security: Built-in security features

Database Schema Design

Core Tables
— Users
CREATE TABLE public.users (
id UUID PRIMARY KEY,
email TEXT UNIQUE NOT NULL,
full_name TEXT,
avatar_url TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);

— Resume templates
CREATE TABLE public.resume_templates (
id UUID PRIMARY KEY,
user_id UUID REFERENCES public.users(id),
name TEXT NOT NULL,
content TEXT NOT NULL,
file_url TEXT,
is_default BOOLEAN DEFAULT FALSE,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);

Agent-Specific Tables
— Agent results
CREATE TABLE public.agent_results (
id UUID PRIMARY KEY,
user_id UUID REFERENCES public.users(id),
agent_type TEXT NOT NULL,
task_type TEXT NOT NULL,
input_data JSONB NOT NULL,
output_data JSONB NOT NULL,
success BOOLEAN NOT NULL,
error_message TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);

— Cover letters
CREATE TABLE public.cover_letters (
id UUID PRIMARY KEY,
user_id UUID REFERENCES public.users(id),
job_title TEXT NOT NULL,
company_name TEXT NOT NULL,
cover_letter_content TEXT NOT NULL,
quality_score INT,
generation_type TEXT,
agent_result_id UUID REFERENCES public.agent_results(id),
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);

— Optimized resumes
CREATE TABLE public.optimized_resumes (
id UUID PRIMARY KEY,
user_id UUID REFERENCES public.users(id),
original_resume_id UUID REFERENCES public.resume_templates(id),
job_title TEXT NOT NULL,
company_name TEXT NOT NULL,
optimized_content TEXT NOT NULL,
job_match_score INT,
optimization_type TEXT,
agent_result_id UUID REFERENCES public.agent_results(id),
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);

Technical Challenges Overcome

LinkedIn scraping via Windows MCP server (repost + 100-applicant filter active)
Job scoring with GPT-4o-mini (ATS fit score 0–100)
Resume tailoring + cover letter generation with GPT-4o-mini 4. LinkedIn Easy Apply automation (Playwright)
Email digest
Dashboard with full pipeline button Before each session, start the MCP server in Windows PowerShell:

uvx linkedin-scraper-mcp --transport streamable-http --host 0.0.0.0 --port 8765

HunterAgent — Step-by-Step Guide

First-Time Setup (do once)

Start the LinkedIn MCP server — open Windows PowerShell and run:

uvx linkedin-scraper-mcp --transport streamable-http --host 0.0.0.0 --port 8765

Leave this window open in the background.

Start the app — in your terminal:

streamlit run streamlit_app.py

Check the dashboard — confirm the green LinkedIn MCP server: connected status

Configure your profile — open the app and go to Settings:
- Keywords: software engineer, python developer (comma-separated)
- Location: Remote or New York, NY
- Resume Text: paste your full resume
- Companies Not Included: any companies to skip
- Notification Email: your Gmail address

Boost Your Agents with MCPs - Launch First Real-world Agentic App

Mindy Jen — Fri, 27 Mar 2026 17:21:56 +0000

Why MCP?

MCP stands for Model Context Protocol. Think of it as a standardised USB-C port for AI tools. Instead of every AI application inventing its own plugin system, MCP defines a common interface: a server exposes tools, a client (our agent here) discovers and calls them. The beauty is that the same MCP server can be reused by Claude Desktop, by a Strands agent, by any MCP-compatible client — without changing a single line of server code. This is the interoperability that the ecosystem has been missing. Here, we use FastMCP, a Python library that reduces an MCP server to almost nothing:

from mcp.server import FastMCP

mcp = FastMCP("Calculator Server")
@mcp.tool(description="Add two numbers together")
def add(x: float, y: float) -> float:
    return x + y
if __name__ == "__main__":
    mcp.run(transport="stdio")

That is a fully functional MCP server. The decorator @mcp.tool is all you need to expose a function to any MCP client.

Review: Our Analyst (Sub-agent)

We start with creating our first toolkit: an analyst. Running two terminals — one for the server, the other for the client — we immediately see the protocol in action.

The client (our agent here) connects, discovers the available tools (addition, subtraction, multiplication, and division), and calls them through the protocol (MCP). The agent calls a function without knowing whether the toolkit lives in a separate process or not.

The toolkit definitely resides within a server. The client (our agent here) receives a structured description and autonomously decides when and how to invoke the tool. No prompt engineering is needed to explain what the addition does.

Review: Our Weather Forecaster (Sub-agent)

The second toolkit is to introduce a weather forecaster that speaks the National Weather Service API.

The weather forecaster on a server exposes three tools:

get_alerts(state) - active weather alerts by US state code
get_forecast(latitude, longitude) - multi-period forecast for a location
get_current_weather(latitude, longitude) - live conditions from the nearest observation station

The implementation of the toolkit is fully async, using httpx for HTTP calls. We can call any external API, read from a database, run a subprocess - whatever our agent needs. The MCP layer is one communication contract between the agent (client) and a server where toolkits reside.

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Get weather forecast for a location."""
    points_url = f"{NWS_API_BASE}/points/{latitude},{longitude}"
    points_data = await make_nws_request(points_url)
    forecast_url = points_data["properties"]["forecast"]
    forecast_data = await make_nws_request(forecast_url)
    # format and return

Supervisor Agent (Head)

Now we connect the dots. A supervisor-mode Strands agent built upon the Amazon Bedrock (Claude Sonnet) is given access to controlling multiple toolkits simultaneously via MCP. When we ask the supervisor something like: “What should I have for lunch given today’s weather in New York?”, the supervisor will leverage the magic power of MCP to pass along the command to different toolkits (sub-agents).

The supervisor figures out that s/he needs to:

Calls the weather forecaster to get current conditions in New York
Reasons which food delivery service makes sense in terms of the current temperature and traffic conditions
Returns a recommendation

Now, the agent is not just completing the prompt texts. Instead, it is orchestrating tool calls, chaining results, and synthesising an answer. The Strands SDK handles the entire tool call loop:

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient

agent = Agent(
    model=BedrockModel(model_id="anthropic.claude-sonnet-4-5"),
    tools=[*calculator_tools, *weather_tools],
)
response = agent("What should I eat for lunch in New York today?")

Build A Text Analyzer (Sub-agent) From Scratch

We can build a text analyzer to shorten the length of a URL. More importantly, we can internalize the URL pattern.

The server exposes four tools: shorten_url, expand_url, get_url_stats, and analyze_text. The implementation uses an in-memory JSON store (with a note that production code would use a real database). Here is the shortener:

@mcp.tool(description="Shorten a long URL into a compact format")
def shorten_url(url: str, custom_code: str = None) -> Dict:
    content = f"{url}{datetime.now().isoformat()}"
    short_code = hashlib.md5(content.encode()).hexdigest()[:8]
    # store and return
    return {"short_url": f"short.ly/{short_code}"}

Key Takeaway: Any Python function can become an AI tool in minutes. Have a legacy internal API? Wrap it. Have a spreadsheet formula? Wrap it. The barrier is almost zero.

Launch Our Agentic App (Research Analyzer) via Bedrock AgentCore

From the development, we have our agent access toolkits via MCP locally over the stdio transport. On the other hand, the real production systems need:

Persistent endpoints accessible over HTTPS
IAM-based authentication (no open endpoints)
Container packaging for reproducible deployments
Auto-scaling based on load

Amazon Bedrock AgentCore Runtime handles all of this. The deployment script is deceptively short:

from bedrock_agentcore_starter_toolkit import Runtime

agentcore_runtime = Runtime()
response = agentcore_runtime.configure(
    entrypoint="text_utils_server.py",
    auto_create_execution_role=True,
    auto_create_ecr=True,
    requirements_file="requirements.txt",
    protocol="MCP",
    agent_name="text_utils_mcp",
)
launch_result = agentcore_runtime.launch()
print(f"Agent ARN: {launch_result.agent_arn}")

Under the hood, the bedrock_agentcore_starter_toolkit:

Packages your server and its dependencies into a Docker container
Pushes it to ECR (auto-created if it does not exist)
Creates an IAM execution role with least-privilege permissions
Deploys to AgentCore Runtime and returns a live ARN

After deployment (around 3–5 minutes), we update our agentic App configuration to point to the remote endpoint.

The remote MCP server is protected by AWS IAM via SigV4 signatures — the same signing mechanism used by every other AWS API. Here, we include a custom transport class that handles this transparently:

class SigV4HTTPXAuth(httpx.Auth):
    def __init__(self, credentials, service, region):
        self.signer = SigV4Auth(credentials, service, region)

    def auth_flow(self, request):
        aws_request = AWSRequest(
            method=request.method,
            url=str(request.url),
            data=request.content,
            headers=dict(request.headers),
        )
        self.signer.add_auth(aws_request)
        request.headers.update(dict(aws_request.headers))
        yield request

This extends HTTPX’s auth interface and plugs directly into the MCP StreamableHTTPTransport. Our agentic App continues to call tools with the exact same code - authentication is completely transparent at the transport layer. No API keys in environment variables, no token rotation to manage.

Once the remote server is alive, activating it in the agentic app is a toggle:

Putting Everything Altogether - Our Agentic App (Research Analyzer)

With the full stack in place — local servers, remote AgentCore server, SigV4 auth — our agentic app that combines all tools is now formed:

The "Research Analyzer" can:

Fetch and summarise web content
Analyse and transform text (via the remote AgentCore server)
Shorten URLs from its research
Check the weather for context-aware suggestions

All from natural language. All with tools that any developer could have written in an afternoon.

The Multi-Tool Orchestration Layer

Now, let's explore advanced implementation patterns — how to structure agents that manage many tools gracefully, handle tool failures, and maintain context across a conversation.

A few things worth highlighting from main.py:

Tool cache with TTL: tools are loaded once at startup and refreshed on demand, avoiding re-negotiation on every request
Session-scoped agents: each user session gets its own agent instance with isolated memory
Structured logging per server: each MCP server has its own log stream, invaluable for debugging multi-server interactions

def refresh_tools_cache():
    global cached_tools, tools_last_updated
    cached_tools = mcp_manager.get_all_tools(active_only=True)
    tools_last_updated = datetime.now()

This pattern, loading tools once and reusing them, becomes critical at scale. Negotiating the MCP protocol on every request adds latency; caching eliminates it.

Key Takeaways

MCP is the right abstraction. The separation between tool definition (server) and tool consumption (client/agent) is clean and powerful. It enables a genuine ecosystem of reusable tools.
FastMCP makes it trivial to start. Going from idea to working MCP server takes minutes, not days. The barrier to contributing tools to the ecosystem is essentially zero.
AgentCore closes the last mile. The hardest part of agentic AI in production is not the model or the tools — it is infrastructure: endpoints, auth, containers, scaling. AgentCore Runtime handles all of it with three lines of configuration.
SigV4 is the right auth for AWS-native stacks. No secret management overhead, no token rotation, automatic credential refresh. If your infrastructure is already on AWS, this is the obvious choice.

Boost Your Agents with MCPs - Productivity Customized Tools

Mindy Jen — Sun, 22 Mar 2026 04:45:10 +0000

A. Features

a. Calendar Integration

Function	Description	Intelligence
`create_event`	Schedule new meetings/appointments	Conflict detection, optimal time suggestions
`list_events`	View calendar for specific dates	Smart filtering, availability analysis
`check_availability`	Find free time slots	Multi-day search, duration-aware
`delete_event`	Remove scheduled events	Cascade handling, notification support

b. Weather Intelligence

Function	Description	Intelligence
`get_alerts`	Get weather alerts for US states	Real-time severe weather notifications
`get_forecast`	Multi-day weather predictions	Official NWS forecasts with detailed periods
`get_current_weather`	Current observation data	Real-time conditions from weather stations

c. Analyzer

Function	Description	Intelligence
`add`	Add two numbers together	Total
`subtract`	Subtract second number from first number	Comparison
`multiply`	Multiply two numbers together	multiplication
`divide`	Divide first number by second number	Percentage
`power`	power of a number	Repitition
`factorial`	factorial of positive number	Is It A Prime Number?

B. Testing

a. Calendar

1. Natural Language Queries

Try these conversational requests:

Query	Expected Behavior
"Schedule a team meeting tomorrow at 2pm"	Creates event, checks conflicts
"Do I have anything on Friday afternoon?"	Lists events for specified time
"Find me 30 minutes free time this week"	Suggests available slots
"Cancel my 3pm meeting today"	Finds and removes matching event

2. Complex Scenarios

The AI agent can handle complex requests as well:

I need to schedule a 90-minute project review with the team. I'm free Tuesday and Wednesday afternoons. What works best?

Agent Process:
1. Calls check_availability() for Tuesday/Wednesday afternoons
2. Finds optimal 90-minute slots
3. Suggests best options based on preferences
4. Creates event when user confirms

3. Error Handling

The calendar server handles various edge cases:

Error Type	Handling	User Experience
Invalid Date Format	Parse error with format help	"Please use format: YYYY-MM-DD HH:MM"
Past Date Scheduling	Validation with warning	"Cannot schedule events in the past"
File Corruption	Backup and recovery	Graceful fallback to empty calendar
Concurrent Access	File locking	Prevents data corruption

b. Weather

1. Natural Language Queries

Try these conversational weather requests:

Query	Expected Behavior
"Get current weather for Seattle"	Current conditions from nearest station
"Show me the forecast for San Francisco"	5-day detailed forecast periods
"Are there any weather alerts in California?"	Active severe weather alerts for CA
"What's the weather like in New York?"	Current observations with temperature

2. Error Handling

The server handles various failure modes gracefully:

Network timeouts: 30-second timeout prevents hanging
Invalid coordinates: Clear error messages for bad inputs
API unavailable: Graceful degradation with error messages
Missing data: Handles null/missing fields safely
State code validation: Validates US state codes for alerts

c. Analyzer

1. Natural Language Queries (Natural Language → Tool Mapping)

Query	Expected Behavior
"add 25 and 17"	→ add(x=25, y=17)
"25 plus 17"	→ add(x=25, y=17)
"what's 25 + 17"	→ add(x=25, y=17)
"sum of 25 and 17"	→ add(x=25, y=17)
"15% of 200"	→ percentage(number=200, percent=15)
"what is 15 percent of 200"	→ percentage(number=200, percent=15)
"square root of 64"	→ square_root(x=64)
"sqrt(64)"	→ square_root(x=64)

2. Complex Query Handling

For complex queries like

I have $1000, spend $234 on groceries and $156 on gas. How much is left?

Agent breaks down the problem
Calls subtract(1000, 234) → 766
Calls subtract(766, 156) → 610
Responds: "You have $610 left"

3. Error Handling

if y == 0:
    raise ValueError("Cannot divide by zero")

Provides clear error messages
Prevents invalid operations
Errors are automatically sent back to AI agent

Boost Your Agents with MCPs - MCP Fundamentals

Mindy Jen — Sun, 22 Mar 2026 00:42:44 +0000

We want to get every reader familiar with using MCP as a tool with LLMs to accomplish productivity tasks for our daily needs. We will see how LLMs can use multiple tools in concert to accomplish more advanced tasks.

We will first learn the core concepts of MCP by building our first intelligent tool - an analyst that understands natural language and provides contextual responses. This exercise will introduce everyone to MCP, the universal open standard for connecting AI systems with data sources and demonstrate its capabilities.

An analyst MCP server that goes beyond simple arithmetic:

Feature	Description	Example
Natural Language Processing	Understands conversational math/statistics queries	"What's 15% of 250?" → Calculation + explanation
Context Awareness	Remembers previous analyses	References earlier results in conversation
Error Handling	Graceful handling of invalid inputs	Clear messages for division by zero, invalid syntax
Rich Responses	Detailed explanations with breakdowns	Step-by-step calculation process

What we need to do...

MCP Architecture: Understand how MCP connects AI models to tools
Server Implementation: Build a working MCP server from scratch
Tool Registration: Register functions that AI models can discover
Response Formatting: Structure responses for optimal AI interaction
Integration Testing: Test our server with the application

A. MCP Protocol Overview

The Model Context Protocol (MCP) is an open standard designed to create a universal interface between AI models and external tools, data, and services. By using Bedrock AgentCore Runtime, developers can transition these tools from local functions to secure, enterprise-grade managed microservices.

Core Concepts of MCP

The protocol replaces custom, one-off integrations with a standardized request-response pattern:

Standardization: Provides a single protocol for all tools (e.g., same interface for analysis or weather tools).
Interoperability: Works across different models (Claude, GPT, Nova) using the same toolset.
Security: Implements sandboxed execution, parameter validation via JSON Schema, and controlled access patterns.

Communication & Message Types

MCP follows a structured flow to ensure the AI model understands and executes tools correctly:

Tool Discovery (tools/list): The model identifies accessible tools and their required parameters (schemas).
Tool Execution (tools/call): The model sends structured arguments to a specific tool to perform tasks beyond its internal knowledge.
Transport Methods: Supports stdio (standard input/output) for local development, as well as HTTP and WebSockets for remote or real-time applications.

Production Deployment with AgentCore

While local tools are useful for development, Bedrock AgentCore Runtime provides the infrastructure for production scaling:

Managed Infrastructure: Moves tools to managed services, removing the burden of server maintenance and scaling.
Enhanced Security: Integrates with Amazon Cognito to enforce strict authentication, ensuring only authorized agents can trigger sensitive operations.
Simplified Integration: A Strands Agent can connect to a remote MCP server and handle authentication handshakes automatically, consuming cloud tools as if they were local functions.

Summary Table: Benefits of Managed MCP

Feature	Local MCP (stdio)	Managed AgentCore Runtime
Primary Use	Development & testing	Enterprise-scale production
Security	Local process isolation	Amazon Cognito Authentication
Scaling	Manual/Local	AWS-handled auto-scaling
Accessibility	Limited to one machine	Shareable across teams/agents

Key Takeaway: This architecture allows developers to build a reusable library of secure MCP tools that any agent in an organization can invoke with minimal code.

B. Key MCP Concepts

Deploying custom tools at scale requires moving beyond local functions to a managed infrastructure that is secure, authenticated, and scalable. Bedrock AgentCore Runtime enables the deployment of Model Context Protocol (MCP) servers as managed services, transitioning tools from local Python decorators to enterprise-grade microservices.

1. Building and Deploying an MCP Server

The development process is simplified using the FastMCP framework, which automates protocol message formatting and JSON Schema generation.

a. Define the Local Server

Using FastMCP, you can quickly define tools with standard Python type hints:

from mcp.server import FastMCP

# Create the MCP server instance
mcp = FastMCP("Analyzer")

# Register a tool; FastMCP handles the schema generation automatically
@mcp.tool(description="Add two numbers")
def add(x: float, y: float) -> float:
    return x + y

# Run using stdio for local testing
mcp.run(transport="stdio")

b. Deploy to AgentCore Runtime

Once containerized, the server is registered with the Runtime Client to become a managed cloud service:

from bedrock_agentcore.tools.runtime_client import RuntimeClient

runtime_client = RuntimeClient(region="us-east-1")

# Deploy with Cognito security
mcp_server = runtime_client.create_mcp_server(
    name="SearchService",
    image="your-docker-image-uri",
    auth_config={
        "type": "COGNITO",
        "user_pool_id": "us-east-1_xxxxxxxxx",
        "client_id": "xxxxxxxxxxxxxxxx"
    }
)

2. Connecting a Strands Agent to a Remote Tool

Strands Agents leverage the AgentCoreRuntime to connect to these remote services. The agent automatically manages the authentication handshake, treating the remote MCP server as a local capability.

from strands import Agent
from strands.models import BedrockModel
from strands_tools.runtime import AgentCoreRuntime

# Connect to the deployed runtime
agentcore_runtime = AgentCoreRuntime(region="us-east-1")

# Create agent using the remote managed tool
agent = Agent(
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0"),
    tools=[agentcore_runtime.mcp_tool(server_name="SearchService")]
)

# Execution: Discovery -> Intent Recognition -> Parameter Extraction -> Execution
agent("What are the key highlights from the latest AWS Re:Invent?")

Summary of MCP Implementation

Component	Role	Technology
Frontend	User interface and real-time chat	React
Backend	Agent orchestration	FastAPI with Strands Agents
MCP Servers	Tool implementations	Python with `FastMCP`
AI Models	Natural language processing	Amazon Nova Pro / Claude

Key Takeaway: Bedrock AgentCore Runtime acts as the "production glue" for AI agents. It shifts the responsibility for security, scaling, and server management to AWS, allowing organizations to maintain a secure library of reusable tools accessible via a single line of code.

C. Building an Analyst MCP Server

An Analyzer MCP Server is created using the FastMCP framework. It demonstrates how to turn standard Python functions into tools that an AI agent can use to solve natural language math problems. Let's build our first MCP server - an analyst that handles natural language math queries with context and error handling.

A short excerpt of this code is shown below:

from mcp.server import FastMCP
import math

# Create MCP server instance
mcp = FastMCP("Analyzer Server")

@mcp.tool(description="Add two numbers together")
def add(x: float, y: float) -> float:
    """Add two numbers and return the result."""
    return x + y

...

@mcp.tool(description="Divide first number by second number")
def divide(x: float, y: float) -> float:
    """Divide x by y and return the result."""
    if y == 0:
        raise ValueError("Cannot divide by zero")
    return x / y

...

if __name__ == "__main__":
    print("🔢 Starting Analyzer MCP Server...")
    mcp.run(transport="stdio")

To build a successful MCP server, focus on these four pillars:

Pillar	Action	Why it Matters
Context	Use detailed docstrings and descriptions.	Helps the AI choose the right tool for a natural language query.
Validation	Always use Python type hints (`x: float`).	Prevents the AI from sending "garbage" data that crashes your code.
Resilience	Raise specific errors (e.g., `ValueError`).	Allows the AI to explain the error to the user rather than failing silently.
Chaining	Design tools to be composable.	Enables the agent to solve complex, multi-step problems (e.g., Compound Interest).

1. Key Implementation Details

a. Server Creation (Core Implementation Flow)

The server is built by defining a FastMCP instance and decorating functions to expose them as tools.

Initialization:
- Creates a new MCP server with a descriptive name
- The name helps with debugging and tool discovery

mcp = FastMCP("Analyzer Server")

Transport: Uses stdio (Standard Input/Output) for local communication between the AI and the server.
Registration: The @mcp.tool decorator tells the AI what the tool does and what inputs it requires.

b. Tool Registration (Essential Tool Components)

@mcp.tool(description="Add two numbers together")
def add(x: float, y: float) -> float:

To ensure the AI uses our tools correctly, every function should include:

Component	Purpose
`@mcp.tool()`	Registers function as MCP tool
`description`	Helps AI understand tool purpose
`Type hints`	Enables automatic parameter validation
`Docstring`	Provides additional context

c. Intelligence Error Handling

if y == 0:
    raise ValueError("Cannot divide by zero")

Provides clear error messages (Natural Language Mapping) The AI automatically maps user phrases like "sum of 25 and 17" or "25 plus 17" to the add(x=25, y=17) function.
Prevents invalid operations (Complex Queries): The agent can "chain" tools. For a budget query, it might call subtract() multiple times to reach a final answer.
Errors are automatically sent back to AI agent (Graceful Failures): By raising a ValueError("Cannot divide by zero"), the error message is passed directly back to the AI, allowing it to explain the mistake to the user rather than just crashing.

d: Best Practices for Developers

Be Specific: Use clear descriptions like "Calculate 15% of 200" instead of "Does percentage stuff."
Strict Typing: Always use Python type hints to prevent the AI from sending the wrong data formats.
Logging: Use import logging to track how the AI invokes our tools in the background.
Memory: We can add "Context Awareness" by storing results in a list (e.g., calculation_history) so the agent can reference previous answers.

Key Takeaway: The Model Context Protocol (MCP) transforms isolated Python functions into intelligent, conversational tools that an AI agent can understand and execute. The transition from a local script to an enterprise-grade tool happens in three stages:

Standardization (Local): Using FastMCP, we wrap standard Python functions with decorators. By providing strict type hints and descriptions, you create a "contract" that the AI model (like Claude or Nova) can read to understand exactly how to perform math/analysis or data tasks.
Scalability (Managed): You move from running a script on your machine to deploying a containerized image via Bedrock AgentCore Runtime. This shifts the burden of server maintenance and scaling to AWS.
Security (Enterprise): By integrating Amazon Cognito, you ensure that only authorized agents can trigger your tools, protecting sensitive operations like database searches or proprietary calculations.

MCP isn't just about math; it's the universal glue for the AI era. Whether we are building a simple analyzer or a complex anomaly detection system, MCP allows us to build our logic once and use it across any AI model or team in our organization.

Boost Your Agents with MCPs - Set up First Real-World Agentic App

Mindy Jen — Sat, 21 Mar 2026 19:36:53 +0000

People use AI-powered tools for various purposes - from simple text completion to writing full reports. But what if your AI assistant could do more? What if it could check your calendar, get weather updates, or connect to your business systems?

The answer is: Using MCP to connect to external tools like weather APIs and calendars can empower your AI assistant to do whatever you like!

About This Product

In this week’s blog series, we highlight practical, real‑world applications that you can put into use immediately. We'll build a complete set of AI-powered productivity tools:

Tool	What It Does	Key Features
Smart Communicator	Performs advanced math/statistics operations	Understands natural language, handles complex data analyses
Calendar Assistant	Manages your schedule intelligently	Detects conflicts, suggests optimal meeting times
Weather Advisor	Provides smart weather forecasts	Recommends activities based on conditions
Bring Your Own MCP (BYOM) Server	Custom functionality you design	Build tools specific to your needs

All integrated into a pre-built React application - so we can focus on building the intelligence, not the UI! "UI is Ready, Focus on the Intelligence" - A complete frontend is provided in advance so we can focus on building the AI-powered backend tools that make a real difference in productivity. In the end, we'll have built multiple MCP servers with hands-on experience, production-ready code we can use daily, and practical patterns for building real-world AI applications.

Environment Overview

Pre-Installed Tools

Tool	Purpose	Version
Python	Backend development	3.11+
Node.js	Frontend dependencies	18+
AWS CLI	AWS service access	Latest
Git	Version control	Latest

AWS Services Configured

Our environment has access to:

Amazon Bedrock: AI model access (Amazon Nova, Anthropic Claude)
CloudWatch: Logging and monitoring
Secrets Manager: Secure credential storage
EC2: Compute resources
VPC: Networking

Frontend (React)

Modern chat interface
Real-time message streaming
Token usage tracking
Session history

Backend (FastAPI)

Strands Agents integration
MCP server management
Bedrock model access
WebSocket support

Launching Application

This is the application...

Left Navigation Panel

On the left side, we have a navigation panel where we can choose the foundation model and and turn on/off MCP servers.

Chat Interface

In the center of the application, we have a chat interface where we can type and see responses from the foundation model.

Server logs

On the right side, we have a panel with the server logs. We have the ability to filter through the different type of logs generated by our server.

Accessing the Application

Once started, we can access the application at:

Frontend: CloudFront URL + /proxy/3000/ (e.g., https://abc123.cloudfront.net/proxy/3000/)
Backend API: CloudFront URL + /proxy/8000/ (e.g., https://abc123.cloudfront.net/proxy/8000/)

We can find the CloudFront URL under the PORTS tab. Then, click on the globe icon next to the URL to open the page directly in the browser.

Troubleshooting Common Issues

Important: Only use the following commands when you are facing an issue.

Issue	Solution
Port already in use	Run `pkill -f "python\
Permission denied	Run {% raw %}`chmod +x start.sh`
Module not found	Activate virtual environment: `source .venv/bin/activate`
AWS access denied	Environment should be pre-configured, contact instructor

Verification

Once our environment is running:

Verify Application: Access the frontend using CloudFront URL + /proxy/3000/
Test Chat Interface: Send a simple message
Check Backend: Ensure API responds at CloudFront URL + /proxy/8000/
Review Code Structure: Explore the ui/backend/mcp_servers/ directory

Environment Ready: Our development environment is configured and ready for building MCP servers!

Get Your Hands Dirty - AgentCore - Gateway

Mindy Jen — Sun, 15 Mar 2026 01:50:04 +0000

Automating Tool Creation with Bedrock AgentCore Gateway

One of the biggest hurdles in agent development is manually writing "glue code" for every external API. Bedrock AgentCore Gateway eliminates this by providing a "zero-code" path to tool creation. By pointing the Gateway to a standard OpenAPI specification (Swagger), it automatically generates a Model Context Protocol (MCP) server. This allows your Strands Agent to understand and interact with any REST API—complete with complex request schemas and authentication—without you writing a single line of integration logic.

The Gateway also handles enterprise-grade security by managing the handshake between your agent and the external service. You can configure JWT-based authentication for the agent itself and link it to AgentCore Identity to securely inject the external API keys (like Exa or Slack) into the headers of every outgoing request.

A. Generating MCP Tools from an OpenAPI Spec

Instead of writing Python functions, you simply register the API's OpenAPI URL. The Gateway parses the specification and instantly exposes every endpoint as a callable tool for the agent.

from bedrock_agentcore.tools.gateway_client import GatewayClient

# Initialize the Gateway Client
gateway_client = GatewayClient(region="us-east-1")

# Create a Gateway that converts an OpenAPI spec into MCP tools
gateway = gateway_client.create_gateway(
    name="ExaSearchGateway",
    auth_config={"type": "JWT"}, # Secure the gateway itself
    targets=[{
        "name": "ExaAPI",
        "openapi_url": "https://api.exa.ai/openapi.json", # The "source of truth"
        "credential_provider_id": "your-secure-credential-id" # Injected securely
    }]
)

print(f"Gateway generated MCP endpoint: {gateway['endpoint']}")

B. Using Generated Tools in a Strands Agent

The Strands Agent treats the Gateway like any other toolset. Because the Gateway provides full semantic descriptions from the OpenAPI spec, the agent knows exactly which parameters to send to the external API to get the job done.

from strands import Agent
from strands.models import BedrockModel
from strands_tools.gateway import AgentCoreGateway

# Connect the Strands Agent to the Gateway
agentcore_gateway = AgentCoreGateway(region="us-east-1", gateway_id=gateway["id"])

agent = Agent(
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0"),
    system_prompt="You are a research assistant. Use the Exa tools to find live data.",
    tools=[agentcore_gateway.gateway] # All OpenAPI endpoints are now tools
)

# The agent automatically picks the correct 'search' endpoint from the spec
agent("Search for the top 5 trending research papers in Quantum Computing from this week.")

Key Takeaway: Bedrock AgentCore Gateway is the ultimate bridge between AI and the existing web. It turns standard documentation into functional code, allowing you to scale an agent's capabilities from a single tool to an entire ecosystem of APIs in minutes. By moving from manual coding to specification-driven integration, you ensure your agents are always aligned with the latest version of the services they consume.