Error: Failed to complete authentication

[Sa1ch]

Greetings! I'm doing everything according to the instructions, but when I try to request the application key, an error is returned: Error: Failed to complete authentication. Even though I'm correctly entering the 4 digits that appear in the pop-up window.

[Qwinty]

That's unusual. We'd expect an incorrect code to produce a 500 error. I've tested the get-key function myself and it worked as expected. I've updated the code to include more detailed error logging. Could you please pull the latest changes and provide the logs if the error continues?

[carsaig]

Same here. It's due to a bug in /src/index.ts. I fixed it but the client still didn't connect. The API key is generated and shown in Anytype backend but the validation session of the code authentication crashes. The dirty workaround currently is: trigger the app key authentication, let the session crash, grab the API key from Anytype Backend while the authentication session is still valid, use it for the client credentials to connect to the MCP server, start the MCP server....(which now starts after I fixed it)...and oh lord - the client still doesn't connect to the Server. The reason is quite simple: the credential syntax mentioned here in the docs is plain wrong. Maybe it worked some time back and anytype changed something - no idea. However, in the Anytype backend, copy the MCP server config and use it for the client. Voila! Server running. --> just use the original MCP server and credentials and not this one and you're all set.
But here is my 2 cents: MCP is not usable for production use yet. It's super edgy, the LLMs are colossaly overwhelmed with requests and answers, it just throws junk tech questions back at me or plain revokes my request. The reason is simple, the solution complex: MCP is just a standard of connection. Very powerful and very new. The downside: it just pipes all sort of technical attributes from the tool side to the LLM which has no chance to interpret this junk as of yet, thus throws back all sorts of useless stuff at the poor enduser. This whole process needs a LOT more polishing, optimization and in parts innovation. That's totally fine. It just takes time :-) The LLM requires a lot more context on the technical possibilities of tools it is working with, then it requires former user actions - so more context and historical insights on user side, etc. etc. The answer to this issue is building an agentic pre-processing before piping requests through MCP. Moreover: it requires memory and caching solutions, some langChain fun, token management and a lot more. I'll look into it in regards to Anytype to make up my mind how to approach it and how it could give real value to the enduser but as of now, this is near unusable. It's just for fun experiments :-) And be warned: MCP requests can burn a lot of tokens currently!
This MCP server requires a lot more polishing. But hey- it's a working POC!

[jmetrikat]

hey @Qwinty, just a heads up: the auth endpoints have been updated in the latest api release. they remain functional for now, but will be deprecated in a few weeks

see as a reference here: anyproto/anytype-heart#2406 (comment)

Warning

As we're improving our API key generation, current auth endpoints (/v1/auth/display_code, /v1/auth/token) will be deprecated in a future release. Please migrate to the updated ones found below:

POST /v1/auth/challenges    → creates a new challenge (201 Created)
POST /v1/auth/api_keys      → exchanges {challenge_id, code} for an api_key (201 Created)

however, this does not resolve the reported auth problem here. the implementation seems correct at first glance

[jmetrikat]

@carsaig sorry to hear you're having trouble getting @Qwinty's mcp server up and running.

as you mentioned, the official Anytype MCP Server should give you the best experience. it's built directly on top of our openapi spec, and the setup is convenient as well. if anything isn't working as expected, or you have feedback for improvement, let me know!