List the Forge organisations this API token can reach, with their slugs. Every other tool takes an organisation slug (or uses the configured default). Start here if you do not know the slug.

List the servers in an organisation — provider, region, size, PHP version, IP addresses and provisioning status. Supports filter/sort/include (try include="tags"). Use this to find a server id for the other tools.

Get one server in full: provider and region, sizes, PHP and database versions, IP addresses, tags and provisioning state.

A server's recent Forge activity — provisioning steps, service restarts, configuration changes, who triggered them and whether they succeeded. The closest thing Forge has to an audit trail, and the first place to look when something changed unexpectedly.

The PHP versions installed on a server, which is the default, and their patch levels. Useful for spotting servers left on an end-of-life version.

List every site in an organisation across all servers, with its domain, project type, PHP version, repository, deployment and maintenance-mode state. Prefer this over listing sites server by server. Note that the hosting server is NOT included by default — pass include="server" to answer "which server hosts acme.com?" in one call. To find one site, filter by name (filter: {"name": "acme.com"}) rather than paging through them all. Sites on a revoked (archived) server are still listed as installed; with include="server" they are marked server_revoked: true, so a stale namesake is not taken for the live site.

Get one site in full: domain and aliases, web directory, PHP version, repository and branch, quick-deploy state and which server it lives on. Note that Forge addresses a single site at organisation level, so no server id is needed.

The domains attached to a site, including aliases and their certificate state. Pair with list_certificates to audit SSL expiry.

A site's SSL certificates with their type, status and expiry — the read to use for certificate-expiry checks. Requires the site:meta scope.

A site's deployment history — commit, author, status, duration and timestamps. Use it to find when a site last shipped, or to identify a failed deployment to inspect with get_deployment. Newest first unless you pass sort (Forge's own default is oldest first).

One deployment in detail: commit, author, status, timings and any failure information. Note that the deployment OUTPUT log needs the site:manage-deploys scope, which also grants the ability to deploy — so a read-only token will get a 403 for the log while this summary still works.

The site's deployment script — the commands Forge runs on each deploy. Read-only: this cannot change the script.

Tail a site's logs: the Laravel/application log, or the Nginx access or error log. The first place to look when a site is throwing errors. Returns the END of the log by default (that is where failures are) — raise tail_lines for more. Requires the server:manage-logs scope, whose only write power is clearing logs. Note that Forge reads logs from the server over SSH at request time, so a server whose Forge access has been revoked returns an SSH error instead of a log.

The output of a deployment — the deploy script's stdout/stderr, which is what actually tells you why a deploy failed. Get the deployment id from list_deployments. Requires the site:manage-deploys scope; be aware that scope ALSO grants the ability to deploy, so a strictly read-only token will get a 403 here while list_deployments and get_deployment still work.

The output of a command previously run from a site's Commands panel. Get the command id from list_site_commands. NOTE: this replays whatever a human chose to run, so it is the tool most likely to contain deliberately-dumped secrets — credential-shaped text is scrubbed on a best-effort basis, but do not treat the result as sanitised.

The output of the most recent run of a scheduled (cron) job — server-level, or site-level if you pass site. Use it to see whether a schedule is actually succeeding rather than just firing. Get the job id from list_scheduled_jobs.

The output of a Forge server event — a provisioning step, service restart or configuration change. Get the event id from list_server_events. Useful for finding out why a Forge-side operation failed.

The log of a daemon or queue worker — what a stuck or crashing queue is actually printing. Get the id from list_background_processes. Requires the server:create-daemons scope; that scope ALSO grants creating daemons and enabling Horizon/Octane/Pulse, so a strictly read-only token will get a 403 here while list_background_processes still works.

Cron/scheduled jobs, either for a whole server or for one site. Shows the command, user, frequency and last run state — use it to confirm a schedule exists and is firing.

Daemons and queue workers on a server — command, user, process count and status. Use it to check queue workers are running and correctly sized.

Whether a first-party Laravel integration is enabled for a site: Horizon, Octane, Reverb, Pulse, Inertia, the scheduler, or maintenance mode. "laravel-maintenance" answers "is this site in maintenance mode?".

The history of commands run from a site's Commands panel, with who ran them and when. An audit read — this cannot run a command.

Database schemas on a server, or the database users and the schemas they can access. Names and grants only — this never reads database contents.

Database backup configurations on a server — schedule, retention, destination and which databases are covered. Answers "is this server actually being backed up?". Listing individual backup INSTANCES needs the server:create-backups scope, which also grants restore, so it is not exposed here.

Perform an arbitrary GET against the Forge API for endpoints the named tools do not cover — monitors, firewall rules, Nginx templates, recipes, teams, PHP config, heartbeats, providers and so on. Pass a path relative to the API base with real ids substituted, e.g. "/orgs/acme/servers/12345/monitors". Only documented Forge GET endpoints are permitted: writes are impossible, and a small set of reads that would expose secrets (.env contents, registry and provider credentials, SSH and deploy keys) or hand over a deploy capability (the deployment trigger URL) are refused with an explanation. Query parameters go in query, not in the path — e.g. {"page[size]": 50}.