What can you do with this server?

A read-only MCP server for the Laravel Forge API, enabling AI assistants to inspect infrastructure and logs without any write capabilities. * Organizations & Escape Hatch: List accessible organizations; forge_get tool for any documented GET endpoint (e.g., monitors, firewall rules, Nginx templates) not covered by named tools, subject to allowlisting and redaction. * Servers & PHP: List servers with provider, region, size, PHP version, IPs, provisioning state; get server details and recent events (audit trail); view installed PHP versions and default. * Sites & Domains: List all sites across servers with domain, project type, PHP version, repo, deployment/maintenance state; get domain details and SSL certificates with expiry. * Site Integrations: Check if Horizon, Octane, Reverb, Pulse, Inertia, scheduler, or maintenance mode is enabled. * Deployments: Deployment history (commit, author, status, duration); get deployment script and logs (requires site:manage-deploys scope). * Logs: Tail Laravel, Nginx access/error logs (last 200 lines); deployment logs; command, scheduled job, server event, and background process output. * Scheduled Jobs & Background Processes: List cron jobs (server/site) with frequency and last-run state; list daemons/queue workers with status. * Databases & Backups: List database schemas or users with grants (no contents); check backup configurations (schedule, retention, destination). * Strict Read-Only Guarantees: Only GET requests; no deploy, restart, provision, restore, or delete. Multiple enforcement layers: token scopes, HTTP verb restriction, path allowlisting, response filtering. * Security by Design: Token from environment/flag only; never in tool arguments. Sensitive data (.env, credentials, SSH keys, deploy trigger URL) filtered out. Logs scrubbed for credential patterns. * Pagination & Rate Limiting: Pagination support (page_size, cursor, sort, filter, include) without automatic cursor following to avoid rate limit exhaustion; respects Forge's 60 requests/minute and handles retry on 429.

Which integrations are available for this server?

Provides read-only access to the Laravel Forge API, enabling AI assistants to query server, site, deployment, SSL, log, and other infrastructure details without making changes.

How do I use laravel-forge-readonly-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@laravel-forge-readonly-mcp show my servers and their PHP versions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

laravel-forge-readonly-mcp

by brynj-digital

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

A read-only MCP server for the Laravel Forge API, enabling AI assistants to inspect infrastructure and logs without any write capabilities.

Organizations & Escape Hatch: List accessible organizations; forge_get tool for any documented GET endpoint (e.g., monitors, firewall rules, Nginx templates) not covered by named tools, subject to allowlisting and redaction.
Servers & PHP: List servers with provider, region, size, PHP version, IPs, provisioning state; get server details and recent events (audit trail); view installed PHP versions and default.
Sites & Domains: List all sites across servers with domain, project type, PHP version, repo, deployment/maintenance state; get domain details and SSL certificates with expiry.
Site Integrations: Check if Horizon, Octane, Reverb, Pulse, Inertia, scheduler, or maintenance mode is enabled.
Deployments: Deployment history (commit, author, status, duration); get deployment script and logs (requires site:manage-deploys scope).
Logs: Tail Laravel, Nginx access/error logs (last 200 lines); deployment logs; command, scheduled job, server event, and background process output.
Scheduled Jobs & Background Processes: List cron jobs (server/site) with frequency and last-run state; list daemons/queue workers with status.
Databases & Backups: List database schemas or users with grants (no contents); check backup configurations (schedule, retention, destination).
Strict Read-Only Guarantees: Only GET requests; no deploy, restart, provision, restore, or delete. Multiple enforcement layers: token scopes, HTTP verb restriction, path allowlisting, response filtering.
Security by Design: Token from environment/flag only; never in tool arguments. Sensitive data (.env, credentials, SSH keys, deploy trigger URL) filtered out. Logs scrubbed for credential patterns.
Pagination & Rate Limiting: Pagination support (page_size, cursor, sort, filter, include) without automatic cursor following to avoid rate limit exhaustion; respects Forge's 60 requests/minute and handles retry on 429.

laravel-forge-readonly-mcp

A read-only MCP server for the Laravel Forge API.

Point an AI assistant at your Forge infrastructure to answer questions — which server hosts a site, when it last deployed, what's in the error log, which certificates are about to expire — without giving it the ability to change anything.

It cannot deploy, restart, provision, restore, or delete. Not because it's asked not to: there is no tool for it and no code path for it. The HTTP client only issues GET, and the verb isn't a parameter anywhere.

Built on Forge's current API (https://forge.laravel.com/api). The older /api/v1 is deprecated and Forge discontinues it on 31 August 2026.

Install

npm install -g laravel-forge-readonly-mcp

Create a token in Forge → account dashboard → API. Recommended scopes are below.

Claude Code

claude mcp add forge -e FORGE_API_TOKEN=your-token -- npx -y laravel-forge-readonly-mcp

Claude Desktop / any MCP client

