DEV Community: Hirohisa Tanaka

Why PHP Uses snake_case Functions but camelCase Methods

Hirohisa Tanaka — Thu, 13 Aug 2026 04:58:14 +0000

Built-in functions are usually snake_case.
Modern framework code is usually camelCase.

That is PHP: a language where naming conventions can feel oddly split.

So which naming convention is actually "correct" in PHP?

I'm tanahiro2010, and this is one of those small-but-persistent questions that keeps coming back whenever I write PHP.

Let me say this up front: this article is not about declaring either camelCase or snake_case the one true style. Instead, it looks at why PHP's naming conventions appear to differ by layer, traces that split through PHP's history, and offers a practical way to decide how to name things in your own code.

While writing this, I tried not to rely only on memory or second-hand explanations. Where possible, I checked primary sources such as the official PHP manual, the PHP-FIG website, and the PEAR manual. For historical details I could not fully verify, especially around early PHP-FIG membership and some framework-specific context, I explicitly mark them as unconfirmed or inferential.

A note on terminology
This article includes a few terms that may be unfamiliar if you are new to PHP or web development. When that happens, I add a short explanation in a blockquote like this. You can skip these blocks if you already know the terms; the main argument should still be readable without them.

Have you seen code like this?

When writing PHP, you often run into functions like these:

str_replace($search, $replace, $subject);
array_map($callback, $items);
json_encode($payload);
file_get_contents($path);

As you can see, these names use snake_case: words connected with underscores.

But modern PHP code, especially framework-based code, often looks more like this:

$request->getParsedBody();
$response->getStatusCode();
$userRepository->findById($id);

This time, the names use camelCase: words joined together, with later words starting with uppercase letters.

Inside the same language, PHP, two very different-looking styles coexist. This article traces where that split came from.

The conclusion first
Why PHP built-in functions look like snake_case
PHP 3 and the spread of function-based web programming
PEAR: shared conventions before PSR
PHP 5 and the rise of OOP PHP
Framework culture in the late 2000s
A side note on Symfony helpers
PHP-FIG and PSR
What PSR-1 says, and what it does not say
Why naming still hurts
Practical guidelines for modern PHP
Summary

1. The conclusion first

Before getting into the history, here is the conclusion of this article:

Regular functions, including global functions, helper functions, and procedural APIs: snake_case
Class methods: camelCase

After looking through PHP's history, this feels like the most natural compromise to me.

That said, this is not an absolute law. Always prioritize the following when they apply:

If an existing project already has a convention, follow it.
If your framework has a convention, such as Laravel, Symfony, or WordPress, follow it.
If you are naming a public API, preserving backward compatibility matters more than stylistic purity.

What is PSR?
PSR stands for PHP Standard Recommendation. PSRs are standards created by PHP-FIG, a group that defines coding styles and shared interfaces for the PHP ecosystem. PSR-1 and PSR-12 are examples. PSRs are not part of the PHP language specification itself; they are community standards.

One important premise: PHP does not enforce naming style at the syntax level. Whether you write names in snake_case, camelCase, or something else, the PHP interpreter will usually run the code just fine. In other words, PHP lets you write code that works even if it ignores naming conventions. This becomes important later when we talk about why naming still causes pain.

So why does "functions use snake_case, methods use camelCase" feel natural in PHP? Let's go back to 1995.

2. Why PHP built-in functions look like snake_case

PHP did not begin as a carefully designed language

PHP began as a small set of CGI binaries written by Rasmus Lerdorf in 1994 to track visits to his online resume. It was called "Personal Home Page Tools" or "PHP Tools". The source code was released in June 1995 (PHP: History of PHP - Manual).

What is CGI?
CGI stands for Common Gateway Interface. It is a mechanism that lets a web server call an external program and return the program's output to the browser. In the 1990s, CGI programs written in languages like Perl were a common way to generate dynamic web pages. PHP started in this world as a set of C-based executables.

In September 1995, PHP evolved into "FI" or "Forms Interpreter". In April 1996, the two were combined as "PHP/FI". Then in 1997, Andi Gutmans and Zeev Suraski, who were in Tel Aviv at the time, rewrote the parser and worked with Rasmus Lerdorf to create a new language. In June 1998, PHP 3 was released as the official successor to PHP/FI 2.0. The name also changed to the recursive acronym "PHP: Hypertext Preprocessor" (PHP: History of PHP - Manual).

In other words, PHP was not born from the sequence "design a complete language specification, then implement it." It grew from practical personal tools into a language because people needed it. Nobody was designing API naming conventions in anticipation of a massive global ecosystem thirty years later. That is the first point to keep in mind.

A function culture grew from there

Useful web development features, such as string handling, array operations, file operations, and database access, were added as functions.

Many functions that still exist in PHP today are part of that lineage:

str_replace();
array_map();
json_encode();
file_get_contents();
mb_strlen();
mysqli_connect();
array_filter();
preg_match();
htmlspecialchars();

As you can see, many of them use snake_case.

A technical note: why snake_case was likely natural

PHP's implementation is written in C. The core runtime is called the Zend Engine.

What is the Zend Engine?
The Zend Engine is the internal engine that parses and executes PHP code. It was developed by Andi Gutmans and Zeev Suraski and has been the execution foundation of PHP since PHP 3.

In C and its standard library ecosystem, function names are traditionally lowercase and often use underscores, although not always. Examples include names such as strcpy, memcpy, and time. Many early PHP built-in functions were thin wrappers around C functions or C libraries, so it is reasonable to think that C naming culture influenced PHP's function names.

I do not mean this as a claim that every PHP function directly follows C naming rules. I have not exhaustively verified that. It is better understood as a general tendency.

But it is not completely consistent

If the story ended here, we might say "PHP built-ins are all snake_case." But that would not be accurate. Standard classes in PHP often have camelCase or PascalCase-style method names:

$reflectionClass->getName();
$reflectionMethod->getParameters();
$dateTime->setTimezone($timezone);

What is Reflection?
ReflectionClass and ReflectionMethod are part of PHP's built-in Reflection API. Reflection lets a program inspect information about classes, methods, parameters, modifiers, and more at runtime. Frameworks and testing tools often use it internally.

So we need to distinguish between "global function culture" and "standard class/method culture". That difference connects directly to the later spread of object-oriented PHP.

What is OOP?
OOP stands for object-oriented programming. It is a way of designing programs around classes, where data and behavior are grouped together as properties and methods. The idea that "class methods use camelCase" comes up repeatedly later in this article.

The PHP manual also has a page called Userland Naming Guide. It states that function names should use underscores between words, and that both camelCase and PascalCase appear in class names. It also names strpos() as an example of an old naming mistake because it does not follow the recommended extension prefix rule.

So if PHP naming feels inconsistent, you are not imagining it. The official manual itself acknowledges historical inconsistency.

My summary for this section is: PHP's built-in functions look snake_case not because of a perfectly planned language design, but because early PHP grew out of practical C-based implementation culture.

3. PHP 3 and the spread of function-based web programming

PHP 3 was released in June 1998 as the official successor to PHP/FI. Around this point, PHP development expanded from a personal project into a broader multi-person effort. Features were added rapidly through extension modules.

