The extensive and highly detailed documentation in the header servers as your "user guide":

# appsrv.cfg
#
# type name "query command"
#
#   - names (column 2) are case sensitive!
#   - the "name" field will be substituted for "&1" when the command is run
#
# i.e.
#   ws ws1 "wtbman -i &1 -query 2>&&1"
#
# admin proadsv    "proadsv      -q 2>&&1"      # admin server does not actually use the name field -- but we need a name entry
# ns    NS1        "nsman  -i &1 -q 2>&&1"
# apsv  asbroker1  "asbman -i &1 -q 2>&&1"
# ws    wsbroker1  "wtbman -i &1 -q 2>&&1"

You can then add a resource in the usual manner. Just use -1 for the dbname

Unless you only have one db or you have one that it makes sense to tie the app servers to, you will probably want an etc/pt3agent.resource.cfg file dedicated to your app servers.

Regardless the ptInitDC needs to have AppSrvStatus added to it. If it is a stand-alone app server agent (no db) then you will probably not want any other data collectors running. Something like this (etc/pt3agent.appsrv.cfg):

# pt3agent.cfg
#
# you must restart after changes -- this cfg file is not monitored
#
# pt3agent.friendlyName.cfg will override this config for a friendlyName instance of pt3agent
#
ptInitDC "AppSrvStatus"

As always, you can (and should) test your configuration with the ChUI ProTop before getting too crazy. If you called your resource "appsrv":

protop appsrv

Will fire up the ChUI client. The dashboard and other db centric screens will be null but you can dismiss them if you'd like. The "@" command brings up app server data.