8 ms·

Context engineering is sleeping on the humble hyperlink

177 points by mbleigh 11mo ago

jrvarela56 11mo ago
Spot on, this is a solid abstraction to build upon. I always felt MCP was a misstep in comparison to OpenAI’s focus on OpenAPI specs. HATEOAS is the principle that has become more useful as agents drive applications.
alexpetros 11mo ago
> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the API structure in a useful manner anyway. Every time I read one of these comments I feel like DiCaprio's character in Inception going "but we did grow old together." HATEOAS worked phenomenally. Every time you go to a webpage with buttons and links in HTML that describe what the webpage is capable of (its API, if you will), you are doing HATEOAS [0]. That this interface can be consumed by both a user (via the browser) and a web scraper (via some other program) is the foundation of modern web infrastructure. It's a little ironic that the explosion of information made possible by HATEOAS happened while the term it self largely got misunderstood, but such is life. Much like reclaiming the proper usage of its close cousin, "REST," using HATEOAS correctly is helpful for properly identifying what made the world's largest hypermedia system successful—useful if you endeavor to design a new one [1]. [0] https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ [1] https://unplannedobsolescence.com/blog/why-insist-on-a-word/ https://unplannedobsolescence.com/blog/why-insist-on-a-word/
- not_kurt_godel 11mo ago
  I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.
  - ffsm8 11mo ago
    From what I read on wiki, I'm not sure what to think anymore - it does at least sound inline with the opinion that the current websites are actually HATeOAS. I guess someone interested would have to read the original work by Roy (who seems to have come up with the term) to find out which opinion is true
    - not_kurt_godel 11mo ago
      I worked on frontend projects and API designs directly related to trying to achieve HATEOAS, in a general, practical sense, for years. Browsing the modern web is not it.
      - tsimionescu 11mo ago
        I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single endpoint on the server with no prior knowledge of what that endpoint represents, downloads a file from the server, analyzes the Content-Type, and can show the user what the server intends to show based on that Content-Type. The fact that one of these content types is a language for running server-controlled code doesn't influence this one bit. The only thing that would have made the web not conform to HATEOAS were if browsers had to have code that's specific to, say, google.com, or maybe to Apache servers. The only example of anything like this on the modern web is the special log in integrations that Microsoft and Google added for their own web properties - that is indeed a break of the HATEOAS paradigm.
        not_kurt_godel 11mo ago
        I'm not confusing it. I was heavily motivated by business goals to find a general solution for HATEOAS-ifying API definitions. And yes, a web page, implemented in HTML/CSS/JS is a facsimile for it in a certain sense, but it's not self-contained RESTful API definition.
- fellowniusmonk 11mo ago
  I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The front end ui was entirely driven, ui and functionality exposed by the data/action payload. I'm still not sure if it's because of the implementation or because there is something fundemental. I came away from that thinking that the db structure, the dag and data flow is what's really important for thinking about any problem space and any ui considerations should be not first class. But I'm not a theorist, I just found a specific real, real formal working implementation in prod to be not great, it's a little hard even now to understand why. Maybe it just works for purely text interfaces, adding any design or dynamic interaction causes issues. I think maybe it's that the data itself should be first class, that well typed data should exist and a system that allows any ui and behavior to be attached to that data is more important than an api saying what explicit mutations are allowed. If I was to explore this, I think folder and files, spreadsheet, dbs, data structures, those are the real things and the tools we use to mutate them are second order and should be treated as such. Any action that can be done on data should be defined elsewhere and not treated as being the same importance, but idk, that's just me thinking outloud.
  - dpe82 11mo ago
    Was this recently, using something like HTMX? Or years ago using some other system (or pure/standard HTML)?
    - fellowniusmonk 11mo ago
      Within the last 3 years. They had their own open sourced functional typescript framework that drove the front end. You could use whatever lightweight rendering you wanted, mostly it was very minimal react but that hardly mattered. One thing that was a positive was how little the ui rendering choice mattered. I don't really want to say more as it's unique enough to be equivalent to naming the company itself.
  - alexpetros 11mo ago
    > I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS and failed to make it nice is part of why it's so useful to acknowledge as valid the one implementation that has wildly succeeded.