What is an extension module?
An extension adds functionality to PHP itself. For example, the curl extension provides HTTP communication through the cURL library, and the mysqli extension provides MySQL access. Many PHP built-in functions are grouped by extensions like these.

During this period, practical web development needs such as database access, form handling, and session management drove PHP's growth. Functions were added as needed. There was not yet a strong centralized process for reviewing naming consistency. Functionality and usefulness came first; naming consistency came later, if at all.

Once a name is public, changing it is hard

Once a function name is public and widely used, it becomes difficult to change. This is a backward compatibility problem.

What is backward compatibility?
Backward compatibility, often abbreviated BC, means code written for an older version of software keeps working in newer versions. Renaming or removing a function can break every existing codebase that uses it, so many languages and frameworks treat public API names as something that should not be changed casually.

PHP's old mysql_* functions, such as mysql_query, are a good example. They went through deprecation and were eventually removed, but that took a long time. This illustrates how hard it is to change names and APIs after they become widely used. I am keeping this example at a high level here because I did not fully verify the detailed year-by-year timeline for this article.

Naming is not decided by philosophy alone

So far, we can see that naming depends on several axes:

Axis	Example
When it was created	Pre-2000 PHP built-ins vs post-PSR code
Who created it	Rasmus Lerdorf individually vs a group such as PHP-FIG
Which culture it came from	C-style function culture vs OOP framework culture
Whether compatibility can be broken	Global functions with huge compatibility cost vs new framework APIs
Which API layer it belongs to	Built-in language functions vs userland classes

It is easy to say PHP naming is inconsistent because the design philosophy was inconsistent. But in practice, PHP's naming style is the result of several historical layers overlapping.

4. PEAR: shared conventions before PSR

What is PEAR?

Before PSR, PHP already had shared coding conventions. They came from PEAR.

What is PEAR?
PEAR stands for PHP Extension and Application Repository. It is a repository and package distribution system for reusable PHP libraries.

One fact-checking note: in an earlier draft, I wrote that PEAR was released in December 2002. After checking multiple sources, I found that PEAR was started around 1999 by Stig Bakken. It is said to have grown out of discussions at the PHP Developers' Meeting in Tel Aviv in January 2000. I could not find a primary source confirming the 2002 date, so this article treats PEAR as a project that began around 1999. I have not pinned down the exact founding date or release timeline.

PEAR naming conventions

PEAR had clear naming conventions more than a decade before PSR (PEAR Manual: Naming Conventions).

Target	Rule	Example
Class names	Initial uppercase, hierarchy expressed with underscores	`Log`, `Net_Finger`, `HTML_Upload_Error`
Method names	Lowercase first word, then studly caps	`connect()`, `getData()`, `buildSomeWidget()`
Global functions	Package name prefix, then studly caps	`XML_RPC_serializeData()`
Constants	Uppercase with underscores	`DB_DATASOURCENAME`, `SERVICES_AMAZON_S3_LICENSEKEY`

The interesting part is that PEAR recommended a camel-like style even for global functions. So the simple story "PHP functions have always been snake_case" is not quite true. Even before PSR, there was already a separate naming culture inside the PHP community that differed from PHP built-in function style.

PEAR class names as pseudo-namespaces

Class names such as Net_Finger and HTML_Upload_Error may look strange today, but they had a technical reason.

What is a namespace?
A namespace is a way to prevent name collisions by giving classes and functions a kind of address. PHP introduced the namespace keyword in PHP 5.3 in 2009. Before that, PHP did not have native namespaces.

In the PEAR era, PHP did not have namespaces, so libraries avoided class-name collisions by encoding hierarchy in the class name itself: package name, underscore, class name. Today you might write Net\Finger; back then, Net_Finger served a similar purpose through naming convention alone.

What this section tells us

The important point is that the "built-in function layer" and the "library distribution layer" belonged to different cultures.

Also, my conclusion in this article, "regular functions use snake_case", does not come from PEAR. PEAR actually recommended camel-like global function names. My conclusion comes from PHP's built-in function culture and practical modern PHP context, not directly from PEAR.

5. PHP 5 and the rise of OOP PHP

What Zend Engine 2.0 changed

PHP 5 was released in July 2004. It introduced Zend Engine 2.0 and a new object model (PHP: History of PHP - Manual). The biggest technical change was how objects behaved.

In PHP 4, passing or assigning objects could internally copy them.
In PHP 5, objects were handled through handles, closer to references in many object-oriented languages.
Access modifiers such as private, protected, and public were introduced.
interface and abstract class were introduced.
Magic methods such as __construct and __destruct were clarified.

What are magic methods?
Magic methods are special methods that begin with two underscores, such as __construct(). PHP calls them automatically at specific moments, such as when an object is created.

These changes made PHP a language where serious class design became practical. This became the foundation for object-oriented PHP culture.

From calling functions to writing methods

The look of PHP code also started changing around this period.

// PHP 4-ish: calling functions
array_map($callback, $items);
json_encode($payload);

// PHP 5 and later: writing methods
$request->getParsedBody();
$response->getStatusCode();

Method names such as getParsedBody(), getStatusCode(), findById(), setCreatedAt(), hasPermission(), and isPublished() became common. The get / set / is / has patterns are common not only in PHP, but also in many object-oriented programming communities.

PHP 5 is where PHP really started to develop a culture of thinking about names at the method level.

6. Framework culture in the late 2000s

Frameworks that adopted camelCase methods

After PHP 5, frameworks and libraries such as CakePHP, Symfony, Zend Framework, Doctrine, and CodeIgniter appeared and grew.

Here is a rough summary of their method naming tendencies, based on what I was able to check. This is not an exhaustive verification of every version or module.

Project	Type	Method naming tendency	General character
CakePHP	Full-stack framework	camelCase	Convention-over-configuration MVC framework
Symfony	Full-stack framework	camelCase	OOP-oriented components and framework
Zend Framework	Framework / library collection	camelCase	Enterprise-oriented design
Doctrine	ORM library	camelCase	Maps database tables to objects
CodeIgniter	Lightweight framework	More snake_case-oriented	Simplicity closer to procedural PHP

What is an ORM?
ORM stands for Object-Relational Mapping. It maps database tables to program objects. Doctrine is one of the best-known ORM libraries in PHP.

As this table suggests, many major frameworks except CodeIgniter leaned toward camelCase method names. CodeIgniter is an important counterexample: not everything in that era was camelCase. It kept a style closer to procedural PHP and PHP's built-in function culture. I could not fully verify an official primary-source statement for that design intent, so I am treating it as a broad tendency rather than a definitive claim.

From here on, some of this is circumstantial

Next comes the question: why did PSR-1 choose camelCase for methods?

To be honest, I could not find a primary source that directly explains the reasoning behind that choice. So from here, I am presenting a hypothesis based on circumstantial evidence.

Hypothesis: camelCase culture was already widespread

My hypothesis is this:

PSR-1 did not introduce camelCase to PHP from nowhere. Instead, it formalized and stabilized a camelCase culture that had already spread through object-oriented PHP frameworks by the late 2000s.

To support that hypothesis, we need to look at PHP-FIG.

7. A side note on Symfony helpers