{
  "mcpServers": {
    "forge": {
      "command": "npx",
      "args": ["-y", "laravel-forge-readonly-mcp"],
      "env": {
        "FORGE_API_TOKEN": "your-token",
        "FORGE_ORGANIZATION": "your-org-slug"
      }
    }
  }
}

FORGE_ORGANIZATION is optional but worth setting if you have one organisation: tools can then omit the slug, and the assistant doesn't need a lookup call first.

Related MCP server: Forge MCP Server

Options

Flag	Environment variable	Default
`--api-token <token>`	`FORGE_API_TOKEN`	required
`--organization <slug>`	`FORGE_ORGANIZATION`	none — pass `organization` per call
`--base-url <url>`	`FORGE_BASE_URL`	`https://forge.laravel.com/api`
`--requests-per-minute <n>`	`FORGE_REQUESTS_PER_MINUTE`	`60`, matching Forge
`--unsafe-allow-secrets`	`FORGE_UNSAFE_ALLOW_SECRETS`	off — see below

Credentials come only from flags or the environment, never from a tool argument, so nothing the model says can change which token, base URL or default organisation is used.

Tools

24 named tools for the common reads, plus one escape hatch. Forge publishes 133 GET endpoints; mapping them 1:1 would cost 30–50k tokens of JSON schema in your context window before you asked anything, so the frequent paths get real tools and forge_get covers the rest against the same allowlist.

Tool	What it answers
`list_organizations`	Which orgs can this token see?
`list_servers` / `get_server`	Provider, region, size, PHP version, IPs, provisioning state
`list_server_events`	Recent Forge activity on a server — the closest thing to an audit trail
`get_server_php`	Installed PHP versions and the default — find servers on an EOL version
`list_sites` / `get_site`	Every site across all servers: domain, repo, PHP, deploy state
`list_domains` / `list_certificates`	Domains, aliases and SSL expiry
`list_deployments` / `get_deployment`	Deployment history: commit, author, status, duration
`get_deployment_script`	The commands each deploy runs
`get_site_logs`	Application, Nginx access or Nginx error log
`get_deployment_log`	Why a deploy failed — the deploy script's output. Needs `site:manage-deploys`
`get_command_output`	Output of a command run from the Commands panel
`get_scheduled_job_output`	Output of a cron job's last run — is the schedule actually succeeding?
`get_server_event_output`	Output of a Forge server event (provisioning, service restart)
`get_background_process_log`	Queue worker / daemon log. Needs `server:create-daemons`
`list_scheduled_jobs`	Cron jobs for a server or one site, with last-run state
`list_background_processes`	Daemons and queue workers, and whether they're running
`get_site_integration`	Is Horizon/Octane/Reverb/Pulse/Inertia/scheduler on? In maintenance mode?
`list_site_commands`	History of commands run from the Commands panel
`list_databases`	Database schemas, or users and their grants (never contents)
`list_backup_configs`	Is this server actually being backed up?
`forge_get`	Any other documented Forge GET — monitors, firewall rules, Nginx templates, recipes, teams, providers…

List tools take page_size, cursor, sort, include and filter. Cursors are never followed automatically — see rate limiting.

Log and output tools return the tail

Forge offers no range parameter and applies no limit: one real site's application log measured 274,503 characters over 500 lines — about 69,000 tokens in a single response. So every log/output tool returns the last 200 lines by default (failures are at the end), raisable via tail_lines, and is additionally capped by character count because line counts lie — that log averaged ~550 characters per line, and one PHP stack-trace line can exceed a thousand. Anything dropped is stated at the top of the output, so a truncated log never reads as a complete one.

Forge also returns HTTP 200 in three cases where there is no log to give, each of which reads as a broken tool unless explained. All three are detected and described in the response:

The server's Forge access was revoked. Forge reads logs over SSH at request time, so a revoked server yields Permission denied (publickey) as the log body. The tools point you at revoked on the server.
The deployment's output file was pruned. Forge stores each deployment's output on the server and deletes older ones per the site's deployment_retention, so historical deployments return cat: …: No such file or directory. The deployment record itself still works.
The log is empty (=== Empty log file ===).

Token scopes: the part worth reading

Forge has genuine view-only scopes, so a token can be minted that is incapable of writing. These five reach 76 of the 120 endpoints this server exposes (plus 13 more that need no scope at all) with zero write capability:

organization:view  server:view  user:view  team:view  recipe:view

Two other view scopes are not worth granting. credential:view unlocks exactly one endpoint this server exposes (a VPC lookup) — its other three are cloud-provider credentials, which are withheld — so it buys nothing while widening what a leaked token could read. resources:view currently gates no endpoint at all; add it when Forge ships the managed-database and object-storage API.

The wrinkle: 30 reads sit behind manage scopes, so getting the read also buys the write. Two are worth it, and the rest mostly aren't:

