Based on the response "I was worried about tight coupling between my Player and the caller."
The Facade Pattern doesn't have any hidden agenda. It is a very straight forward pattern. Make your application classes easier to use for the "user" code.
The Facade Pattern is not intended to reduce coupling from individual classes. Reduced coupling of the "Facaded" code is generally a by-product of doing that.
To give a concrete example, suppose I wanted to command my system to start collecting data and report events as they occur. In order to turn the system on, it might need to register the control interface to receive specific events, turn a sensor or two on, read the GPS data, read weather information, position the sensors, provide readings to algorithm processing modules etc...each of those will have at least one class representing it. While the application developer may know how to put all those pieces together, the poor developer developing the user-interface is going to have their hands full figuring it all out.
IOW, that's a lot for "user" code to know when all they really want to do is say StartDataCollection(). Thus, the Facade is born. All that knowledge of coordinating the classes to coordinate the processing is hidden behind that Facade.
If all your system is going to ever have is 1 "user" code implementation or the same developer is implementing the application and "user" interface then Facade is probably not needed and maybe some sort of Command Pattern or operation concept is an option.
Where the Facade shines is when your system has multiple "user" interface types that can control it. By using the Facade, with the addition of events, asynchronous processing, message queues, perhaps some application specific rules, etc... and ensuring that the Facade and your application code is user interface agnostic, the job of implementing new types of interfaces only ends up becoming one of writing/reading data to/from the physical interface. Getting the app to do the right things is trivial because you simply make calls on the Facade and receive events from the Facade.
Also, you can develop and test the "user" interface totally stand-alone from your application. While that is good in its own right, it is a silver bullet for meeting deadlines because now you can throw more people at the problem (which almost never works in software development) as they can develop their software independently from others and user/control interfaces tend to not be as difficult as the main application processing.
Getting back to your question....Should Player be exposed or not? I'd say if all your Facade methods are simply regurgitating the corresponding method on the class then I think you need to revisit your use-cases or your design. I know you just gave a simple example, but basically what you've shown is that "Player" is really the Facade. The other option is that maybe the functionality within Player.Play() belongs in the Facade instead of Player.
I think it is OK to expose a limited set of classes in the Facade for simplicity, in particular with regards to reporting information. However, I would avoid exposing classes with the intent of initiating application operations. Create a Facade method for that. What happens if you change your application to allow multiple users but only 1 can Play at a time? If the "user" code has access to the Player instance then you're in for a bit of pain. If they only have access to the Facade Play() method then change number of users till your heart is content.