Symfony 1.x code and documentation reveal an interesting detail. In the Symfony 1.x coding standards, class names and variable names were generally expected to use UpperCamelCase, also called PascalCase, but there were two exceptions: core classes prefixed with lowercase sf, such as sfController and sfRequest, and template variables, which used underscore-separated notation (Symfony 1.4 legacy documentation: Exploring Symfony's Code).

I want to be careful here. In an earlier draft, I had written a more specific anecdote: that the Symfony documentation explained helper functions were not camelCase because helpers were functions, and therefore followed PHP core functions. When I rechecked primary sources, I could not confirm that specific Q&A-style explanation. What I did find was the documented rule about underscore notation for template variables.

So I will avoid stating that helper explanation as fact.

Still, the verified fact is useful: Symfony 1.x mostly used camelCase/PascalCase conventions for classes and variables, while some areas followed different conventions. This shows that two cultures coexisted even within the same framework:

a procedural, PHP-built-in-function-like culture
an OOP framework, camelCase-oriented culture

That coexistence supports the way this article separates functions and methods.

8. PHP-FIG and PSR

What is PHP-FIG?

The group behind PSRs is PHP-FIG.

What is PHP-FIG?
PHP-FIG stands for PHP Framework Interop Group. It is a group created by PHP framework developers to improve interoperability across the PHP ecosystem.

According to the official PHP-FIG FAQ, the group was formed in 2009 at the php|tek conference by several framework developers. It started with around five members and later grew through a voting process to include more than twenty member projects (PHP-FIG FAQ).

What is php|tek?
php|tek is a conference for the PHP community.

Here is another fact-checking note. In an earlier draft, I listed specific founding members and associated projects, such as Matthew Weier O'Phinney for Zend Framework, Fabien Potencier for Symfony, Paul M. Jones for Solar/Aura, Jonathan Wage for Doctrine, and Nate Abele for Lithium. However, I could not find a primary source on the PHP-FIG website that explicitly identifies the original five people.

After additional research, I found a retrospective explanation by a participant on the early php.standards mailing list. It says that the group that became PHP-FIG included representatives from projects such as Agavi, CakePHP, PEAR, Phing, Solar, Symfony, and Zend Framework.

Combining that information with individual profiles and project histories, such as official Zend/Laminas pages and interviews, gives us this rough argument:

People associated with early PHP-FIG were involved in these projects.
Many of those projects already leaned toward camelCase method names.
Therefore, the early PHP-FIG ecosystem was already strongly connected to camelCase-oriented OOP PHP culture.

Person	Project associated at the time	Method naming tendency
Matthew Weier O'Phinney	Zend Framework	camelCase
Paul M. Jones	Solar	camelCase
Nate Abele	CakePHP at the time, later Lithium	camelCase
Fabien Potencier	Symfony	camelCase
Representative names not fully confirmed	PEAR / Phing / Agavi	PEAR recommended camel-like global functions; Phing and Agavi not verified here

Two cautions:

First, this is not a definitive mapping of the original five founding members in 2009. It is a combination of early project names and people known to be associated with them.

Second, I removed the Jonathan Wage / Doctrine pairing from the table because I could not verify it from primary sources during this research.

Even with those cautions, the evidence I could confirm still supports the idea that early PHP-FIG was surrounded by projects where camelCase methods were already common.

Interoperability was the keyword

PHP-FIG's goal was interoperability.

What is interoperability?
Interoperability is the ability of different software systems to work together. In PHP-FIG's context, it means code written for one framework should be easier to combine with code from another framework.

The goal was to make shared PHP code, cross-framework libraries, and reusable components easier to mix together. One of the first topics PHP-FIG worked on was coding style, which later became PSR-1 and PSR-12.

PHP-FIG has produced many standards beyond naming and formatting. PSR-3 defines a logging interface, PSR-4 defines an autoloading standard, and PSR-7 defines common HTTP message interfaces. PHP-FIG is not only about coding style; it is about interoperability across the PHP ecosystem.

9. What PSR-1 says, and what it does not say

The purpose of PSR-1

PSR-1, formally called "Basic Coding Standard", describes its purpose like this (PSR-1: Basic Coding Standard):

This section of the standard comprises what should be considered the standard coding elements that are required to ensure a high level of technical interoperability between shared PHP code.

In other words, PSR-1 defines basic coding elements needed for shared PHP code to interoperate well.

What PSR-1 defines

PSR-1 defines the following naming conventions:

Target	Rule
Class names	`StudlyCaps`
Class constants	`UPPER_CASE_WITH_UNDERSCORES`
Method names	`camelCase()`

What is StudlyCaps?
StudlyCaps means writing words together with each word starting with an uppercase letter. It is roughly equivalent to what many people call PascalCase, for example HttpClient.

For property names, PSR-1 does not require one specific convention. It says $StudlyCaps, $camelCase, and $under_score are all acceptable, but whichever convention is used should be applied consistently within a reasonable scope.

PSR-12, "Extended Coding Style", adds more detailed rules for indentation, line breaks, class and method declarations, control structures, and so on. But it does not add a new rule such as "variables must be camelCase."

What PSR-1 does not define

This distinction is the most important point for this article. PSR-1 does not define naming rules for:

regular global functions
variable names
existing PHP built-in functions

So the claim "Because PSR exists, PHP functions should be camelCase" does not follow from PSR-1 itself.

Why built-in functions do not look like PSR

The reason is simple: many built-in functions existed long before PSR. Renaming them now would break backward compatibility. Also, PSR-1 was never meant to impose naming rules on PHP's built-in functions.

Why PSR does not look like built-in functions

This part cannot be proven definitively from the sources I found. But based on the evidence from sections 6, 7, and 8, I think the most natural reading is:

PSR-1 did not invent camelCase from scratch. It formalized the camelCase method culture already common in userland OOP frameworks at the time.

As a side note, PSR-1 has a Meta Document that lists Paul M. Jones as an editor (PSR-1 Meta Document). According to Paul M. Jones's own blog post from June 4, 2012, PSR-1 and PSR-2 were accepted by vote, with PSR-1 passing 17 to 0 (Paul M. Jones: PHP-FIG: PSR-1 and PSR-2 Accepted).

In an earlier draft, I wrote that PSR-1 was released on June 5, 2012. The primary source I confirmed is the June 4, 2012 blog report, and I could not confirm the exact vote closing date. So this article uses the more cautious phrasing "accepted in early June 2012." It is also more accurate to say "PHP-FIG created PSR-1, and Paul M. Jones was one of its editors" than to say simply "Paul M. Jones created PSR-1."

10. Why naming still hurts

PHP does not enforce naming conventions at the syntax level. Variables, functions, and methods can be snake_case, camelCase, PascalCase, or something else, and PHP will usually run the code.

This has both benefits and costs.

Benefit: Beginners can start writing PHP without worrying about naming rules, which lowers the learning barrier.
Cost: Once code is written by a team, naming inconsistencies become visible in code review and hurt readability.

Personally, I have often been confused by code whose naming style was mixed, especially code written without knowledge of PHP's history or PSR, including code I wrote myself in the past.

I do not think this means the original author was bad. It is a consequence of PHP itself: you can write working code without knowing the conventions.

That is why it helps to know the history and then decide what your own project should do.

11. Practical guidelines for modern PHP

Based on the history above, here are the factors I would consider in real projects:

PHP built-in function culture
OOP culture
PSR rules
project consistency
framework conventions
public API compatibility

Common arguments from both sides

In practice, this debate usually produces arguments like these. Both sides have reasonable points. This article is not trying to prove one style superior to the other.

Camp	Common argument
snake_case	Matches PHP built-in functions; word boundaries are visually clear; less worry about uppercase/lowercase typos
camelCase	Matches PSR-1 for methods; aligns with OOP culture in Java, JavaScript, C#, and others; fits major framework conventions

My position is that we can reconcile both sides by separating the layer: inside classes or outside classes.

Here is the concrete recommendation:

Use snake_case for global functions, helper functions, and procedural APIs.
- Reason: This aligns with PHP's built-in function culture and keeps procedural code visually consistent with the standard library.
Use camelCase for class methods.
- Reason: This follows OOP PHP culture and PSR-1.
For properties and variables, PSR-1 does not prescribe one rule, so prioritize consistency within the relevant scope.

And again, always prioritize these rules when they apply:

If a project already consistently uses snake_case methods, follow that project.
Respect the conventions of the surrounding ecosystem, such as Laravel, Symfony, or WordPress.
For public APIs, preserving backward compatibility comes first.

Before and after

Suppose you have a class with mixed naming:

// Before: inconsistent method names
class UserRepository
{
    public function find_by_id($id) { /* ... */ }
    public function GetAll() { /* ... */ }
    public function delete_user($id) { /* ... */ }
}

Applying this article's guideline, class methods become camelCase:

// After: methods unified as camelCase
class UserRepository
{
    public function findById($id) { /* ... */ }
    public function getAll() { /* ... */ }
    public function deleteUser($id) { /* ... */ }
}

But helper functions outside a class remain snake_case:

// Plain helper functions outside classes stay snake_case
function format_currency($amount) { /* ... */ }

The practical rule is: separate by whether the name belongs inside a class or outside one.

Here is the decision flow:

flowchart TD
    A[You need to choose a name] --> B{Does the project already have a convention?}
    B -->|Yes| C[Follow it]
    B -->|No| D{Does the framework have a convention?}
    D -->|Yes| C
    D -->|No| E{Is it a class method?}
    E -->|Yes| F[camelCase]
    E -->|No| G{Is it a global function or helper?}
    G -->|Yes| H[snake_case]
    G -->|No| I[Other cases: prioritize consistency within scope]

These conventions can also be checked mechanically instead of relying only on human review.

What is static analysis?
Static analysis means analyzing source code without running it, usually to detect possible bugs, type issues, or style violations. In PHP, PHPStan is one of the most widely used static analysis tools.

Tools such as PHP_CodeSniffer, which can detect and automatically fix coding style violations, and PHPStan, which performs static analysis, can help teams enforce PSR-1/PSR-12 and other style rules consistently.

12. Summary

To summarize:

PHP naming conventions are not one single unified system.
PHP built-in function culture, PEAR/library culture, OOP framework culture, and PSR culture exist as historical layers.
Looking at that history, "functions use snake_case, methods use camelCase" feels like a natural practical guideline.
But it is not an absolute rule. Existing project conventions, framework conventions, and backward compatibility always come first.

I was never especially good at history classes in school, but researching PHP's history was genuinely fun. If this article made you a little more curious, I would be happy. And if it makes you want to dig into the later history of PSR-2 to PSR-12, or the changes brought by PHP 7 and PHP 8, that would be even better.

References

If You Can Give a Lightning Talk, You Can Probably Go Bungee Jumping

Hirohisa Tanaka — Sat, 08 Aug 2026 12:42:03 +0000

If You Can Give a Lightning Talk, You Can Probably Go Bungee Jumping

I have a question for anyone who has ever given a lightning talk.

Do you remember those few dozen seconds right before you walked on stage?

Do you remember what was happening to your body?

I do.

In fact, this article itself started as something I talked about during a lightning talk. And while I was speaking, a strange thought suddenly popped into my head:

“Wait. Aren’t lightning talks kind of like bungee jumping?”

Written down like that, it sounds like an absurd claim.

I know.

But at least in my own experience, the excitement I feel right before stepping onto a stage is surprisingly similar to what I feel when standing on a bungee platform and looking down.

So in this article, I want to develop the ridiculous-sounding claim in the title — “If you can give a lightning talk, you can probably go bungee jumping” — while keeping the casual spirit of the original idea and giving it at least some concrete reasoning.

If, by the end of this article, the thought “Bungee jumping sounds kind of interesting” appears in your head before “Lightning talks are scary,” then this article has accomplished its mission.

The Nervousness Before a Lightning Talk and the Fear Before a Bungee Jump

That restless feeling right before a lightning talk is probably nervousness.

The similar feeling right before a bungee jump is probably fear.

Strictly speaking, these are different emotions.

Nervousness comes from uncertainty: Can I do this well?

Fear comes from perceived danger: Am I safe?

Their causes are completely different.

But if we move one level higher and look at what the body actually does, the two experiences start looking surprisingly similar.

Your heart rate increases.

Your palms get a little sweaty.

Your breathing becomes shallow.

You cannot quite settle down.

And somehow, two contradictory thoughts exist at the same time:

“I want to escape.”

and

“I still want to do this.”

More importantly, the peak of that reaction happens before the experience actually begins.

With a lightning talk, the most nerve-racking moment is often right before stepping onto the stage, or just before opening your slides and saying the first sentence.

Once you actually start talking, the nervousness tends to drop very quickly.

Bungee jumping feels similar.

Standing on the platform, having the equipment checked, and finally looking down is the scariest part.

Once you jump, fear is no longer the only thing occupying your brain.

There is another similarity too: once the experience begins, your body almost seems to take over.

Once you start a lightning talk, your main remaining option is to keep talking.

Once you jump off a bungee platform, continuing to fall is no longer exactly optional.

That structure — the moment where starting removes most of your ways to back out — might be one of the biggest reasons why the two experiences feel so similar to me.

`===` Is False, but `==` Might Be True

Obviously, a lightning talk and bungee jumping are completely different activities.

A lightning talk is an intellectual activity where you share ideas with an audience.

Bungee jumping involves physically falling from a very high place while attached to a cord.

The actions are different.

The skills involved are different.

The risks are definitely different.

If we borrow a programming metaphor:

lightningTalk === bungeeJumping
// false

Strict equality does not hold.

But what if we narrow the comparison?

What if we only compare these three things?

The emotional peak happens before starting.
Once it starts, time feels extremely short.
After it ends, you somehow want to do it again.

Under those conditions, at least in my head:

lightningTalk == bungeeJumping
// surprisingly true

If we allow a little type coercion, they start looking oddly equivalent.

But if we require both the type and value to match exactly, of course they are not.

That is roughly the level of seriousness with which this entire article should be read.

Comparing Lightning Talks and Bungee Jumping

To make the argument slightly more structured, here is a direct comparison.

Perspective	Lightning Talk	Bungee Jumping
Before it starts	Nervousness reaches its peak	Fear reaches its peak
After it starts	Time feels extremely short	Time feels extremely short
After it ends	You want to speak again	You want to jump again

The first similarity is that the emotional peak happens before the activity begins.

For a lightning talk, it happens right before going on stage.

For a bungee jump, it happens when you are standing on the platform and looking down.

In my experience, the anxiety or fear rarely gets stronger after starting.

The second similarity is how short the experience feels once it begins.

Lightning talks are usually around five to ten minutes long, and once you start speaking, they tend to end much faster than expected.

A bungee jump is even shorter.

The period between jumping and reaching the end of the fall is only a matter of seconds, and subjectively it feels even shorter.

The third similarity is that immediately afterward, you want to do it again.

After a lightning talk, I often find myself thinking:

“What should I talk about next?”

After bungee jumping, strangely enough, I get a similar feeling:

“I kind of want to jump again.”

This is entirely based on my own experience.

I have no scientific evidence that everyone reacts this way.

But at least for me, it happens almost every time.

What About Other Types of Public Speaking?

At this point, there is an obvious question.

If public speaking in general feels similar to bungee jumping, why specifically talk about lightning talks?

My answer is that not every kind of speaking feels the same.

The speaking activities I have personally experienced can roughly be divided into three categories:

Lightning talks
Regular conference or seminar talks
Hands-on workshop instruction

Out of these, lightning talks feel the most like bungee jumping.

A normal conference or seminar presentation tends to be much longer.

It might last thirty minutes, an hour, or sometimes even longer.

When you speak for that long, the nervousness gradually fades during the presentation. At some point, it starts feeling almost routine.

That is not a bad thing.

Preparing a longer presentation forces you to research the topic more deeply.

The research itself often improves your understanding as an engineer.

Questions from the audience and the preparation process can also expose gaps in your own knowledge.

Those are all valuable things.

But on the specific axis of “How similar is this to bungee jumping?”, they do not matter very much.

A long presentation feels less like jumping and more like walking a long distance until you finally reach the destination.

Hands-on workshops are even more different.

During a workshop, teaching is only part of the job.

You also deal with:

Differences between participants’ environments
Mysterious errors
Dependencies that refuse to install
Sample code that suddenly stops working
Problems that somehow only happen on one person’s machine

I enjoy that too.

But once a workshop begins, the dominant feeling is not “I’m jumping.”

It is closer to:

“I am operating a live system.”

So among the kinds of speaking I have experienced, lightning talks still feel the most similar to bungee jumping.

They are short.

The emotional peak happens right before the start.

And after they end, you often want to do them again.

The Scariest Part Is Before the Jump

There is an obvious response to everything I have written so far:

“Bungee jumping is scary.”

Yes.

It is.

I am not going to pretend otherwise.

But for me, most of that fear is concentrated before the jump.

You stand on the platform.

You look down.

You suddenly understand exactly how high you are.

That moment is genuinely scary.

But once you actually jump, the experience becomes surprisingly short.

The falling sensation is somewhat similar to the drop on a roller coaster.

There is definitely excitement after the jump begins, but the highest concentration of emotion exists in the moments before it.

Lightning talks work in a similar way.

The strongest nervousness usually happens before the talk.

After it ends, instead of thinking only about how stressful it was, I naturally start wondering what I should speak about next.

The important point is not that fear or nervousness disappears.

It is understanding where the peak actually happens.

And in both experiences, the peak comes before the beginning.

Commitment Makes Backing Out Harder

There is one more major similarity between lightning talks and bungee jumping.

Making a commitment in advance makes it harder to back out later.

Before submitting a lightning talk proposal, you can keep telling yourself:

“Maybe I’ll speak someday.”

There is no problem with that.

But once you submit the talk, something changes.

Your name is now attached to a future event.

You have accepted the role of “the person who is going to speak.”

That suddenly turns a vague idea into an actual commitment.

Now you have to make the slides.

You have to research the topic.

You have to prepare.

Bungee jumping has a similar structure.

Thinking:

“I want to try bungee jumping someday.”

can remain a vague idea forever.

But saying publicly:

“I’m going bungee jumping.”

makes the idea slightly more real.

Your psychological escape route gets a little narrower.

And personally, I find that process strangely entertaining.

Of course, this is not an argument for forcing people into things they genuinely cannot or do not want to do.

The idea is much lighter than that.

Sometimes, making a half-joking, half-serious commitment is enough to make your future self actually move.

Sign Up for a Lightning Talk So You Can Go Bungee Jumping

You might have reached this point thinking:

“Bungee jumping still sounds difficult, but maybe I could try a lightning talk.”

Unfortunately, that is not quite the order I am proposing.

I am suggesting that you give a lightning talk so that you can eventually go bungee jumping.

Submitting a lightning talk is a useful exercise in creating commitment.

It teaches you how to turn:

“Maybe someday.”

into:

“Okay. I guess I’m actually doing this.”

And compared with jumping off a tall platform, a five-minute talk is a relatively manageable first step.

That said, once you submit a lightning talk, another problem appears:

What do you actually do next?

Here is roughly how I prepare.

First, I research the topic as broadly as possible.

I look through official documentation, related articles, implementation examples, old notes, and anything else that seems remotely relevant.

At this stage, I intentionally avoid narrowing the scope too early.

Then I dump everything into a note-taking app or Markdown file.

I do not worry about structure.

I write bullet points.

I nest ideas.

I add random observations.

I leave things in even when I am not sure whether they will be useful later.

Once I have accumulated roughly ten thousand Japanese characters’ worth of material, I finally start thinking seriously about the structure of the talk.

Only then do I decide what to keep and what to remove.

For me, trying to create a clean structure from the beginning often causes the work to stall because I simply do not have enough raw material yet.

So instead, I prefer to collect too much information first and cut it down afterward.

I also find it useful to bounce ideas off AI tools.

Ideas that seem perfectly connected inside my own head often reveal logical gaps when I try to explain them to someone else.

Even when the conversation partner is an AI, questions such as:

“How strongly can you actually support that claim?”

“What should the audience take away from this?”

can force me to organize my thoughts much more clearly.

Okay, So Who Wants to Go Bungee Jumping?

So, after all of that, here is my conclusion:

If you can give a lightning talk, I think you can probably go bungee jumping too.

If we inspect the two activities strictly, there are obviously countless differences.

But if we only compare these three things:

The emotional peak happens before starting.
Once it starts, time feels extremely short.
After it ends, you somehow want to do it again.

Then I think lightning talks and bungee jumping are surprisingly similar experiences.

And perhaps the most important part is the act of commitment itself.

You make a decision in advance.

You slightly reduce the number of escape routes available to your future self.

And somewhere inside that situation, fear and excitement start existing at the same time.

So yes.

I recommend bungee jumping.

Half as a joke.

Half seriously.

Whether you actually jump is entirely up to you.

But if this article made you even slightly curious about it, feel free to reach out.

Maybe we should go jump together someday.

I Built a Bridge for Google's New WebMCP Draft Spec — Here's What Broke

Hirohisa Tanaka — Mon, 03 Aug 2026 10:22:51 +0000

Hi, everyone.
I usually go by tanahiro2010 in Japan.
I'm a member of GDG Greater Kwansai.
I gave the first-half talk at the Google I/O Extended Osaka 2026 hands-on session, "Let's Build WebMCP and Call It from an AI Agent!"
This is a write-up of that hands-on session for Qiita (translated here for Dev.to).
Here's the codelab we used:
https://learn.gdgs.jp/webmcp-agent/

This is for people who already know MCP but have never heard of WebMCP, and for people who want to know "so what's this new spec Google put out, actually like?"

Have you heard of WebMCP?

Let me just ask straight up: have you heard of WebMCP?
I hadn't even heard it existed until I started putting together the hands-on materials.
Just from the name, I assumed it was "the Web version of MCP."
But once I actually read the spec and implemented it, it turned out to be a much quirkier spec than I expected.
In this article I'll walk through what's actually in it, and what I learned by getting my hands dirty with it.

First, what is MCP?

Before getting into WebMCP, let's recap MCP (Model Context Protocol).
MCP is a common interface for connecting external tools to an AI Agent.
The flow looks like this:

sequenceDiagram
    participant Agent as AI Agent
    participant Server as MCP Server
    Agent->>Server: Launch (stdio / HTTP)
    Server-->>Agent: tools/list (list of available tools)
    Agent->>Server: tools/call (tool name + args)
    Server->>Server: Execute the tool
    Server-->>Agent: Return the result

The key point is that the tools stay registered for as long as the Agent is running.
Whether it's a local file operation or a tool that hits an internal API, you can keep calling it as long as you don't kill the Agent.
The webmcp-bridge-mcp I built for this is also just an ordinary MCP Server listening on stdio.
From the perspective of a client like the Antigravity CLI, it's nothing more than "one more run-of-the-mill MCP Server."
What's unusual is the WebMCP side, which I'll get to next.

What is WebMCP?

WebMCP is a draft spec published by the W3C Web Machine Learning Community Group.
https://webmachinelearning.github.io/webmcp/
As of writing, it's the February 2026 draft — still at the proposal stage.

In one sentence:

A mechanism by which a web page itself declares its own features as tools for an Agent.

There are two ways to register a tool.

Imperative

You register a tool directly from JavaScript.

await document.modelContext.registerTool({
  name: "reserve_hotel",
  description: "Reserve a hotel",
  inputSchema: {
    type: "object",
    properties: { city: { type: "string" } },
    required: ["city"],
  },
  execute: async ({ city }) => ({ ok: true, city }),
});

The shape — name / description / inputSchema / execute — is almost identical to an MCP tool definition.
Anyone who's touched MCP will look at this and immediately think, "oh, this is the same shape as that."

Declarative

You turn an existing <form> into a tool just by adding attributes to it.

<form toolname="search_hotels" tooldescription="Search hotels">
  <input name="city" toolparamdescription="City to search hotels in" required />
  <button type="submit">Search</button>
</form>

When a form with toolname / tooldescription is found, a JSON Schema is automatically assembled from each <input>'s name, required, and toolparamdescription (or, if that's absent, the text of the associated <label>).

