I am currently building out a server/database on my local machine to go along with a client core. The core of the client will interface directly to the server. The actual client files will be open sourced, the core client exe and framework itself will be closed. Others can use the framework to make their own "client files", and the methods from the framework will interface to the server so others don't have to, they can use the supplied api's. The client files are compiled dll's that can pretty much do anything that people want to as long as they code it.

With that said, inside my supplied framework I mentioned is where the real "client" to "server" communication happens.

Let's say I supply a method called "private eCreateAccountStatus CreateAccount(string Email, string Password) { ... }".

Now, anybody can call that method using my framework, and that method isn't vary harmful to the server, as it just checks for an account with that email already and creates it if not existing.

The game in question is going to be very much like a traditional ccg/tcg.

Now, let's say in a game, we need to tell the server we are playing cards from our hands. Should we provide a direct method of "PlayCard(int CardID)" and do the approprate card checks on the server (does the player have the card in the first play, do they have the resources to play it, is the game in a state where it can be played, etc). Or does this open up a vulnerability since players could pass in any card.

The reason I mentioned the "Client Files" earlier is let's say in a provided default GameBoard.dll I place our hand in the bottom and the opponents hand in the top of the screen. Someone doesn't like this design and provides their own GameBoard.dll that places their hand on the left side and the opponents on the right side of the screen. The Client Files just provide the design for where things get rendered.

My guess is that you don't yet have all the experience necessary to correctly implement a publicly visible API.
I would suggest that you first just implement your own game, perhaps structured along the lines that you suggest.
Then, once that's working, you can take the learnings and structure that comes from the game, and start factoring it into a public API of some sort.

Regarding your "playcard" function question, the server needs to enforce any rules. Thus, if a player attempts to playcard() a card he/she doesn't have, the server should reject that request.
Which brings up the question: If you let developers write client plug-ins, how would the server know about any custom rules? What about custom cards?

Now, anybody can call that method using my framework, and that method isn't vary harmful to the server, as it just checks for an account with that email already and creates it if not existing.

Except now some e-mail spammer finds your system, and starts creating tons of accounts, only for the purpose of having your server send e-mails to specific addresses and "pre-warming" anti-spam systems to believe that those addresses are legit.
As I said: If you build and operate your own game first, you're much more likely to succeed in the end!

Thanks for the words.

Which brings up the question: If you let developers write client plug-ins, how would the server know about any custom rules? What about custom cards?

Basically they won't make custom rules or cards. They could only modify the look of anything though.

Envisioned like this: Server tells client -> player was dealt these cards for their hand. The client goes ok and renders them however the plugin creator defines. When playing a card, the plugin creator calls a method via the supplied framework, framework tells the server to play card x, and the server figures out if it's a valid play or not.

All the rules and checks and everything were planned to be server side.