- jdlshore 11mo ago
  HATEOAS is hypertext as the engine of application state. When a person reads a webpage and follows links, it’s not HATEOAS, because the person is not an application. HATEOAS and by-the-book REST don’t provide much practical value for writing applications. As the article says, a human has to read the spec, make sense of each endpoint’s semantics, and write code specific to those semantics. At that point you might as well hardcode the relevant URLs (with string templating where appropriate) rather than jumping through hoops and pretending every URL has to be “discovered” on the off chance that some lunatic will change the entire URL structure of your backend but somehow leave all the semantics unchanged. The exception, as the article says, is if we don’t have to understand the spec and write custom code for each endpoint. Now we truly can have self-describing endpoints, and HATEOAS moves from a purist fantasy to something that actually makes sense.
- mbleigh 11mo ago
  Totally agree, the web itself is absolutely HATEOAS, but there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs, but the only real benefit of those APIs was to enable overly generic API clients that were usually strictly worse than even clumsily tailored custom clients. The missing piece was having machines that could handle enough ambiguity to "understand" the structure of the API without it needing to be generic to the point of uselessness.
  - JimDabell 11mo ago
    > there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs The creator of REST, Roy Fielding, literally said this loud and clear: > REST APIs must be hypertext-driven > What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. — https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... I think of all the people in the world, the creator of REST gets to say what is and isn’t REST.
    - mbleigh 11mo ago
      Fair, but the person who coins a term generally doesn't ultimately decide how it's going to be used, see vibe coding for a more recent example. REST API became colloquially defined as "HTTP API with hierarchical URL structure, usually JSON". I wrote about the very phenomenon 15 years ago! https://www.mobomo.com/2010/04/rest-isnt-what-you-think-it-is/ https://www.mobomo.com/2010/04/rest-isnt-what-you-think-it-i...
- JimDabell 11mo ago
  I agree. The “purist” REST using HATEOAS is the single most successful API architectural style in history by miles. It’s the foundation of the World-Wide Web, which would not have been anywhere near as successful with a different approach.
- _kidlike 11mo ago
  I think you're misunderstanding the purpose of hateoas. If we jump down to the bolts and nuts, let's say on a json API, it's about including extra attributes/fields in your json response that contain links and information of how to continue. These attributes have to be blended with your other real attributes. For example if you just created a resource with a POST endpoint, you can include a link to GET the freshly created resource ("_fetch"), a link to delete it ("_delete"), a link to list all resources of the same collection ("_list"), etc... Then the client application is supposed to automatically discover the API's functionality. In case of a UI, it's supposed to automatically discover the API's functionality and build a presentation layer on the fly, which the user can see and use. From our example above, the UI codebase would never have a "delete" resource button, it would have a generic button which would be created and placed on the UI based on the _delete field coming back from the API
labrador 11mo ago
I just discovered that I can paste a link into a Claude prompt and ask it to follow read the page so we can talk about it. I no longer have to copy the text of the page and paste it in. Claude uses the web_fetch command. So we're heading in the direction this article discusses.
- tmoravec 11mo ago
  Except that more often than not, Claude is blocked from reading the article. This used to work great two years ago when chatgpt first got the Web browsing feature. Nowadays, no eyeballs on ads: no content.
  - hollerith 11mo ago
    Is one of the reasons OpenAI made a browser (Atlas) and Perplexity made Comet and Anthropic made a Chrome extension to make it impossible for the site to tell whether a person or the person's AI assistant is making the request?
  - simonw 11mo ago
    Claude Code running on your machine can switch to "curl" or even Playwright if it needs to.
  - labrador 11mo ago
    It refused to read this complaint about Grok because of the NSFW topic "The irony is they trained their model on so much porn even barely NSFW prompts get flagged because Grok the Goon Commander thinks a simple fully-clothed lapdance requires a visible massive dong being thrusted up her piehole." https://old.reddit.com/r/grok/comments/1ofd6xm/the_irony_is_they_trained_their_model_on_so_much/ https://old.reddit.com/r/grok/comments/1ofd6xm/the_irony_is_...