Here's the interesting part: internally, the declarative form gets normalized into the same registerTool() call as the imperative form.
Rather than having two separate APIs, the declarative form is implemented as syntactic sugar over the imperative one.
Personally, I genuinely like this design.

The submission result is received via SubmitEvent#respondWith(), as specified.

form.addEventListener("submit", (event) => {
  event.preventDefault();
  if (event.agentInvoked) {
    event.respondWith(Promise.resolve({ ok: true /* ... */ }));
  }
});

event.agentInvoked lets you tell whether a human clicked the button or an Agent submitted the form.
It's a small detail, but it ends up mattering a lot later.

MCP and WebMCP: similar names, but...

Because the name and the shape of the API are so similar, my initial impression was roughly "it's just the Web version of MCP."
But once I actually dug in, they turned out to differ clearly along three axes.

Item	MCP	WebMCP
Target	AI Agents in general	Per the spec, mainly browser-embedded Agents
Registration timing	Once, at Agent startup	Every time the page is opened
Session lifetime	Until the Agent is terminated	Only while the page is open
Execution location	Local or a service server	Inside that browser, on that page

The difference I felt most viscerally was the session lifetime.

stateDiagram-v2
    [*] --> Unavailable
    Unavailable --> Available: Open the tab
    Available --> Unavailable: Close/leave the tab
    Unavailable --> Available: Return to the tab