Scope	Reads it unlocks	Writes it also grants	Suggested
`site:meta`	8 — all domains and certificates	add / modify / delete a domain	Add — this is SSL and domain visibility
`server:manage-logs`	4 — application and Nginx logs, server logs	clearing logs, nothing else	Add — smallest blast radius, biggest payoff
`site:manage-redirects` / `-notifications` / `-project`	6	redirect rules, webhooks, healthcheck	Optional
`site:manage-nginx`	2 — Nginx config	rewrite the Nginx config	Skip unless needed
`server:manage-network`	2 — firewall rules	change the firewall	Skip unless needed
`site:manage-security`	2	basic-auth rules	Skip
`site:manage-deploys`	1 — the deployment log	deploy the site, rewrite the deploy script (8)	Your call — see below
`server:create-daemons`	1 — queue worker log	create daemons, enable Horizon/Octane/Pulse (8)	Your call — see below
`server:create-backups`	2 — backup instances	restore a backup	Don't
`storage:manage`	2	delete storage providers	Don't

Suggested token — seven scopes:

organization:view  server:view  user:view  team:view  recipe:view  site:meta  server:manage-logs

That reaches 101 of the 120 endpoints this server exposes, and the token cannot deploy, restore a backup, change a firewall, or rewrite an Nginx config. Its only write powers are clearing a log and modifying a domain.

For a token with literally no write capability, drop site:meta and server:manage-logs: 89 endpoints, but no logs and no domain or certificate visibility.

The two log scopes that also grant writes

get_deployment_log and get_background_process_log are the only tools whose scopes grant real write power — deploy, and enabling Horizon/Octane/Pulse respectively. There is no alternative source: a deployment object carries only commit, status and timings, with no output field, and Forge gates the log behind the same scope as deploying.

Worth being precise about what granting them does and doesn't change. It does not give this server, or a model talking to it, any ability to deploy: no write tool exists, the client only issues GET, the deploy-hook endpoint stays excluded and deployment_url stays redacted. What it changes is the token's capability if the token itself leaks. Whether that trade is worth a failed deploy's output is a judgement about your threat model, not something this package should make for you — so both tools ship regardless, and simply return a 403 naming the scope when you haven't granted it.

Every scope-gated endpoint stays available in this package regardless of what you grant — your token's scopes decide, not us. A 403 says which scope was missing, and whether that scope would also hand over write access:

Forge denied access to /orgs/acme/servers/1/sites/2/nginx (403). This endpoint requires the
"site:manage-nginx" scope, which your token does not have. Note that "site:manage-nginx" also
grants the matching write permissions — this package deliberately does not require you to hold
it, and will simply not serve this read if you would rather keep the token read-only.

What it deliberately won't read

A GET being read-only doesn't make it safe to put in front of a language model. Thirteen of Forge's reads are withheld by default, for two different reasons.

They'd leak a secret:

…/sites/{site}/environment — Forge documents this as "Get .env content": database passwords, APP_KEY, every third-party API key the app holds
Composer and npm registry credentials
Cloud provider credentials (/server-credentials)
SSH keys and deploy keys

They'd leak a write capability:

…/deployments/deploy-hook returns, in Forge's words, "the deployment trigger URL" — a URL that triggers a deploy with no authentication. Handing that string to a model defeats the entire point of a read-only server, however much the verb was GET.

That last one is why this package doesn't implement read-only as "allow all GETs". Refusals explain themselves rather than looking like a bug:

/orgs/acme/servers/1/sites/2/deployments/deploy-hook is a read this server deliberately
withholds: the deployment trigger URL — an unauthenticated deploy capability, so reading it
would hand out the ability to deploy. Exposing it would grant a write capability, which
defeats the purpose of a read-only server.

…and one field, wherever it appears

Withholding an endpoint is worthless if the thing it guards is duplicated into a payload you do serve. Forge returns the deploy trigger URL inline on ordinary site reads:

{ "attributes": { "deployment_url": "https://forge.laravel.com/servers/1/sites/2/deploy/http?token=…" } }

That's the same unauthenticated deploy capability as the deploy-hook endpoint, arriving through get_site and list_sites. So every response is also filtered field-by-field, and deployment_url comes back as:

[withheld: deploy trigger URL — an unauthenticated capability to deploy the site, not a read]

The key is preserved so you can see something was withheld, and a null value passes through untouched — that legitimately means quick-deploy is off. The general lesson, learned by probing the live API rather than reading its docs: for a read-only surface over someone else's API the unit of danger is a field, not an endpoint. Fields travel.

…and secrets inside log text

The same lesson recurs a layer down, and this one cannot be solved cleanly. This server withholds .../environment to keep .env out of model context — but a deployment log is the output of a deploy script that may echo environment variables, composer auth tokens turn up in build output, and get_command_output replays whatever a human chose to run, cat .env included. Field-level redaction can't help, because the secret is inside a blob of text.

