Title

MCP, Meet PCM

Subtitle: Portfolio Context Manager — a WebMCP-powered portfolio that turns visitor context into evidence, a durable takeaway, and a human-reviewed project brief.

One-line Summary

PCM turns Mohit's portfolio into a context manager where people and agents find relevant proof, create a tailored takeaway, and prepare the next conversation together.

Problem

Professional portfolios are designed for browsing, not collaboration. A founder, CTO, recruiter, or design leader must scan several pages, infer which projects matter, verify whether the evidence truly supports their need, remember the useful parts, and then repeat the context in a blank contact form.

An agent can help, but without a structured interface it must scrape presentation-oriented pages, reconstruct the site's meaning, and guess which claims are canonical. The website knows the facts; the agent knows the visitor's context. Conventional portfolios give them no reliable way to work together.

Solution

PCM adds five WebMCP tools to the existing portfolio. The agent can establish a canonical profile, rank relevant work with evidence and honest gaps, create a visible visitor-specific briefing, save selected work as a durable web/PDF takeaway, and prepare an editable project brief.

The human stays in the loop. Page-changing actions are visible and reversible. A takeaway is created only after the visitor confirms that anyone with its unguessable link may view it. An inquiry is prepared and the contact form is prefilled, but the tool never sends it.

This produces a better experience than either side can create alone: the site contributes reviewed, structured evidence; the agent contributes the visitor's already-known goals and priorities; the human sees, edits, saves, or rejects the result.

Why This Matters

The same pattern applies far beyond portfolios. Today, useful web experiences repeatedly ask people to translate context from their agent back into forms and filters. A structured website capability layer can let agents do the broad comparison work while the website retains authority over facts, validation, presentation, persistence, and side effects.

MCP, Meet PCM demonstrates that future on a familiar, high-friction decision: “Could this person help us?” Instead of producing a generic summary, the collaboration ends in inspectable evidence and an actionable—but deliberately unsent—next step.

Why This Is a Strong Fit for WebMCP

  • The agent needs reliable access to facts and actions owned by the live website, not a second copy of the portfolio in an external database.
  • Visitor context is what makes the experience valuable, but that context should not need to be permanently uploaded to the site.
  • Read-only research and state-changing actions have meaningfully different contracts and safety boundaries.
  • The best result is visible on the web page: a human can inspect what the agent selected, edit it, reset it, save it, or continue manually.
  • The five tools form a coherent journey rather than a decorative one-tool integration.

How We Used AI

The visitor's agent supplies the reasoning. The website supplies canonical public data, strict tool contracts, deterministic matching, evidence boundaries, visible UI state, and durable artifacts. No embedded chatbot or paid model call is required.

AI is useful here because it can combine the visitor's nuanced intent with a larger evidence set, explain why specific work is relevant, and carry context between research, personalization, saving, and inquiry preparation. The site's deterministic layer prevents that reasoning from becoming an excuse to invent credentials, project outcomes, or client claims.

The implementation was tested through Codex's in-app browser and with GPT-5.6 Terra. GPT-5.6 Luna completed page, saved-artifact, and injection baselines, but its available browser runtime did not expose document.modelContext or the WebMCP tool-list operation; that limitation is reported rather than treated as a pass.

How We Used Codex

Codex was a working product and engineering partner throughout the WebMCP extension. It helped:

  • turn the initial concept into product, development, and browser acceptance specifications;
  • define bounded tool contracts and the human/agent safety model;
  • implement the five tools, canonical content layer, relevance engine, browser state, storage API, and PDF output;
  • write regression tests and exercise complete browser flows rather than checking registration alone;
  • inspect desktop and mobile UI, identify the unfinished modal-like experience, and redesign it into a polished editorial briefing and project-brief surface;
  • validate persistence, confirmation gates, error states, privacy boundaries, response headers, deployment storage, and rate limiting;
  • prepare the demo narrative and Devpost materials while keeping unverified claims and release blockers explicit.

Key Features

  1. Canonical understanding — a concise, bounded profile and service overview from reviewed site content.
  2. Evidence-based matching — deterministic project ranking with approved evidence, stable links, and explicit evidence gaps.
  3. Visible portfolio context — an editorial briefing tailored to the visitor's role, goal, and priorities, with reset and persistence behavior.
  4. Durable takeaway — an immutable public-by-link page and server-generated PDF, created only after confirmation.
  5. Human-reviewed inquiry — an editable brief that prefills the existing contact form while remaining clearly unsent.
  6. Progressive enhancement — the normal portfolio remains complete when WebMCP is unavailable.

Architecture

PCM is an Astro 7 application with React islands deployed on Vercel. A browser adapter checks for document.modelContext.registerTool and registers exactly five tools. Zod validates bounded inputs; outputs are compact structured results.

The human pages and tools consume the same canonical content under src/content. Relevance matching is deterministic and uses curated capabilities, audiences, problem types, roles, outcomes, evidence, and evidence gaps. Personalized views and inquiries use versioned sessionStorage and custom events to keep state changes visible.

Confirmed takeaways are written through an Astro API to private Vercel Blob storage. IDs are opaque, stable, HMAC-derived values; exact retries are idempotent. Public records exclude identity, email, transcripts, and hidden reasoning. Saved pages are no-index and offer a server-generated PDF.

Public Demo Link

https://mohittater.in/

Public Repository Link

https://github.com/mnttnm/mohit-freelance-portfolio

Known Limitations

  • WebMCP support varies across experimental browser and agent runtimes.
  • The available GPT-5.6 Luna browser runtime did not expose the required page model context, so real Luna routing remains blocked by that runtime.
  • Preview deployments remain owner-protected; the production judging URL is public and was verified separately.
  • Saved takeaways are public by unguessable link and do not yet have an account-based library or revocation UI.
  • Inquiry preparation intentionally stops before external communication.
  • Real email delivery, timed cancellation, and timed storage-failure recovery were not exercised against production.

Built With

  • codex
Share this project:

Updates