An MCP tool can be called as long as the Agent is up and running.
But a WebMCP tool is completely tied to "whether that page is currently open."
The moment you switch tabs, that tool disappears from view; go back, and it reappears.
The idea that "the tab's lifetime = the tool's lifetime" felt pretty fresh to someone coming from an MCP-only mindset.

How much of it actually works, as of August 2026

As of this writing (August 2026), WebMCP is still a draft at the proposal stage.
Even Chrome's own docs introduce it as an "upcoming feature."
https://developer.chrome.com/docs/ai/webmcp?hl=ja

You can join the Origin Trial starting with Chrome 149
To just try it locally, use chrome://flags/#enable-webmcp-testing
It's explicitly noted that the API may still change

In other words, you can't assume "the native implementation is enabled in every attendee's browser at the hands-on venue."
This is where the thing I built comes in.

What I built — WebMCP Bridge

There was a genuine gap between the hands-on requirements and the WebMCP spec if you approached it head-on.

What the spec assumes: WebMCP is for browser-embedded Agents
The reality of the hands-on: participants wanted to call it from an existing MCP-capable Agent, like the Antigravity CLI

So, I decided to build something to bridge the two.
With that in mind, I built a Chrome Extension and an MCP Server as a set.

MCP Server: https://github.com/tanahiro2010/webmcp-bridge-mcp
Chrome Extension: https://github.com/tanahiro2010/webmcp-bridge-extension