So log and command output additionally passes through a best-effort scrubber for credential-shaped substrings: KEY=/SECRET:/PASSWORD= assignments, Authorization: Bearer …, ?token=…, AWS AKIA… ids, https://user:pass@host, and PRIVATE KEY blocks. Redactions keep the key name so the line still reads as a log line and you can see what was withheld.

This is best-effort and not a guarantee. Pattern matching over arbitrary log output cannot be complete, and it is deliberately narrow — a greedy scrubber that mangled ordinary log lines would push people to disable it wholesale, which loses far more than it gains. Treat log output as potentially containing secrets regardless. get_command_output deserves the most caution of the set.

--unsafe-allow-secrets re-enables all thirteen endpoints and this field. It's off by default and named to be hard to turn on by accident. If you enable it, those values will appear in model context and in transcripts and logs wherever they're kept.

How read-only is enforced

Four independent layers, so no single mistake is sufficient:

No write tool exists. Only reads are implemented, so there is nothing to disable.
The client can only GET. The verb is a literal in one place and is never threaded through from configuration or arguments.
Every path is matched against an allowlist of Forge's documented GET templates before a request is built. This is what makes forge_get safe: the model picks a path, but only from a set already reviewed. Denials are checked before allowances, because an excluded literal path (…/deployments/deploy-hook) collides with a legitimate template (…/deployments/{deployment}) — in a deny-by-default boundary the denial must win.
Every response is filtered field-by-field on the way out, because the endpoint allowlist alone let the deploy trigger URL through inline on ordinary site reads. Log and command text is additionally scrubbed for credential shapes, and bounded in size.
Your token's scopes, if you mint it view-only — defence in depth rather than the primary control.

The allowlist is generated from Forge's OpenAPI spec (npm run generate:paths), so a typo can't silently create a hole. npm run check:drift — run in CI on every PR and weekly — fails if a new GET appears unreviewed, if one we rely on disappears, if a read moves behind a write-granting scope, or, most importantly, if a withheld path is renamed such that its exclusion silently stops protecting anything.

Rate limiting

Forge allows 60 requests per minute per token. This package keeps a local sliding window and also honours X-RateLimit-* and Retry-After, retrying a 429 twice before giving up with advice to narrow the request.

Cursors are never followed automatically. A single "check every site" call must not be able to spend the whole minute, so pagination is explicit: read meta.next_cursor and pass it back as cursor.

Development

npm install
npm run lint            # tsc --noEmit
npm test                # unit tests (no network)
npm run build
node scripts/smoke.mjs  # drives the built binary over stdio; no network needed
npm run generate:paths  # regenerate the path table from Forge's spec
npm run check:drift     # fail if the package has drifted from Forge's API

FORGE_SPEC_FILE=/path/to/spec.json makes the generator and drift check read a local spec instead of fetching.

Using this behind an MCP gateway

Tool names are intentionally un-prefixed (list_servers, not forge_list_servers), because aggregating gateways add their own namespace and a self-prefixed name becomes forge__forge_list_servers downstream.

Annotations split by kind: this package sets readOnlyHint and idempotentHint (facts about the tool, true everywhere) plus a plain title. A gateway is free to override the top-level title with its own house convention.

main and bin are the same built entry, so a gateway can require.resolve() the package and run it under its own Node rather than needing a global install.

Licence

MIT. Not affiliated with or endorsed by Laravel. "Laravel" and "Laravel Forge" are trademarks of Taylor Otwell; this is an independent client for their public API.

Available Tools

20 tools

forge_getForge API Read (any endpoint)A

