No - not primary key - clustering key .
By default, this is the same in SQL Server - but it is not necessary. It is possible that in this table the PC is different from the clustering key. In this case, the index will not know PK.
The primary key is a logical construct for unambiguously and clearly defining each row in your table. You use it for FK restrictions, etc.
The clustering key, on the other hand, is the physical index - this is the "street address" or page number where your actual physical data is stored. Because of this, it is included in each nonclustered index of the same table - it serves to search for the actual data row after you find the record in the nonclustered index.
UPDATE: okay, so I couldn't resist asking Queen Indexing, Kimberly Tripp, for what she thinks about this topic - here is her answer:
If PK is actually a CL key, then you're right ... it will be automatically there. As for "where," hes said - Im not sure (DMVs, DTA, somewhere ???). Regardless, I'm sure that any tool that uses is just what you need for the request. Meaning, the tool just didn’t see if it was a CL key ... adding it obviously doesn’t add it twice, so in fact this is not all.
Does it help?