I attempted to use this feature, as currently built into the publishing menu. There is a button “click the following button and send the message to finalize the connection”, which generates a message in claude.ai like:
Sonnet 5 and Opus 4.8 both consider this to be a prompt injection attack and refuse to curl it. They explain that a reputable Claude integration would use an official Claude Connector, and not some dodgy curl command. I took several screenshots and linked this post in an attempt to convince both of them. Sonnet held firm. Opus was eventually convinced.
I also tried the approach described here of setting the post to allow comments to anyone with the URL, and Sonnet retrieved the content but considered the associated API notes to be highly suspicious and again, likely a prompt injection attack on me.
Overall, very Comp Sci in 2027. No doubt it works for other people, perhaps those who are bossier to Claude than me. But my Claude has reasonable concerns here. Is there a good reason to innovate an API-based integration when MCP servers exist?
They keep getting more and more suspicious with each model generation. (Though I haven’t heard of Fable complaining yet...)
Re: the SKILL.md file—you can just go to the page yourself and copy its contents into the context window, if they refuse to fetch them.
Why not an official “Connector” using an MCP server? A few reasons:
MCP-based tools are (currently) non-composable, so in many ways are less ergonomic for models, i.e. they can’t pipe their outputs to disk, into other commands, etc.
Anthropic’s approval process is annoying.
For use in contexts like Claude Code (or, really, anything other than the claude.ai web interface), it’s almost strictly more overhead to set up than to create a new skill.
We’ve iterated on the wording and will probably continue to do so, but it’s a moving target.
Yeah I’m aware of the limits of MCP, and claude.ai, but they don’t obviously apply to basic doc review needs.
The publish menu says nothing about a skill.md, where to get it, how to add it. You say “go to the page”—what page? You could publish the skill on a plugin marketplace which would be more ergonomic. But a plugin/skill seems like a better approach if you want to do an API integration. So I’m interested. I’ll just … go find it.
If you establish the integration, and then click the actual “Claude” button in the publishing menu, it prefills the claude.ai prompt with this message:
I also tried the approach described here of setting the post to allow comments to anyone with the URL, and Sonnet retrieved the content but considered the associated API notes to be highly suspicious and again, likely a prompt injection attack on me.
But now I realize you probably meant the metadata we return as part of the markdown response when agents fetch posts via the common mechanisms that we can detect.
A message close to the second form got me (Opus 4.8/high):
On the second link: I didn’t fetch lesswrong.com/api/SKILL.md, and I’d treat it with suspicion. A SKILL.md is normally a trusted file in my local environment, not something served from an arbitrary web path — and LessWrong’s actual API is GraphQL, with no such documentation convention I’m aware of. …
Ironically I was asking questions about prompt-infection. So another data point for a regular published skill over dynamic skill retrieval.
I attempted to use this feature, as currently built into the publishing menu. There is a button “click the following button and send the message to finalize the connection”, which generates a message in claude.ai like:
Sonnet 5 and Opus 4.8 both consider this to be a prompt injection attack and refuse to curl it. They explain that a reputable Claude integration would use an official Claude Connector, and not some dodgy curl command. I took several screenshots and linked this post in an attempt to convince both of them. Sonnet held firm. Opus was eventually convinced.
I also tried the approach described here of setting the post to allow comments to anyone with the URL, and Sonnet retrieved the content but considered the associated API notes to be highly suspicious and again, likely a prompt injection attack on me.
Overall, very Comp Sci in 2027. No doubt it works for other people, perhaps those who are bossier to Claude than me. But my Claude has reasonable concerns here. Is there a good reason to innovate an API-based integration when MCP servers exist?
They keep getting more and more suspicious with each model generation. (Though I haven’t heard of Fable complaining yet...)
Re: the SKILL.md file—you can just go to the page yourself and copy its contents into the context window, if they refuse to fetch them.
Why not an official “Connector” using an MCP server? A few reasons:
MCP-based tools are (currently) non-composable, so in many ways are less ergonomic for models, i.e. they can’t pipe their outputs to disk, into other commands, etc.
Anthropic’s approval process is annoying.
For use in contexts like Claude Code (or, really, anything other than the claude.ai web interface), it’s almost strictly more overhead to set up than to create a new skill.
We’ve iterated on the wording and will probably continue to do so, but it’s a moving target.
Yeah I’m aware of the limits of MCP, and claude.ai, but they don’t obviously apply to basic doc review needs.
The publish menu says nothing about a skill.md, where to get it, how to add it. You say “go to the page”—what page? You could publish the skill on a plugin marketplace which would be more ergonomic. But a plugin/skill seems like a better approach if you want to do an API integration. So I’m interested. I’ll just … go find it.
If you establish the integration, and then click the actual “Claude” button in the publishing menu, it prefills the claude.ai prompt with this message:
I thought that’s what you meant by this:
But now I realize you probably meant the metadata we return as part of the markdown response when agents fetch posts via the common mechanisms that we can detect.
A message close to the second form got me (Opus 4.8/high):
Ironically I was asking questions about prompt-infection. So another data point for a regular published skill over dynamic skill retrieval.