ako 11mo ago
The article seems a few months too late. Claude (and others) are already doing this: i've been instructing claude code to generate code following certain best practices provided through URLs or asking it to compare certain approaches from different URLs. Claude Skill uses file "URLs" to provide progressive disclosure: only include detailed texts into the context if needed. This helps reduce context size, and improves cachability.
- j45 11mo ago
  That's fair, but not everyone reads and tries every single AI thing every day, or they might not get to applying it.
- mettamage 11mo ago
  Thanks for that. Comments like yours are why I visit this site and don’t have to read the original article. Though in this case, I did read the original article.
- mbleigh 11mo ago
  Heh, the problem with having a half drafted post on your machine for a few weeks is the industry moves fast! I had the post pretty much done, went on vacation for a week, and Claude Skills came out in the interim. That being said Skills are indeed an implementation of the patterns possible with linking, but they are narrower in scope than what's possible even with MCP Resources if they were properly made available to agents (e.g. dynamic construction of context based on environment and/or fetching from remote sources).
  - bradfa 11mo ago
    The problem with MCP resources is someone needs to stand up a server. That’s enough overhead and infrastructure that it slows down creating these kinds of resources and linking. Do any of the popular forge sites have like a GitHub pages but it’s MCP kind of capability? I think that would lower the hurdle for standing up such tooling so it would be much more appealing to actually do.
- fooker 11mo ago
hu3 11mo ago
I wonder if I can instruct LLMs to use my MCP whenever they need to access anything online. So they can bypass AI blocks when I tell them to read some docs online.
- csomar 11mo ago
  This can already be done with Claude Code or most agentic tools. There will be restrictions for online platforms as LLMs are very vulnerable to prompt attacks.
xg15 11mo ago
HATEOAS always seemed a bit like a solution in search of a problem to me. It was a nice idea for more convenient "manual exploration" of APIs if you're a human developer and all you have is curl - but I never understood for what kind of "production" scenario they were designing their constraints. The kind of automated client that could make actual use of the metadata always seemed more of a fantasy. ...until now. It seems they finally found their problem.
CuriouslyC 11mo ago
What you're describing is basically very stripped down versions of pre-SPA web pages. We don't need MCPs for this, just make a tool that uses Trafilatura to read web pages into markdown and create oldschool server side web UIs, and let the agents curl them.
simonw 11mo ago
If you ask Claude Code a question about its own features you can see it using hyperlinks directly, starting with this dedicated markdown index page: https://docs.claude.com/en/docs/claude-code/claude_code_docs_map.md https://docs.claude.com/en/docs/claude-code/claude_code_docs... This is driven by instructions in the Claude Code system prompt: > When the user directly asks about Claude Code (eg. "can Claude Code do...", "does Claude Code have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific Claude Code feature (eg. implement a hook, or write a slash command), use the WebFetch tool to gather information to answer the question from Claude Code docs. The list of available docs is available at https://docs.claude.com/en/docs/claude-code/claude_code_docs_map.md https://docs.claude.com/en/docs/claude-code/claude_code_docs.... Screenshot and notes here: https://simonwillison.net/2025/Oct/24/claude-code-docs-map/ https://simonwillison.net/2025/Oct/24/claude-code-docs-map/
daxfohl 11mo ago
I wonder if append-only will continue to be important. As agents get more powers, their actions will likely be the bottleneck, not the LLM itself. And at n*2, recomputing a whole new context might not take much longer than just computing the delta, or even save time if the new context is shorter.
ramanvarma 11mo ago
isn't this basically rag with a different entrypoint? following links works when the corpus is well-authored/ hierarchical but most real data isn't. how do you handle relevance ranking/stale links/huge fan-out?? "just follow hyperlinks" can blow up the context window just as easily

