Is there an open-source license between MPL, LGPL and AGPL that meets these criteria?

It's easy to fulfill all five of your conditions.

You can write an exception text, to be attached to the AGPLv3, similar to the GPL-3.0 Interface Exception, and it may look like this:

Linking [name of library] statically or dynamically with other modules is making a combined work based on [name of library]. Thus, the terms and conditions of the GNU Affero General Public License, version 3 ("AGPLv3") cover the whole combination.

As a special exception, the copyright holders of [name of library] give you permission to combine [name of library] program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with [name of library] solely through the [name of library's interface] interface. You may copy and distribute such a system, and/or make it remotely interactive through a computer network, following the terms of the GNU AGPL for [name of library] and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU AGPL requires distribution of source code and provided that you do not modify the [name of library's interface] interface.

Note that people who make modified versions of [name of library] are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU Affero General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception. If you modify the [name of library's interface] interface, this exception does not apply to your modified version of [name of library], and you must remove this exception when you distribute your modified version.

This exception is an additional permission under section 7 of the GNU Affero General Public License, version 3 ("AGPLv3").

The above text is virtually identical to the GPL-3.0 Interface Exception, except for the addition of the bolded text, which is specific to Section 13 of AGPLv3. I say "virtually identical" because "GPL" was replaced with "AGPL".

From the GPL FAQ:

This exception enables linking with differently licensed modules over the specified interface (“ABCDEF”), while ensuring that users would still receive source code as they normally would under the GPL.

Only the copyright holders for the program can legally authorize this exception. If you wrote the whole program yourself, then assuming your employer or school does not claim the copyright, you are the copyright holder—so you can authorize the exception. But if you want to use parts of other GPL-covered programs by other authors in your code, you cannot authorize the exception for them. You have to get the approval of the copyright holders of those programs.

I would not call this a "crayon license", since it uses an exception text which is sanctioned by the GNU Foundation, excluding the bolded text above of course, which is very similar to language from Section 13 of the AGPLv3.

I am not a lawyer and this is not legal advice.

Network use is considered distribution: The license treats network use (remote use, Software as a Service (SaaS)) as distribution, meaning modifications to the software must be shared if the software is made available over the network (like AGPL).

The only widely used license that meets this criterion is the AGPL, which does not meet your other requirements, so probably the answer is no. However, even the AGPL has issues with how it actually works, and for reasons I will explain, those issues are probably unfixable within the scope of a FOSS license. I would encourage you to consider dropping this requirement altogether, since it may not have a feasible solution at all.

Here is the operative clause of the AGPL:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Let's break that down into bullet points:

• If you modify the software...
• ...in a way that supports any kind of network interaction...
• ...then the modified version must offer a copy of its source code...
• ...to anyone who interacts with it.

I have seen the following objections raised against this clause (but see below):

• It applies to any modification of any software that already has networking code, even if that software does not already include a source-offer feature. So you are required to implement such a feature if you so much as fix a typo in the source code of such a project.
• It prohibits you from making a version of the software which does not offer source, even if this version is never executed at all (or never interacts with any users). So you can't turn the feature off for debugging purposes, or for an internal version of the software that is never publicly accessible.
  • Under an even stricter reading, it is prohibited to have such a version in your Git history or working directory, because those are modified versions of the software and immediately become subject to the AGPL's remote interaction clause, before you have even compiled them.
• The AGPL requires the software to "offer" the source code to "all users interacting with it remotely through a computer network," but it is unclear what happens if that is technically impossible or impractical. For example, an SMTP implementation is going to have a hard time offering a copy of its source to remote users, because the remote user is probably a human interacting with the webmail frontend of an entirely different email service, and there is simply no reasonable means of offering source to that user (other than auto-generating a source-offer email reply, which I think most recipients would regard as spam). Similarly, an HTTP server would need to inject a source-offer header or HTML containing such an offer, and so on. Crucially, none of these things may be disabled by configuration options, because the language of the AGPL says you must make this offer to all remote users, unconditionally.
  • If we say that the software is not required to ensure that the offer is actually received by the end user, then this creates the obvious loophole of putting a reverse proxy in front of the AGPL application, and configuring it to strip out the source code offer.

Now the important caveat: All of the above objections are based on a completely literal reading of the AGPL. In practice, nobody actually files copyright lawsuits against developers who create pull requests that do not contain a source-offer feature, despite the fact that the license arguably requires such a feature to be included in every pull request (for applications which already have some networking features).

There is a somewhat colorable argument that these "technical" breaches of the AGPL would fail to give rise to significant damages, and if the AGPL is a contract (which is itself not completely uncontroversial), then they may be de facto permissible as efficient breach in jurisdictions which allow it. Unfortunately, in some jurisdictions, these violations could also be claimed as copyright infringement instead of or in addition to a "mere" contractual breach, and depending on the operative law, there may be no such loophole. For example, in the US, 17 USC 504 provides a fixed schedule of damages and allows the plaintiff to choose whether they want to receive those statutory damages or attempt to prove actual damages.

If you are working in the professional space, then there are lawyers involved in your work whether you like it or not, and those lawyers will not be happy with hearing about "community norms" and "we probably won't get sued if we do [something that is not unambiguously permitted by the license]." This is one of several reasons that the AGPL is unacceptable to many tech companies.

You might therefore ask whether there is a better way to accomplish this goal. Probably not, unless we make a license that looks a lot like an EULA. The law (in most countries) does not provide a mechanism for us to specify what is and is not "distribution." Instead, we can only impose restrictions on how the software can be used, modified, or redistributed (within the meanings of those terms as defined under applicable copyright law). If we impose a usage restriction which requires a source offer to be made, then we accomplish our goal, but at the expense of imposing a usage restriction, which many in the FOSS community regard as unacceptable (it's literally freedom zero in the FSF's four freedoms). Such a license would be a "clickwrap" license (i.e. "You must accept the license in order to use [name of software]. If you do not accept the license, then uninstall [software] and return it to your distributor for a refund or exchange."), and I do not believe the FSF or OSI would be willing to bless such a license as Free or Open Source (respectively).

Disclaimer: My employer doesn't like the AGPL. This answer is my understanding of the legal and practical issues, is based solely on publicly available information, and does not necessarily reflect anyone else's viewpoint or opinion, including that of my employer.