I want to make this design more flexible and avoid tightly coupling the parameters to specific implementations.

You've described a situation where the parameters are intrinsic to those specific implementations:

token for FCMNotifier, and topicArn for SNSNotifier

Can you have an FCMNotifier without a token? Can you have an SNSNotifier without a topicArn?

So let's say you do crack this design problem and you're able to figure out a way to abstract away the specific parameters to each notifier. Whatever solution you come up with, the first thing each notifier implementation has to do is verify that the things it needs to function are specified. IOW, the FCMNotifier has to deal with whatever abstraction you've created and extract a valid token from it, and the SNSNotifier has to do the same for a topicArn.

On the other side of this communication, whatever populates the abstraction has to know that it's not just dealing with generic parameters for some generic notifier. No, it has to know it wants an SNSNotifier and so I have to provide a topicArn. It will want to know that it hasn't made a silly mistake and formatted some parameter incorrectly, so it will probably need some kind of utilities specific to each parameter type that can verify, yup, this is a valid topicArn, you're good to go!

Keep in mind that the value of abstractions is that they allow you to deal with things at a conceptually higher level if that's all you care about. For example, if we're having a conversation about stars and I pick some example star to make a point about stars in general, I could pick the Sun, but neither you nor I care that it's the Sun, and we can ignore all the things about the Sun that make it unique.

If we're talking about the Sun specifically, though, and you say, "Let's not use the Sun as the Sun per se, but rather as an example of stars in general," that doesn't make any sense because we're trying to make a point that is actually specific to the Sun. So making sure we carefully have the discussion such that we never rely on anything about the Sun that isn't generic to all stars … isn't going to work. We're trying to use an abstraction where the conversation doesn't call for one.

It seems to me you're doing the same thing. Design all of the specific notifiers you need first and then look at all of them and ask, "What do these have in common that can be pulled up to an interface? What in my codebase is going to use these are generic notifiers, and what do those callers need from this interface?"

The things in the codebase providing parameters to the notifiers are not examples of callers that want to talk about stars in general, they want to talk about the Sun. Don't force them to use the abstraction.