177 points by mbleigh 11mo ago

Spot on, this is a solid abstraction to build upon. I always felt MCP was a misstep in comparison to OpenAI’s focus on OpenAPI specs. HATEOAS is the principle that has become more useful as agents drive applications.

alexpetros 11mo ago

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the API structure in a useful manner anyway. Every time I read one of these comments I feel like DiCaprio's character in Inception going "but we did grow old together." HATEOAS worked phenomenally. Every time you go to a webpage with buttons and links in HTML that describe what the webpage is capable of (its API, if you will), you are doing HATEOAS [0]. That this interface can be consumed by both a user (via the browser) and a web scraper (via some other program) is the foundation of modern web infrastructure. It's a little ironic that the explosion of information made possible by HATEOAS happened while the term it self largely got misunderstood, but such is life. Much like reclaiming the proper usage of its close cousin, "REST," using HATEOAS correctly is helpful for properly identifying what made the world's largest hypermedia system successful—useful if you endeavor to design a new one [1]. [0] https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ [1] https://unplannedobsolescence.com/blog/why-insist-on-a-word/ https://unplannedobsolescence.com/blog/why-insist-on-a-word/

not_kurt_godel 11mo ago
I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.
- ffsm8 11mo ago
  From what I read on wiki, I'm not sure what to think anymore - it does at least sound inline with the opinion that the current websites are actually HATeOAS. I guess someone interested would have to read the original work by Roy (who seems to have come up with the term) to find out which opinion is true
  - not_kurt_godel 11mo ago
    I worked on frontend projects and API designs directly related to trying to achieve HATEOAS, in a general, practical sense, for years. Browsing the modern web is not it.
    - tsimionescu 11mo ago
      I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single endpoint on the server with no prior knowledge of what that endpoint represents, downloads a file from the server, analyzes the Content-Type, and can show the user what the server intends to show based on that Content-Type. The fact that one of these content types is a language for running server-controlled code doesn't influence this one bit. The only thing that would have made the web not conform to HATEOAS were if browsers had to have code that's specific to, say, google.com, or maybe to Apache servers. The only example of anything like this on the modern web is the special log in integrations that Microsoft and Google added for their own web properties - that is indeed a break of the HATEOAS paradigm.
      - not_kurt_godel 11mo ago
        I'm not confusing it. I was heavily motivated by business goals to find a general solution for HATEOAS-ifying API definitions. And yes, a web page, implemented in HTML/CSS/JS is a facsimile for it in a certain sense, but it's not self-contained RESTful API definition.
fellowniusmonk 11mo ago
I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The front end ui was entirely driven, ui and functionality exposed by the data/action payload. I'm still not sure if it's because of the implementation or because there is something fundemental. I came away from that thinking that the db structure, the dag and data flow is what's really important for thinking about any problem space and any ui considerations should be not first class. But I'm not a theorist, I just found a specific real, real formal working implementation in prod to be not great, it's a little hard even now to understand why. Maybe it just works for purely text interfaces, adding any design or dynamic interaction causes issues. I think maybe it's that the data itself should be first class, that well typed data should exist and a system that allows any ui and behavior to be attached to that data is more important than an api saying what explicit mutations are allowed. If I was to explore this, I think folder and files, spreadsheet, dbs, data structures, those are the real things and the tools we use to mutate them are second order and should be treated as such. Any action that can be done on data should be defined elsewhere and not treated as being the same importance, but idk, that's just me thinking outloud.
- dpe82 11mo ago
  Was this recently, using something like HTMX? Or years ago using some other system (or pure/standard HTML)?
  - fellowniusmonk 11mo ago
    Within the last 3 years. They had their own open sourced functional typescript framework that drove the front end. You could use whatever lightweight rendering you wanted, mostly it was very minimal react but that hardly mattered. One thing that was a positive was how little the ui rendering choice mattered. I don't really want to say more as it's unique enough to be equivalent to naming the company itself.
