Put an app_config.xml file in your project folder and tell BOINCmgr to read the config files. E.g.

<app_config>
    <app>
        <name>arp1</name>
        <!-- needs 1 GB RAM per arp1 WU -->
        <!-- Xeon E5-2686v4   18c36t   32 GB   L3 Cache = 45 MB  -->
        <max_concurrent>1</max_concurrent>
    </app>
    <app>
        <name>opn1</name>
        <max_concurrent>8</max_concurrent>
    </app>
    <app>
        <name>mcm1</name>
        <max_concurrent>5</max_concurrent>
    </app>
    <app>
        <name>hst1</name>
        <max_concurrent>2</max_concurrent>
    </app>
    <app>
        <name>mip1</name>
        <!-- needs 5 MB L3 cache per mip1 WU -->
        <max_concurrent>3</max_concurrent>
    </app>
</app_config>

Root cause may be due to subproject weight. Not all subprojects weigh the same, so maybe MCM1 has higher distribution priority on the feeder than other subprojects.

I've re-enabled MCM1 on my end to see if I experience the same as you (that I get more MCM1 tasks than OPN1).

Edited to add: It's only been 2 hours since making this post, but out of the 9 most recent tasks I've received, 7 were MCM1, and 2 were OPN1. I'll give it a couple days to normalize, but so far, I'm experiencing the same as you.

It's possible that because so many people are opting into only crunching OPN1 that the other subprojects are neglected, so the feeder is more likely to give non-OPN1 tasks to devices who aren't picky.

Editing about 2 days after making this post: Over half -- maybe 2/3 or more -- of new tasks have been MCM1 compared to OPN1, so I'm able to reproduce what @Petrctale is seeing. So I think there is such a thing as sub-project weight. I don't know if this weight is visible (i.e. in the API) or if we just have to guess.

Mitigation steps are as discussed: Limit the # downloaded per device in the WCG profile custom preferences and limit the # concurrently running via an app_config.xml parameter.