There's one thing I was particular about here:

Only detect and execute the APIs defined by the WebMCP spec (document.modelContext / annotated <form>s) as-is.

I didn't want to override the spec with some custom protocol of my own.
The reason is simple: if what people learn in the spec and what actually runs end up diverging, there's no point in running the hands-on in the first place.

Overview of the Bridge

Here's the overall structure:

flowchart LR
    Agent["AI Agent<br>(e.g. Antigravity CLI)"]
    MCP["webmcp-bridge-mcp<br>(MCP Server)"]
    Ext["webmcp-bridge-extension<br>(Chrome Extension)"]
    Page["Web page<br>(WebMCP-enabled)"]
    Agent <-->|stdio, MCP| MCP
    MCP <-->|WebSocket| Ext
    Ext <-->|content/injected script| Page

The MCP Server (webmcp-bridge-mcp) never touches the DOM directly itself.
It sticks strictly to being a Bridge / Registry / Router between itself and the Extension, and leaves all DOM manipulation to the Extension side.
It's a fairly unglamorous division of labor, but the responsibilities are clear, and I had few doubts while implementing it.

The WebSocket binds to ws://127.0.0.1:58787.
I used 58787 instead of 8787 because 8787 collided with the default port for wrangler dev (Cloudflare Workers).
When I had Workers development running in parallel, the Extension would end up connecting to wrangler instead of my server, and I'd sit there wondering why nothing would connect — a fairly unglamorous bug I ran into early on.

The Extension side is MV3-based and has a two-layer structure.

