I've submitted to just about every directory I could reach by now. Chrome, Firefox, Edge, Zapier, IFTTT, Figma, ChatGPT. Every time it's someone else's place: you show up, they check what you've brought, sometimes they send you back to fix it, sometimes they let you in. I've written enough about review rounds and strange submission rules by now.
And this week we submitted Publora to the official Claude connectors directory. For some reason I'd been preparing for this one longer than any of the others. Not technically. The work was done. Apparently I had some feelings left over.
The submission itself took about fifteen minutes. A form, a button, done. Submitted yesterday, in the directory today. Behind those fifteen minutes was a month and a half of work by the whole team: thirteen pages of Anthropic documentation, checking the server against fifteen requirements with live requests, and manually running all eighteen tools against production.
So why did the easiest submission bother me more than some of the genuinely horrible ones?
I think it's because all the previous directories felt like other people's territory. Claude doesn't. I'm not an engineer; my job is getting people to use our product, and almost everything I've built this year I've built with Claude somewhere next to me. It's my pocket techie: it writes the code, I lead, argue and make it redo things. Twenty articles, a dozen and a half integrations, all those submissions. And now Publora is sitting in Claude's own directory. That felt different.
That's enough sentiment. There were also several stupid things that cost us time, and those are probably more useful if you're submitting a connector yourself.
The main thing I'd keep in mind: a green status in the portal doesn't necessarily mean the thing next to it is already working. We found that out in three different places.
"Live in the directory," and the page is empty. We hit publish and the portal immediately reported "live." The listing page, meanwhile, spent several hours returning "This connector doesn't exist." The View listing button went to the same page, and search found only our temporary connection. We'd already written a support email and, luckily, hadn't sent it yet. A few hours later the listing appeared on its own. If you see the same thing, give it some time before writing to support.
The portal decides the server is authless when it isn't. At the authorization step it checks tools/list. Ours returns the tool list without a token, so the portal announced: "Server requires no auth to list and call tools." The first half is true. The second isn't. You can see our tools without authorization, but you can't call any of them. We still had to select OAuth manually.
The docs disagreed with the live form in four places. The docs promised eleven steps; we got ten. The icon field was described as a file upload but turned out to want a URL. The best one was the listing address: the docs use claude.ai/directory/connectors/<slug>, while the actual listing is claude.ai/directory/<slug>. The old version even appeared in the approval email. We nearly copied it into our own documentation because apparently an email can still outrank the browser in my head.
One deserves its own section, because I went looking to see whether we'd done something stupid. This time, at least, we had company.
The portal flagged all eighteen of our tools as "missing a title." All eighteen had titles. The problem is that the MCP spec has two places for title: top-level Tool.title, added in summer 2025, and the older annotations.title. We used the newer field. The Claude directory was checking annotations.title.
This has caught other people too. A pull request to FastMCP describes the same problem: its titles were going only into the top-level field, so the Claude connectors directory saw the tools as nameless. If the portal says your tools are missing titles and you can clearly see the titles in the schema, check annotations.title before doing anything more dramatic. That string is also what users see in the confirmation dialog, so they get "Create post" instead of create_post.
The form draft doesn't save. We went through all ten steps, clicked "Save and exit," and lost the lot. When we came back, the form was empty and the dashboard said we hadn't submitted any servers. "Draft saved in this tab" is apparently very literal. I'd do the form in one sitting.
The "Keep your personal account separate" checkbox when creating an organization. Without it, your personal subscription is cancelled and your chat history moves into the organization, with no way to move it back. It's an easy checkbox to skim past and not a particularly easy decision to undo.
Separately, because this part was my problem rather than Anthropic's. Along the way I put four things into our blockers: a network supposedly missing from the test account, a strange 403, dead tokens and a parameter I thought we had to change. None survived an actual live check. In several cases I'd looked at one field in the database, decided what it meant and promoted the guess to a problem.
There was a good example in the other direction too. At one point I entered the wrong plan, the one I thought was required for submission. Claude accepted that as a fact, built the rest of the reasoning around it and very confidently helped me proceed in the wrong direction. Which was fair enough. I had given it bad information and then asked it to reason from there.
I'm getting better at noticing this when we work together: when Claude has started building on an assumption, when it's doing something I didn't actually ask for, and when I need to stop and check the boring fact underneath all the reasoning. The same applies to me. My "I think there's a defect here" can become a blocker in a document surprisingly quickly. Claude's guess can do the same. Neither becomes more factual because it has been written down neatly.
Publora is in the Claude directory now. You can connect it and create posts for ten social networks from the same chat where you're already working, instead of moving the text into another app afterward.
The part I'd still be careful with is delegation. I've written about this before, but it keeps coming up: vague instructions give Claude room to fill things in. If you want a post published, tell it what to publish, where and when. If you want a draft, say draft. I don't rely on Claude to guess which parts of a publishing decision I meant to leave unsaid.
Looking back at the things I've built this year, there's a slightly ridiculous amount of technical work for someone who still introduces herself by saying she's not an engineer. Claude has been involved in most of it. So seeing Publora in its directory was nice in a way I hadn't expected.
The actual submission took fifteen minutes. Getting to the point where those fifteen minutes were possible took considerably longer.
I wrote this one with Claude as well, which seemed only fair given where it ended up. I told it what happened, it drafted, and I cut whatever hadn't actually happened.
Have you ever spent months getting somewhere and then found the actual moment itself was almost suspiciously uneventful?