There are 4 real parts to this.
1) Your application. An MDB is an application which implements the J2EE Message Driven Bean API, which in its simplest form means it has an onMessage() function which will be invoked by the application server when messages arrive.
2) The J2EE application server, JBOSS is an example. This receives messages from the MQ client, and forwards them to the MDB.
3) The MQ client. This is the code written by the MQ provider (IBM/Apache/etc) which implements the JCA RA and JMS parts of J2EE. Applications can interact with this client via JMS to put and get messages, though when you're interacting as an MDB you'll be driven via your onMessage() method. This client hands messages to the application server, which drives the applications.
4) The MQ server. IBM MQ calls this a 'queue manager', and this can exist anywhere. The client from #3 will connect to the queue manager over the network.
#1, #2, and #3 need to be on the same physical machine (and run in the same JVM). #4 can be anywhere as its accessed over the network.
To address your points:
So can the MDB deployed in physical server-A get messages from physical server-B?
Yes
If this is possible, then does MDB use JMS API's?
The MDB is driven by the application server using the J2EE API, JMS is just a part of this.
By the way, 'MQ' is the name of product rather than a concept. The generic name is 'Messaging Provider'. IBM MQ and ApacheMQ are both messaging providers.