flowchart TB
    subgraph Page["Inside the web page"]
        direction TB
        Injected["injected.ts<br>(main world)"]
        Content["content.ts<br>(isolated world)"]
        Injected <-->|postMessage| Content
    end
    Background["background.ts<br>(Service Worker)"]
    WS["MCP Server"]
    Content <-->|chrome.runtime| Background
    Background <-->|WebSocket| WS

The reason injected.ts needs to run in the main world is that accessing the page's document.modelContext requires running in the main world.
You can't touch it directly from the isolated world (a normal content script).
When document.modelContext isn't yet natively implemented in the browser, injected.ts provides a minimal polyfill for registerTool / getTools / executeTool / the toolchange event.
If a native implementation exists, it does nothing.
By designing it as "quietly defer if a native implementation exists," I expect I won't need major code changes even as native implementations roll out.

Tools visible to the Agent

There are six tools visible to the Agent:

Tool	Description
`webmcp_get_status`	Returns the Extension's connection state, number of known tabs, and the active tab ID
`webmcp_list_tabs`	Returns the list of WebMCP-enabled tabs the Extension has captured
`webmcp_discover_tools`	Discovers the WebMCP tools on a given tab
`webmcp_call_tool`	Executes a tool on a given tab
`webmcp_submit_tool`	Confirms a submission that's waiting on a human, from the Agent side
`webmcp_ping`	Checks connectivity with the Extension

Here's what the input/output look like:

// webmcp_discover_tools input
{ "tabId": 123, "forceRefresh": true }
// output
{ "tabId": 123, "tools": [ { "id": "reserve_hotel", "name": "reserve_hotel", "source": "imperative" } ] }

// webmcp_call_tool input
{ "toolId": "reserve_hotel", "args": { "city": "Osaka" } }
// output
{ "ok": true, "result": { "ok": true, "city": "Osaka", "confirmationId": "RES-12345" } }

webmcp_submit_tool is a bit unusual.
Per the spec, a declarative form without toolautosubmit is expected to stop by focusing the submit button, so that a human reviews the content and submits manually.
This is a safety mechanism intentionally built into the WebMCP spec.
webmcp_submit_tool is a tool for explicitly overriding that from the Agent side.
I've written a note in the README that this should only be used with the understanding that it bypasses the human confirmation the spec intends.

Running it on real hardware, it was riddled with landmines

This is the part I most wanted to write about in this article.
Things I never would have noticed just from reading the docs kept popping up once I actually ran it on Chrome for Testing.

`getTools()` turned out to be async

From skimming the summary in Chrome's developer docs, my impression was that it was a synchronous function.
But when I checked on real hardware (Chrome for Testing 150), document.modelContext.getTools() returned a Promise<ModelContextTool[]>.
On top of that, executeTool() doesn't take a tool-name string — it requires the actual tool object obtained from getTools().
Pass it a string, and you get a TypeError.
This was a spot where implementing based only on a summary of the docs would trip you up, plain and simple.

On `file://`, the handshake never finishes, for some reason

For postMessage between content.ts and injected.ts, I was using window.location.origin as targetOrigin.
On a page opened via file://, this becomes, for some reason, the literal string "null".
As a result, the handshake never completed at all, and the overlay would never show up.
I'm not sure whether this bug is fully reproducible, but thinking about it more, communication between the main world and isolated world within the same window shouldn't involve the concept of cross-origin at all in the first place.
So I changed targetOrigin to "*", and instead guarantee legitimacy via a random channel ID.
This was the type of bug you only notice by trying it with file://; if I hadn't verified the sample page by opening it directly via file://, I probably would have missed it.

The native implementation registers declarative forms on its own

When a native implementation is present, the browser itself may automatically register declarative forms.
In that case, this Extension's own registerTool() call fails as a "duplicate," but I'm treating that as expected behavior.
Since findAnnotatedFormByName() looks directly at the DOM to determine source: "declarative", it can report correctly regardless of who registered it.
There were also cases where the natively-synthesized inputSchema returned empty ({ type: "object", properties: {} }) on this particular build.
This is probably down to the state of the browser's implementation, not a bug in the Extension.

Tool execution results come back as strings, for some reason

The WebMCP spec's execute is originally meant to return "a string summary for the agent."
Because of that, I confirmed on real hardware that even when the page returns an object like { ok: true, city }, the browser's native implementation JSON-stringifies it before returning.
Neither the Extension nor the MCP Server touch result — they pass it straight through.
So the MCP client side needs to determine whether it got a string or structured data.

The Service Worker falls asleep on its own

An MV3 Service Worker gets suspended when it goes idle.
During that time, the WebSocket connection also drops.
It wakes back up automatically when a chrome.tabs event or similar fires, and the reconnection logic kicks in.
But if nothing happens right after startup — no tab activity at all — it can stay stuck at extensionConnected: false for a while.
If webmcp_get_status / webmcp_ping return false, doing something with the target tab (switching to it, reloading it, etc.) will bring it back.

Tool registration finishes before the handshake, so the overlay never shows up

On declarative-only pages (with no imperative JS at all), there was a race condition where tool registration could complete before the handshake with content.ts finished, leaving the overlay permanently hidden.
injected.ts registers <form toolname tooldescription> elements as soon as it finds them via MutationObserver.
So this race is more likely to occur on lightweight declarative-only pages that don't run any imperative script.
The previous implementation recorded "the manifest was sent / attempted to be sent" before the handshake had actually completed.
As a result, once the handshake did complete, a resend request would be misjudged as "no diff" and silently swallowed.
I fixed reportManifestIfChanged() so that it doesn't record or send anything at all until the channel is established.
I wrote a test that deliberately reproduces the bad ordering (tool registration → delayed handshake), and confirmed it reproduces the bug before the fix and resolves it after.
More than the bug itself, what I felt made the biggest difference was the approach of "write a test that deliberately reproduces the bad ordering, and use it to prove the fix works."

A tool that never comes back until a human clicks

Per the spec, a form without toolautosubmit stops by just focusing the submit button.
This is meant so a human reviews the content and submits manually.
At least some native implementations keep executeTool() itself blocked during this "waiting for a human" period.
This is not the same behavior as this Extension's polyfill, which immediately returns { pending: true, ... }.
If you call webmcp_call_tool on a tool without toolautosubmit in an automated environment with no human interaction, you won't get a response back until it times out.
Before calling it, you need to check whether webmcp_discover_tools's result has requiresUserGesture: true.

Testing: two tiers, with and without a browser

I verified the following four scenarios:

An imperative-only page (no <form>)
A declarative-only page (no registerTool() calls)
A page with a normal mix of imperative and declarative
A pattern where executing one tool changes whether another tool exists (calling unlock makes a new tool dynamically appear, and lock makes it disappear)

I actually loaded the Extension on Chrome for Testing and confirmed all patterns passed.
The fourth one also serves as verification of dynamic detection via the toolchange event and MutationObserver.
Since webmcp_discover_tools returns a cached result by default, you need forceRefresh: true to observe these dynamic changes.

I'm using Chrome for Testing (the Chromium bundled with Playwright) because, from Chrome 137 onward, official Google Chrome builds have removed the --load-extension flag for automation purposes.
Loading an extension manually via chrome://extensions works fine with regular Chrome.
But if you want to load an extension in automated tests, you need Chrome for Testing or Chromium.