Read-onlyIdempotent

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}.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	API path with ids filled in, starting with "/" and with no query string, e.g. /orgs/acme/servers/12345/monitors
`query`	No	Query parameters, e.g. {"page[size]": 50, "sort": "-created_at"}.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint, openWorldHint, idempotentHint. The description adds that writes are impossible, some reads (like .env contents) are refused, and gives examples of endpoints, significantly expanding behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and each sentence adds value, though slightly longer than necessary; could be more concise while maintaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully explains allowed endpoints, refused operations, and parameter usage, providing sufficient context for an AI to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial value: explains path must be relative to API base, no query string in path, provides example path, and describes query parameter usage with examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Perform an arbitrary GET against the Forge API for endpoints the named tools do not cover', with specific examples (monitors, firewall rules, etc.), and distinguishes it from sibling tools by indicating it covers endpoints not covered by named tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool (for endpoints not covered by named tools) and when not to use it (writes are impossible, certain sensitive reads are refused with explanation), providing clear guidance on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_deploymentGet DeploymentA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`server`	Yes	Server id the site is on.
`deployment`	Yes	Deployment id from list_deployments.
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by noting that the deployment output log requires a broader scope (site:manage-deploys) and that read-only tokens will get a 403 for the log while the summary works. This behavioral insight goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence immediately states the purpose, and the second adds critical scope information. Every sentence is valuable and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description lists the key fields returned (commit, author, status, etc.) and includes a scope-related caveat. It is fairly complete for a single-item retrieval tool, though it could mention error handling or not found scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all parameters. The description does not add additional meaning beyond the schema, so it meets the baseline expectation. No extra parameter guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns detailed information about a single deployment, listing fields like commit, author, status, timings, and failure info. This distinguishes it from sibling tools like list_deployments (list) and get_deployment_script (script).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing detailed deployment information but does not explicitly contrast with alternatives. It does mention a scope requirement for the log, providing some usage context, but lacks direct guidance on when to use this versus other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_deployment_scriptGet Deployment ScriptA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`server`	Yes	Server id the site is on.
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description reinforces the read-only nature but adds no further behavioral context beyond what annotations offer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two precise sentences with no wasted words. The purpose is front-loaded, and every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only retrieval tool with no output schema, the description adequately explains what it returns and that it is safe. It could mention return format but is sufficient for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional semantics beyond mentioning 'site' implicitly, meeting baseline without extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool returns the deployment script (specific verb and resource) and distinguishes it as read-only. It differentiates from siblings like get_deployment by specifying it retrieves the script commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Read-only: this cannot change the script,' indicating safe usage. However, it does not mention when to avoid using this tool or suggest alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_serverGet ServerA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal readOnly, openWorld, idempotent. Description adds value by listing what data is returned. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, efficient sentence. Front-loaded with purpose, no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool, description covers return fields, parameters are documented in schema, sibling tools exist. No output schema needed given description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions. Tool description adds no extra parameter meaning beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get one server in full' and lists specific fields (provider, region, sizes, PHP/db versions, IPs, tags, provisioning state), distinguishing it from list_servers (list all) and get_server_php (specific).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use when detailed single-server info is needed; references required param from list_servers. Does not explicitly state when not to use or mention alternatives, but sibling tools context helps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_server_phpGet Server PHP VersionsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`server`	Yes	Server id from list_servers.
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds transparent details about the output (versions, default, patch levels) without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence immediately states the tool's functionality, and the second adds a practical use case. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes what is returned (versions, default, patch levels). It does not specify structure, but for a simple list this is sufficient. Parameter handling is clear from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are fully described in the schema. The description does not add extra meaning beyond stating it's for a server, which is already covered. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns the PHP versions installed on a server, including the default version and patch levels. This distinguishes it from sibling tools like get_server (general server info) and list_servers (list servers).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case ('spotting servers left on an end-of-life version'), implying when to use. It does not explicitly state when not to use, but the purpose is narrowly defined, and alternatives are evident from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_siteGet SiteA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. Description adds behavioral context about org-level addressing, which is valuable beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. First sentence efficiently lists return fields, second sentence provides critical context. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given rich annotations (read-only, idempotent) and full schema coverage, the description sufficiently covers what the tool returns and clarifies a potential organizational confusion. No output schema needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description does not repeat parameter descriptions. However, it adds value by clarifying that 'site' comes from list_sites and that organization is optional with default context, which aids correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get' and resource 'site', lists exact fields returned (domain, aliases, etc.), and clearly distinguishes from sibling list_sites by emphasizing full detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that no server ID is needed because Forge addresses at organization level, which provides clear usage context. However, it does not explicitly mention when to use this versus alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_site_integrationGet Site Integration StatusA

Read-onlyIdempotent

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?".

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`server`	Yes	Server id the site is on.
`integration`	Yes	Which integration to check.
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safe, non-destructive behavior. The description adds useful clarification, especially for the 'laravel-maintenance' integration, without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, and a secondary sentence clarifying an enum value. No unnecessary words. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only status check with 4 parameters (3 required), the description covers purpose and key clarification. No output schema is present, but expected return is boolean. Lacks mention of authentication or prerequisite (e.g., server existence), but annotations cover safety. Overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning for the 'integration' parameter by clarifying that 'laravel-maintenance' answers the maintenance mode question. However, it does not elaborate on 'server', 'site', or 'organization' beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks whether a specific first-party Laravel integration is enabled, listing the possible integrations. This distinguishes it from sibling tools like get_site (which retrieves general site info) and list_certificates, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context but does not explicitly guide when to choose this tool over alternatives. No exclusions or prerequisites are mentioned. Sibling tools include many list operations, but no comparative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_site_logsGet Site LogsA