- alexpetros 11mo ago
  > I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS and failed to make it nice is part of why it's so useful to acknowledge as valid the one implementation that has wildly succeeded.
jdlshore 11mo ago
HATEOAS is hypertext as the engine of application state. When a person reads a webpage and follows links, it’s not HATEOAS, because the person is not an application. HATEOAS and by-the-book REST don’t provide much practical value for writing applications. As the article says, a human has to read the spec, make sense of each endpoint’s semantics, and write code specific to those semantics. At that point you might as well hardcode the relevant URLs (with string templating where appropriate) rather than jumping through hoops and pretending every URL has to be “discovered” on the off chance that some lunatic will change the entire URL structure of your backend but somehow leave all the semantics unchanged. The exception, as the article says, is if we don’t have to understand the spec and write custom code for each endpoint. Now we truly can have self-describing endpoints, and HATEOAS moves from a purist fantasy to something that actually makes sense.
mbleigh 11mo ago
Totally agree, the web itself is absolutely HATEOAS, but there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs, but the only real benefit of those APIs was to enable overly generic API clients that were usually strictly worse than even clumsily tailored custom clients. The missing piece was having machines that could handle enough ambiguity to "understand" the structure of the API without it needing to be generic to the point of uselessness.
- JimDabell 11mo ago
  > there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs The creator of REST, Roy Fielding, literally said this loud and clear: > REST APIs must be hypertext-driven > What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. — https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... I think of all the people in the world, the creator of REST gets to say what is and isn’t REST.
  - mbleigh 11mo ago
    Fair, but the person who coins a term generally doesn't ultimately decide how it's going to be used, see vibe coding for a more recent example. REST API became colloquially defined as "HTTP API with hierarchical URL structure, usually JSON". I wrote about the very phenomenon 15 years ago! https://www.mobomo.com/2010/04/rest-isnt-what-you-think-it-is/ https://www.mobomo.com/2010/04/rest-isnt-what-you-think-it-i...
JimDabell 11mo ago
I agree. The “purist” REST using HATEOAS is the single most successful API architectural style in history by miles. It’s the foundation of the World-Wide Web, which would not have been anywhere near as successful with a different approach.
_kidlike 11mo ago
I think you're misunderstanding the purpose of hateoas. If we jump down to the bolts and nuts, let's say on a json API, it's about including extra attributes/fields in your json response that contain links and information of how to continue. These attributes have to be blended with your other real attributes. For example if you just created a resource with a POST endpoint, you can include a link to GET the freshly created resource ("_fetch"), a link to delete it ("_delete"), a link to list all resources of the same collection ("_list"), etc... Then the client application is supposed to automatically discover the API's functionality. In case of a UI, it's supposed to automatically discover the API's functionality and build a presentation layer on the fly, which the user can see and use. From our example above, the UI codebase would never have a "delete" resource button, it would have a generic button which would be created and placed on the UI based on the _delete field coming back from the API

labrador 11mo ago

I just discovered that I can paste a link into a Claude prompt and ask it to follow read the page so we can talk about it. I no longer have to copy the text of the page and paste it in. Claude uses the web_fetch command. So we're heading in the direction this article discusses.

tmoravec 11mo ago
Except that more often than not, Claude is blocked from reading the article. This used to work great two years ago when chatgpt first got the Web browsing feature. Nowadays, no eyeballs on ads: no content.
- hollerith 11mo ago
  Is one of the reasons OpenAI made a browser (Atlas) and Perplexity made Comet and Anthropic made a Chrome extension to make it impossible for the site to tell whether a person or the person's AI assistant is making the request?
- simonw 11mo ago
  Claude Code running on your machine can switch to "curl" or even Playwright if it needs to.
