The server (but not the client) absolutely must receive, and validate, multiple parts of the AuthenticatorAttestationResponse beyond just the public key. Failure to do this would reduce the phishing and MitM protection that FIDO2/Webauthn is designed to provide. In particular, the server needs to verify that the challenge it sent to the client was correctly combined with the expected relaying party ID (the site domain, or other app ID) and credential ID, and that the resulting verificationData was correctly signed to produce the attestation signature (attStmt.sig from the decoded AuthenticatorAttestationResponse.attestationObject) using the credential's private key (meaning, you must validate the signature against the reconstructed verification data using the provided public key).
This means the server needs to know not only the public key, but also the attestation signature (part of the attStmt) and the data necessary to reconstruct the signed message: the authData, combined with values the server knows already (the challenge it issued, and the expected relaying party ID). The former fields are part of the decoded AuthenticatorAttestationResponse.attestationObject. The latter fields can be extracted from the AuthenticatorResponse.clientDataJSON if you want to validate that the authenticator did the expected thing, but this is not generally needed or recommended in the spec. (Obviously, you must not blindly trust them to be correct since they are supplied by the client; either validate them or ignore them and just use your known values for those fields!) As such, you need to send the attestationObject to the server, but I believe you don't necessarily need to send the clientDataJSON.
Simply sending the public key could allow for attacks such as using CSRF to associate an attacker's authenticator (and its public key) with your account (normally prevented by validating the challenge) and then logging in as you using their own authenticator's public key, or registering the user's actual public key but on a phishing site such that in the future the user can log in to their account via the phishing site and give the site access to their account (fixed by validating the relaying party ID). Both of those validations are part of the signature verification that requires all this data.
The server might have additional uses for the authenticator data, such as retrieving the name and type of authenticator (e.g. to display an icon along with the name for the user's assistance in identifying which or their authenticators it is, or to restrict allowed authenticator vendors). However, the critical security check is the signature validation. This is just as when logging in, where most of the same data is present and a very similar signature verification must be carried out by the server.
As a side note, I'm pretty sure webauthn libraries have now been written for all major web frameworks, and while the quality and completeness of those libraries will inevitably vary, I expect you can find one for any given format you want to use, and probably one that will handle (and abstract the differences between) multiple formats. As such, you shouldn't need to write your own implementation, and I recommend against doing so unless all the options are not only too flawed to use, but also to fork and fix, or work with the vendor on. Cryptography, even when you're just implementing a well-specified protocol using standard primitives, is complex and error-prone, and nearly everybody is better off using a library that hopefully has seen some external review, rather than trying to build their own implementation.
