With TestComplete, the binding between the source control system and the project is stored in the MDS file (for projects) and the PJS file (for project suites).
So, adding the source code to TFS directly via the Source Control Explorer added your project to TFS, it, however, did not bind your project to your source control system. What you would need to do then is, after you've added it to TFS, open it in TestComplete and right click on your project or project suite node and select the Source Control option. In there, there should be an option to "Add Project" or "Add Project Suite". Selecting that will create the binding and, since TFS already has the project in the source control, it doesn't need to go through and re-add all the components.
When that is then saved and the MDS is re-checked in, that binding to TFS is now complete. What this means, though, is that when working with your project on a new workstation, as you noted, you need to first "Get" the latest version on that new workstation before you open it in TC. There isn't, as far as I can tell, a way within TC to say "Get a particular project from TFS so I can work with it". Although, interestingly enough, I'm trying it now with my own project and it's not actually checking out one of my units. I can get the latest version, but it doesn't automatically check it out. I wonder if it has something to do as to whether TFS recognizes that the unit version on your hard drive is the same version as in TFS. If the version is unknown on your drive (since you added via explorer, that's likely), it may be that it wants to check it out so that the version on the drive can be updated to match TFS.
As for your other questions, as I work with TFS, TC's interface through the SCCI assumes that, if you're getting the latest version of an item, you must be intending on editing it. I can't find anything within TC that specifies that a "get" doesn't automatically check out the item. This seems to be a peculiarity with this interface.
As for the MDS file getting changed all the time, I think there's another thread up here that addresses some of that. First of all, there's a "files" section in the MDS file that, for every file associated with the project, there's an XML node in the MDS file. So, if you add or remove a unit or a Stores object or other similar things, the MDS file will be changed. For the most part, these changes can be ignored as, each time you open the project, the MDS file gets updated with all associated files. Secondly, if you add new Project Variables or, in your script code, do dynamic "Add Variable" or "Delete Variable" calls on the project variables, that will alter the MDS file as that file is what stores the variable declarations and the default values (dynamic "local" values of variables are stored in a different file). Finally, and I think SmartBear folks are looking at this, Object Mapping nodes in the MDS file seem to get re-ordered at times depending upon which workstation is editing the MDS. My assumption for my operations is that, if I'm doing any work with a project, I need to assume that I'm going to be altering the MDS file in some way and need to make sure it gets checked out with all other changes.
Hopefully I've been able to answer your questions.