- labrador 11mo ago
  It refused to read this complaint about Grok because of the NSFW topic "The irony is they trained their model on so much porn even barely NSFW prompts get flagged because Grok the Goon Commander thinks a simple fully-clothed lapdance requires a visible massive dong being thrusted up her piehole." https://old.reddit.com/r/grok/comments/1ofd6xm/the_irony_is_they_trained_their_model_on_so_much/ https://old.reddit.com/r/grok/comments/1ofd6xm/the_irony_is_...

ako 11mo ago

The article seems a few months too late. Claude (and others) are already doing this: i've been instructing claude code to generate code following certain best practices provided through URLs or asking it to compare certain approaches from different URLs. Claude Skill uses file "URLs" to provide progressive disclosure: only include detailed texts into the context if needed. This helps reduce context size, and improves cachability.

j45 11mo ago
That's fair, but not everyone reads and tries every single AI thing every day, or they might not get to applying it.
mettamage 11mo ago
Thanks for that. Comments like yours are why I visit this site and don’t have to read the original article. Though in this case, I did read the original article.
mbleigh 11mo ago
Heh, the problem with having a half drafted post on your machine for a few weeks is the industry moves fast! I had the post pretty much done, went on vacation for a week, and Claude Skills came out in the interim. That being said Skills are indeed an implementation of the patterns possible with linking, but they are narrower in scope than what's possible even with MCP Resources if they were properly made available to agents (e.g. dynamic construction of context based on environment and/or fetching from remote sources).
- bradfa 11mo ago
  The problem with MCP resources is someone needs to stand up a server. That’s enough overhead and infrastructure that it slows down creating these kinds of resources and linking. Do any of the popular forge sites have like a GitHub pages but it’s MCP kind of capability? I think that would lower the hurdle for standing up such tooling so it would be much more appealing to actually do.
fooker 11mo ago

hu3 11mo ago

I wonder if I can instruct LLMs to use my MCP whenever they need to access anything online. So they can bypass AI blocks when I tell them to read some docs online.

csomar 11mo ago
This can already be done with Claude Code or most agentic tools. There will be restrictions for online platforms as LLMs are very vulnerable to prompt attacks.

xg15 11mo ago

HATEOAS always seemed a bit like a solution in search of a problem to me. It was a nice idea for more convenient "manual exploration" of APIs if you're a human developer and all you have is curl - but I never understood for what kind of "production" scenario they were designing their constraints. The kind of automated client that could make actual use of the metadata always seemed more of a fantasy. ...until now. It seems they finally found their problem.

CuriouslyC 11mo ago

What you're describing is basically very stripped down versions of pre-SPA web pages. We don't need MCPs for this, just make a tool that uses Trafilatura to read web pages into markdown and create oldschool server side web UIs, and let the agents curl them.

simonw 11mo ago

If you ask Claude Code a question about its own features you can see it using hyperlinks directly, starting with this dedicated markdown index page: https://docs.claude.com/en/docs/claude-code/claude_code_docs_map.md https://docs.claude.com/en/docs/claude-code/claude_code_docs... This is driven by instructions in the Claude Code system prompt: > When the user directly asks about Claude Code (eg. "can Claude Code do...", "does Claude Code have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific Claude Code feature (eg. implement a hook, or write a slash command), use the WebFetch tool to gather information to answer the question from Claude Code docs. The list of available docs is available at https://docs.claude.com/en/docs/claude-code/claude_code_docs_map.md https://docs.claude.com/en/docs/claude-code/claude_code_docs.... Screenshot and notes here: https://simonwillison.net/2025/Oct/24/claude-code-docs-map/ https://simonwillison.net/2025/Oct/24/claude-code-docs-map/

daxfohl 11mo ago

I wonder if append-only will continue to be important. As agents get more powers, their actions will likely be the bottleneck, not the LLM itself. And at n*2, recomputing a whole new context might not take much longer than just computing the delta, or even save time if the new context is shorter.

ramanvarma 11mo ago

isn't this basically rag with a different entrypoint? following links works when the corpus is well-authored/ hierarchical but most real data isn't. how do you handle relevance ranking/stale links/huge fan-out?? "just follow hyperlinks" can blow up the context window just as easily