Go Link Shortener

Inspiration

Go Link Shortener started as a small, fast URL shortener built around a simple idea: creating and resolving short links should require as little friction as possible.

When I discovered WebMCP, the project became a natural experiment for a different question:

What if an AI agent did not need to inspect the page, understand the layout, and simulate clicks just to use a web application?

Instead of building a separate chatbot or a remote MCP server, I wanted the existing website itself to expose its capabilities directly to AI agents while remaining fully usable by humans.

The result is an agent-native URL shortener where the same application can be used through its normal UI or through structured WebMCP tools.

What it does

Go Link Shortener allows users to create custom short URLs, redirect visitors efficiently, and collect click analytics.

With WebMCP enabled, the website exposes three capabilities directly to AI agents:

• create_short_link — creates a short URL using the existing HTML form and server-side validation.
• resolve_short_link — returns the destination behind an existing alias.
• get_link_analytics — returns aggregate traffic information such as total clicks and the latest click timestamp.

This enables interactions such as:

"Create /webmcp pointing to the WebMCP documentation."

or:

"Where does /webmcp redirect, and how many times has it been opened?"

The agent can discover and execute the appropriate tools without visually locating controls or automating clicks.

How I built it

The backend is written in Go using Fiber v3, with PostgreSQL as the persistent datastore and Redis for fast URL resolution.

I deliberately kept the existing server-rendered architecture instead of introducing a frontend framework only for WebMCP.

For link creation, I used the Declarative WebMCP API. The existing HTML form is exposed as the create_short_link tool, so both humans and agents go through the same validation and persistence code.

For read operations, I used the Imperative WebMCP API through:

document.modelContext.registerTool(...)

Two read-only tools are registered when WebMCP is available:

resolve_short_link
get_link_analytics

They call lightweight JSON endpoints implemented in the existing Go application.

The integration is implemented as progressive enhancement. If a browser does not support WebMCP, the website continues working normally.

Privacy and safety

The original application records redirect events for analytics, including information useful for internal traffic analysis.

I intentionally designed the WebMCP interface to expose only aggregate information.

The get_link_analytics tool returns:

• total clicks
• latest click timestamp

It does not expose raw IP addresses, User-Agent strings, referrers, or individual click events.

Read operations are also explicitly marked with readOnlyHint: true, giving agents additional information about which actions are safe to execute without modifying application state.

Challenges I faced

One of the most interesting challenges was that implementing the tools themselves was not enough.

WebMCP requires the document to run in the appropriate browser security context, so I had to configure origin isolation using:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

I also added configurable support for the WebMCP Origin Trial token so the application can participate in the browser experiment without hardcoding environment-specific credentials.

Another challenge was deciding where WebMCP should stop.

It would have been easy to create a parallel API layer, duplicate validation in JavaScript, or rebuild the UI using a frontend framework. Instead, I kept the existing application as the source of truth and exposed only the capabilities an agent actually needs.

That kept the implementation small, maintainable, and aligned with the progressive nature of WebMCP.

What I learned

The biggest lesson was that making a website agent-friendly is very different from adding AI to a website.

There is no LLM inside Go Link Shortener.

Instead, WebMCP gives external agents a structured contract describing what the website can do.

This changes the integration model from:

Agent → inspect DOM → understand UI → simulate clicks

to:

Agent → discover tools → execute structured action

I also learned that good tool design matters as much as implementation. Tool names, descriptions, JSON schemas, read-only annotations, error handling, and privacy boundaries directly affect how reliably an agent can interact with the application.

What's next

The next steps would be to expand the agent-native interface with capabilities such as:

• listing and searching previously created links
• safely deleting or disabling short links
• richer aggregate analytics
• expiration dates
• QR code generation
• authenticated link management

The important part is that these features can continue using the same architecture: normal web functionality for humans, structured WebMCP capabilities for agents.

Go Link Shortener remains a simple web application.

It just no longer assumes that every visitor using it has fingers.

Built With

• ai-agents
• chrome
• context
• docker
• fiber
• go
• html
• javascript
• json
• model
• postgresql
• redis
• rest-api
• webmcp