| There's Language Server Protocol (LSP) which is an open specification from Microsoft, but as far as I can tell it's meant to be a personal server to back a REPL session, not a public server on the internet that serves the same content to everybody in the world.

I looked at their overview here, and I agree with your conclusion:

 https://microsoft.github.io/language-server-protocol/overview

It sure would be nice to take advantage of all the work they've done, though.

Reuse of what has been done around the LSP can mean these things:

• Language server side: making use of a concrete language implementation of the LSP. Last time I checked, for Scheme this was only Kawa, where Per Bothner mentioned somewhere that he is working on it (repo is here). The implementation is based on the Java-LSP, so setting this up for Emacs means setting up LSP Kawa, LSP Java and LSP Emacs. And as noted above, the LSP infrastructure is based on the idea, that you're running a local service where the editor is constantly fetching data from that server (as with Emacs, Slime, CL).
  
  
• Editor side: reuse here means whatever we provide fitting the server-side of LSP can be consumed by VS Code, Emacs and any other editor supporting LSP. Given that many Schemers will probably already use Emacs and that Emacs already has a rather strong story around language integration (or rather various quite strong stories...), the advantage here is probably smaller than for most other editors.
  
  To technically fulfill that option would mean to run some client to our API-server locally, which could do some caching and which could extend the remote information with additional information only available in the context of a current session, e.g. an apropos of symbols available if this and that module are imported. Basically a REPL per Scheme with an integrated HTTP client and cache.
  
  
• Ideas, protocol: the features provided by the LSP according to the main page are
  

• Code completion
• Hover
• Jump to def
• Workspace symbols
• Find references
• Diagnostics
• Additional capabilities
• There is also already the Debug Server extension for VS Code, but I'm not sure how much traction this got up to now. Given where we start, it will anyway not be on the top of the prio list for the first few iterations ;)
  

I recently did post here some bits around my Emacs config for some Schemes, and for me the interesting features up to now where:

• access to documentation index (per Scheme, RnRS, SRFIs)
  
• fetching docstring (incl. signature) per symbol, aka hover aka Emacs Eldoc
  
• code completion per symbol-prefix, e.g. Emacs Company
• jump to def and finding references over all relevant Scheme code would also be interesting; for now I just use here what's available with Emacs out of the box
  

So for me the LSP already quite well fits the API functionality that we probably would anyway come up with; at least it could be a good starting point to collect such feature set.

Again from the technical point of view, next questions for me would be:

• What is the complete API functionality we want to cover with V1
  
• Can this API functionality covered with something two-tier: an (Emacs-)client API talking to the HTTP-API-server or
• Do we need something three-tier: an (Emacs-)client API talking to a local REPL which again talks to the HTTP-API-server and can also provide some more details by running a local session. These "details" could be very helpful things, but then we're also already talking about not only about the API-server but n API-REPL clients.