You first should understand what is the role of the linux kernel, and that applications interact with the kernel only thru system calls.
In effect, an application runs on the “virtual machine” provided by the kernel: it is running in the user space and can only do (at the lowest machine level) the set of machine instructions permitted in user CPU mode augmented by the instruction (e.g. SYSENTER or INT 0x80 …) used to make system calls. So, from the user-level application point of view, a syscall is an atomic pseudo machine instruction.
The Linux Assembly Howto explains how a syscall can be done at the assembly (i.e. machine instruction) level.
The GNU libc is providing C functions corresponding to the syscalls. So for example the open function is a tiny glue (i.e. a wrapper) above the syscall of number NR__open (it is making the syscall then updating errno). Application usually call such C functions in libc instead of doing the syscall.
You could use some other libc. For instance the MUSL libc is somhow “simpler” and its code is perhaps easier to read. It also is wrapping the raw syscalls into corresponding C functions.
If you add your own syscall, you better also implement a similar C function (in your own library). So you should have also a header file for your library.
See also intro(2) and syscall(2) and syscalls(2) man pages, and the role of VDSO in syscalls.
Notice that syscalls are not C functions. They don’t use the call stack (they could even be invoked without any stack). A syscall is basically a number like NR__open from <asm/unistd.h>, a SYSENTER machine instruction with conventions about which registers hold before the arguments to the syscall and which ones hold after the result[s] of the syscall (including the failure result, to set errno in the C library wrapping the syscall). The conventions for syscalls are not the calling conventions for C functions in the ABI spec (e.g. x86-64 psABI). So you need a C wrapper.