On the MCP Server side, I use a mock class called FakeExtension.
It speaks the same WebSocket protocol as the real Extension, and lets me verify — without launching a browser — the connection state, the discover_tools cache/forceRefresh behavior, concurrent tool call execution, and cleanup on disconnect.
Since it doesn't launch a browser, it runs fast, so I split the work: bridge logic gets tested here, and verification that involves actual DOM manipulation goes through the Extension's Playwright tests.

A note on security (this is a prototype)

For postMessage between the main world (injected.ts) and the isolated world (content.ts), a random channel ID is issued once per page load, shared through a one-time handshake, and attached to every subsequent message. This is to prevent unrelated page scripts from injecting a fake manifest or fake execution results.
The MCP Server's WebSocket server binds only to 127.0.0.1, so it can't be connected to from anywhere other than the same machine.

This is built with personal use and prototyping in mind, and doesn't include additional authorization such as token authentication.
I stopped at the line of "good enough to run at the hands-on session" and haven't designed authorization with production use in mind.

Even so, there are real benefits

Even though I put this together somewhat forcefully, there are benefits I genuinely felt after actually using it.

Less guessing: the Agent doesn't have to infer the meaning of buttons or input fields on screen. The site itself can declare its intent as a tool.
Shorter execution: no need to replay a bunch of clicks and inputs — it can be handled directly as a tool call.
Visually verifiable: since it runs in the browser, a human can watch the result happen in real time.

But personally, I don't think it's necessary

From here on, this is entirely my personal opinion.
Honestly, having implemented it and used it at the hands-on session, what I felt most strongly was, "do we really need this?"

There are a few reasons.

First, the motivation to use a browser-embedded Agent is still weak.
Actually, I myself didn't even know Chrome had a built-in Agent until I did this investigation.
I imagine there are quite a few people in the same boat.

And WebMCP has the constraint that it only works while the page is open.
That's subtly restrictive.
Having a tool disappear the moment you switch tabs felt a bit inconvenient, coming from the mindset I'm used to with MCP.

In actual use, I didn't feel a particularly large difference in perceived token usage or execution speed between Agent-driven browser operations and WebMCP-driven ones.
For people who keep an existing Agent like Claude Code or Codex open at all times, I felt the appeal of going out of your way to open a browser-embedded Agent just to use this is pretty thin.

And honestly, from a layperson's perspective, I also wondered if the target audience selection itself might be a bit off.
The benefit itself — "fewer mistaken operations from the Agent" — is appealing.
But it's a bit of a shame that the place where you can realize that benefit is limited to something as little-known as a "browser-embedded Agent."

That said, it will resonate with the right people

That said, for people who use a browser-embedded Agent as part of their daily routine, the two points — "less guessing" and "shorter execution time" — should genuinely land hard.
I think the reason it didn't land as hard for me this time is simply that my own workflow wasn't built around a browser-embedded Agent to begin with.

Why I published this article anyway

Given how harsh some of this has been, you might wonder why I'm publishing it at all.
The reason is simple.
It felt like a waste to build an Extension and an MCP Server and have them only get used on the day of the hands-on session and nothing more.
Even though I have some skepticism about WebMCP as a spec, the technical insights I only gained by actually implementing it and getting my hands dirty — the async API, the origin issue, how I fixed the race condition, and so on — should be useful to someone on their own merits.
Also, if people end up using the extension or the MCP server, that makes me happy.

Summary

WebMCP is, directionally, an interesting spec: "the web page itself declares tools for an Agent."
That said, as of August 2026 it's still at the draft stage, and its target is limited to browser-embedded Agents.
So my personal conclusion is that, at this point, it doesn't land all that strongly for people who are already heavy users of existing MCP-capable Agents.
On the other hand, the pitfalls I found while implementing it — the async API, the origin issue, the race condition — should be useful reference material as native implementations spread further going forward.

Here's what I built and the related links:

Codelab: https://learn.gdgs.jp/webmcp-agent/
WebMCP Bridge MCP: https://github.com/tanahiro2010/webmcp-bridge-mcp
WebMCP Bridge Extension: https://github.com/tanahiro2010/webmcp-bridge-extension
connpass: https://gdgkwansai.connpass.com/event/391029
Original Article: https://qiita.com/tanahiro2010/items/66b7822e2132ec4e0a45

Feel free to check out the repos and reach out with any questions.

DEV Community: Hirohisa Tanaka

Why PHP Uses snake_case Functions but camelCase Methods

Have you seen code like this?

Table of Contents

1. The conclusion first

2. Why PHP built-in functions look like snake_case

PHP did not begin as a carefully designed language

A function culture grew from there

A technical note: why snake_case was likely natural

But it is not completely consistent

3. PHP 3 and the spread of function-based web programming

Once a name is public, changing it is hard

Naming is not decided by philosophy alone

4. PEAR: shared conventions before PSR

What is PEAR?

PEAR naming conventions

PEAR class names as pseudo-namespaces

What this section tells us

5. PHP 5 and the rise of OOP PHP

What Zend Engine 2.0 changed

From calling functions to writing methods

6. Framework culture in the late 2000s

Frameworks that adopted camelCase methods

From here on, some of this is circumstantial

Hypothesis: camelCase culture was already widespread

7. A side note on Symfony helpers

8. PHP-FIG and PSR

What is PHP-FIG?

Interoperability was the keyword

9. What PSR-1 says, and what it does not say

The purpose of PSR-1

What PSR-1 defines

What PSR-1 does not define

Why built-in functions do not look like PSR

Why PSR does not look like built-in functions

10. Why naming still hurts

11. Practical guidelines for modern PHP

Common arguments from both sides

Before and after

12. Summary

References

If You Can Give a Lightning Talk, You Can Probably Go Bungee Jumping

If You Can Give a Lightning Talk, You Can Probably Go Bungee Jumping

The Nervousness Before a Lightning Talk and the Fear Before a Bungee Jump

=== Is False, but == Might Be True

Comparing Lightning Talks and Bungee Jumping

What About Other Types of Public Speaking?

The Scariest Part Is Before the Jump

Commitment Makes Backing Out Harder

Sign Up for a Lightning Talk So You Can Go Bungee Jumping

Okay, So Who Wants to Go Bungee Jumping?

I Built a Bridge for Google's New WebMCP Draft Spec — Here's What Broke

Have you heard of WebMCP?

First, what is MCP?

What is WebMCP?

Imperative

Declarative

MCP and WebMCP: similar names, but...

How much of it actually works, as of August 2026

What I built — WebMCP Bridge

Overview of the Bridge

Tools visible to the Agent

Running it on real hardware, it was riddled with landmines

getTools() turned out to be async

On file://, the handshake never finishes, for some reason

The native implementation registers declarative forms on its own

Tool execution results come back as strings, for some reason

The Service Worker falls asleep on its own

Tool registration finishes before the handshake, so the overlay never shows up

A tool that never comes back until a human clicks

Testing: two tiers, with and without a browser

A note on security (this is a prototype)

Even so, there are real benefits

But personally, I don't think it's necessary

That said, it will resonate with the right people

Why I published this article anyway

Summary

`===` Is False, but `==` Might Be True

`getTools()` turned out to be async

On `file://`, the handshake never finishes, for some reason