Read-onlyIdempotent

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. Requires the server:manage-logs scope (whose only write power is clearing logs).

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`type`	Yes	Which log to read.
`server`	Yes	Server id the site is on.
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, openWorld. The description adds transparency by naming required scope (server:manage-logs) and clarifying its only write power (clearing logs). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first covers purpose and options, second adds usage guidance and permission context. No wasted words, front-loaded with main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, log types, and permissions adequately for selection. Missing output format details (e.g., streaming vs lines), but acceptable for a simple tail tool. Output schema not present, so not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal parameter semantics beyond the schema (e.g., log types are listed but schema already has enum). The usage hint ('first place to look') is useful but not parameter-specific.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it tails site logs (application or Nginx access/error), directly linked to troubleshooting errors. It distinguishes well from sibling tools focused on certificates, servers, sites, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly marks this as the first place to check for site errors, providing clear when-to-use guidance. Does not explicitly state when not to use or name alternatives, but sibling tool list makes context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_background_processesList Background ProcessesA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the description's main job is to add context. It does so by naming the returned fields and the purpose (checking workers). No contradictions; the description complements annotations well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the key information: what the tool returns and why to use it. Every word adds value, and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the essential return structure (command, user, process count, status) and purpose. Pagination and response format are not detailed, but the schema parameters (cursor, page_size) imply pagination support, which is adequate for a straightforward list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all seven parameters described in detail. The description does not add additional parameter-level information beyond what is in the schema, so it meets the baseline of 3. No extra value is provided, but none is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists daemons and queue workers on a server, specifying returned fields (command, user, process count, status) and the intended use case (checking queue workers are running and correctly sized). This distinguishes it from sibling tools like list_servers or list_certificates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit use case ('Use it to check queue workers are running and correctly sized'), which helps the agent decide when to invoke this tool. It does not provide negative usage cases or alternatives, but the use case is clear enough for its simple purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_backup_configsList Backup ConfigurationsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds value by specifying the tool returns schedule/retention/destination/databases and is intended to answer about backup existence. It does not cover pagination or sorting behavior, but these are documented in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: it defines the tool, states its purpose, and explains a limitation. Every sentence adds value; there is no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters and no output schema. The description explains the output fields and clarifies a key limitation (no instance listing). It leaves some behavior (sorting, pagination) to the schema, but overall it is sufficient for an agent to understand the tool's purpose and scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not elaborate on parameters beyond stating the output fields; it adds no additional meaning to the parameter definitions already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool lists database backup configurations including schedule, retention, destination, and covered databases. It answers a specific question ('is this server being backed up?') and differentiates from any potential sibling by clarifying it does not list backup instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it lists configurations, not instances. It notes that listing instances requires a different scope and is not exposed here, giving implicit guidance on when to use this tool vs. alternatives. However, it does not explicitly name an alternative tool for instances.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_certificatesList Site CertificatesA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id the site is on.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the authorization requirement (site:meta scope), which is valuable. However, it does not discuss pagination, rate limits, or data format beyond what the schema provides, so the added transparency is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately communicates the tool's purpose and key details. Every word contributes meaning, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 8 parameters, full schema descriptions, and annotations, the description adequately covers the core purpose. However, the lack of output schema and brief description means the agent must infer response format from the schema fields alone. Still, for a listing tool, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not provide additional meaning for parameters beyond the schema. The mention of 'type, status and expiry' relates to the output, not input parameters, so no extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool lists a site's SSL certificates with type, status, and expiry, and identifies it as the read to use for certificate-expiry checks. This clearly distinguishes it from sibling tools like list_sites or list_domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear guidance: it is 'the read to use for certificate-expiry checks' and mentions the required scope ('site:meta'). While it doesn't explicitly list when not to use it or alternatives, the context is sufficient for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_databasesList DatabasesA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`resource`	No	"schemas" (default) for databases, "users" for database users.
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds that it only returns names and grants and never reads contents, providing additional behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that efficiently conveys the tool's purpose and constraints without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters and no output schema, the description could better explain the response format. It is adequate but lacks completeness for a tool with complex inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents parameters. The description does not add further meaning to any parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists database schemas or database users and their grants, specifying it never reads contents. This distinguishes it from other list tools but does not explicitly compare to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for schemas or users but lacks explicit guidance on when to choose this over alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_deploymentsList DeploymentsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id the site is on.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the returned fields (commit, author, status, etc.), reinforcing the read-only nature without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant information, front-loaded with purpose and key use cases. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although no output schema exists, the description mentions the type of data returned (commit, author, status, etc.). It does not explicitly discuss pagination, but parameters like cursor and page_size are documented in the schema. Good enough for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific guidance, but the schema already describes each parameter adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists a site's deployment history with specific fields (commit, author, status, duration, timestamps) and distinguishes from get_deployment, which inspects a single deployment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases: finding when a site last shipped or identifying a failed deployment to inspect with get_deployment. Could be more explicit about when not to use it, but the guidance is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_domainsList Site DomainsA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id the site is on.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the returned data includes aliases and certificate state, which is beyond the annotation hints. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and contains no extraneous words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks output schema details, but the annotations and parameter schema compensate somewhat. It could mention pagination or the exact return format, but it's still mostly complete for a list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all 8 parameters. The description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists domains attached to a site, including aliases and certificate state. It distinguishes from sibling tool list_certificates by mentioning pairing for SSL audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly suggests pairing with list_certificates to audit SSL expiry, providing clear usage context. It implies when to use this tool (to view domains and their certificate states) and hints at a related tool for deeper analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_organizationsList OrganisationsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and behavioral traits. The description adds value by specifying the exact resource (organisations) and return fields (slugs), which is beyond the annotations' scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no superfluous information. Front-loaded with the key action and resource, followed by essential context. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool, the annotations, and the full schema coverage, the description provides complete context. It explains the role of this tool in the workflow and how it connects to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the 5 parameters. The description does not add parameter information, but also does not need to. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list', the resource 'organisations', and what it returns ('with their slugs'). It distinguishes itself from sibling tools by being the starting point to obtain slugs needed by other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent to start here when the organisation slug is unknown, and notes that other tools require the slug. Provides clear context for when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_scheduled_jobsList Scheduled JobsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`site`	No	Restrict to one site; omit for all jobs on the server.
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, indicating safe, non-destructive behavior. The description adds value by specifying the displayed fields (command, user, frequency, last run state) and the scoping options (server or site), which are not covered by annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The first sentence identifies the resource and output, the second clarifies the use case. Every word earns its place, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains the returned fields (command, user, frequency, last run state) and the two scopes. It misses mentioning pagination or cursor behavior, but those are in the schema. Overall, it provides sufficient context for an agent to understand the tool's purpose and outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond hinting at the 'site' parameter's role. It does not elaborate on other parameters like sort, cursor, filter, etc., which are adequately described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists cron/scheduled jobs with specific scope (server or site) and details shown (command, user, frequency, last run state). The use case 'confirm a schedule exists and is firing' adds precision, distinguishing it from other listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage guidance ('use it to confirm a schedule exists and is firing'). However, no direct comparison with sibling tools or when-not-to-use scenarios are given, but the context is clear enough for a simple listing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_server_eventsList Server EventsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id from list_servers.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, open-world, and idempotent behavior. The description goes beyond by detailing what events are covered (provisioning steps, restarts, config changes, who triggered them, success/failure), which adds valuable behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every phrase adds value. No redundancy or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and no output schema, the description could provide more context on the return structure or pagination. It explains the essence well but lacks details on what the response contains, leaving some gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter well-described in the schema itself (e.g., 'Server id from list_servers.'). The description does not add any parameter-specific meaning beyond what's already in the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists recent Forge activity for a server, including specific event types and success status. It effectively distinguishes from sibling tools like list_servers by positioning itself as an audit trail, and the concrete examples ('provisioning steps, service restarts, configuration changes') give specific verb+resource understanding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use context, explicitly calling it 'the first place to look when something changed unexpectedly.' However, it does not discuss when not to use the tool or provide alternatives, so it misses some usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_serversList ServersA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, so the description's behavioral disclosure is supplementary. It adds that the tool supports filter/sort/include and mentions the include parameter, which provides useful operational context beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first lists the returned fields, second gives actionable usage advice. Every sentence is purposeful and concise. Information is front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main purpose and output fields. With 6 parameters fully documented in the schema and no output schema, the description adequately describes what the tool returns and how to use it. The mention of pagination or cursor is missing but schema covers it. The guidance to find server ids completes the context for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters are already documented in the schema. The description adds value by recommending a specific value for include ("tags"), which provides semantic guidance. It does not repeat schema descriptions, making it efficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list), the resource (servers in an organisation), and enumerates key returned fields (provider, region, size, PHP version, IP addresses, provisioning status). This distinguishes it from sibling tools like get_server (single server) or list_sites (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit advice to 'use this to find a server id for the other tools' provides clear context for when to use this tool. It also suggests trying include="tags" to enrich results, though it does not explicitly state when not to use it. The context is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_site_commandsList Site Command HistoryA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`site`	Yes	Site id from list_sites.
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`server`	Yes	Server id the site is on.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's statement that this is an audit read and cannot run a command reinforces but does not substantially add beyond the annotations. No contradictions are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, efficiently conveying the tool's purpose and key limitation. There is no extraneous content, and the important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, nested objects, and no output schema, the description is minimal. It does not explain pagination, response format, or how to interpret the history. For a simple list endpoint, it is adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details beyond what the schema provides, so it meets but does not exceed expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the history of commands run from a site's Commands panel, including who ran them and when. It also distinguishes itself by noting it is an audit read and cannot run a command, which helps differentiate from sibling tools like list_server_events or get_site.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies that this tool is for auditing purposes and not for running commands, providing clear context on when to use it. However, it does not explicitly mention when not to use it or point to alternative tools for running commands, leaving some guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sitesList SitesA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Comma-separated fields to sort by; prefix with "-" to reverse (e.g. "-created_at").
`cursor`	No	Pagination cursor from a previous response's meta.next_cursor.
`filter`	No	Field filters, e.g. {"name": "acme-web"}. Supported fields vary by endpoint.
`include`	No	Comma-separated relationships to embed (e.g. "tags,latestDeployment").
`page_size`	No	Items per page (Forge default 30).
`organization`	No	Organisation slug. Optional when the server has a default configured.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by noting that the hosting server is not included by default and how to include it, which is useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. First sentence states purpose and output, second gives usage guidance. All information is front-loaded and essential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists returned fields. Pagination is implicitly covered by schema parameters (cursor, page_size), but not mentioned in description. However, this is acceptable as the schema carries that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, but the description adds concrete usage context for the 'include' parameter (e.g., include="server"), which enhances understanding beyond the schema's generic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List every site' and clearly specifies the resource (sites) and scope (across all servers), listing the fields returned. It distinguishes from listing sites server by server, which is a sibling alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends preferring this over listing sites server by server, and provides concrete guidance on using include="server" to get hosting info. It does not explicitly state when not to use, but the sibling list provides context for alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

20 tool updatesv0.1.0Jul 28, 2026
- First observedforge_get
- First observedget_deployment
- First observedget_deployment_script
- First observedget_server
- First observedget_server_php
- First observedget_site
- First observedget_site_integration
- First observedget_site_logs
- First observedlist_background_processes
- First observedlist_backup_configs
- First observedlist_certificates
- First observedlist_databases
- First observedlist_deployments
- First observedlist_domains
- First observedlist_organizations
- First observedlist_scheduled_jobs
- First observedlist_server_events
- First observedlist_servers
- First observedlist_site_commands
- First observedlist_sites

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-28 13:40 across 20 tools

Disambiguation5/5

Each tool targets a distinct resource or action (e.g., certificates, organizations, servers, sites, deployments, logs, etc.). Even list/get pairs for the same resource are differentiated by returning summaries vs. full details. The generic forge_get tool is explicitly for uncovered endpoints, reducing ambiguity.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (list_* for collections, get_* for single items). The exception is forge_get, which inverts the order, but it's a single outlier and its purpose is clear.

Tool Count5/5

20 tools provide a comprehensive read-only surface covering servers, sites, databases, and configurations without being overwhelming. The count is well-scoped for the domain and includes a generic catch-all for edge cases.

Completeness5/5

The tools cover all major read areas of Laravel Forge: organization, server, site, deployment, log, job, process, database, backup, and integration information. The forge_get tool fills any gaps by allowing arbitrary GET requests to documented endpoints, ensuring no important read operations are missing.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
mcp-server A
ar.com.muovi
Read-only MCP server for Muovi, Argentina's trust-first local services marketplace (6 tools).
E-commerce & Retail
621
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2

Related MCP Servers

Laravel Forge MCP Server
Cloud Platforms Developer Tools
JordanDalton
F
license
D
quality
D
maintenance
A minimalist MCP server that integrates with Laravel Forge, allowing users to manage their Laravel Forge servers, sites, and deployments through AI assistants like Claude Desktop, Windsurf, or Cursor.
Updated a year ago (2025-06-19 00:08 UTC)
1
2
-
Forge MCP Server
Cloud Platforms Developer Tools CI/CD & DevOps
ranium
A
license
Not graded
quality
D
maintenance
Integrates with the Laravel Forge API to provide comprehensive management of servers and sites. It enables users to perform health checks, monitor logs, create resources, and execute deployment tasks through MCP-compliant tools.
Updated a year ago (2025-07-14 12:07 UTC)
27
2
MIT
forge-mcp-server
Cloud Platforms Developer Tools CI/CD & DevOps
bretterer
A
license
B
quality
D
maintenance
MCP server for managing Laravel Forge servers, sites, and deployments via the Forge API.
Updated a year ago (2025-06-02 02:45 UTC)
12
818
8
MIT
@rarecloudio/mcp-serverofficial
Cloud Platforms Developer Tools Payments & Billing
RareCloudio
A
license
A
quality
B
maintenance
Read-only MCP server for the RareCloud API, enabling AI agents to list servers, browse the catalog, check billing, and plan deployments.
Updated 2 months ago (2026-07-14 21:28 UTC)
100
16
MIT

laravel-forge-readonly-mcp

Install

Claude Code

Claude Desktop / any MCP client

Options

Tools

Log and output tools return the tail

Token scopes: the part worth reading

The two log scopes that also grant writes

What it deliberately won't read

…and one field, wherever it appears

…and secrets inside log text

How read-only is enforced

Rate limiting

Development

Using this behind an MCP gateway

Licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@rarecloudio/mcp-serverofficial