laravel-forge-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a distinct resource/action, and descriptions explicitly separate server logs from site logs, deployment status from deployment logs, and server/service/background-process actions. However, with 28 tools there are several adjacent pairs (get/update env, get/update nginx, list/get server, deployment-related tools) that require careful reading to avoid misselection.
Naming Consistency4/5
Most tools follow a clear forge_<verb>_<noun> snake_case pattern (list/get/update/deploy/run). A few exceptions such as forge_whoami, forge_resolve, forge_call, forge_deployment_status, and forge_server_action break the strict verb_noun pattern, but the consistent forge_ prefix and snake_case keep the set predictable.
Tool Count3/5
28 tools is on the heavy side and above the typical comfortable range, but the Laravel Forge domain is broad and each direct tool maps to a distinct common operation. The generic forge_search_operations/forge_call pair helps justify the count by providing an escape hatch instead of requiring even more bespoke tools.
Completeness5/5
The forge_search_operations + forge_call pair exposes the full 273-operation Forge API, so any capability missing as a direct tool (site CRUD, SSL, firewall, backups, etc.) is still reachable. Common workflows around deployments, env, nginx, logs, services, background processes, cron, and databases are directly covered, leaving no obvious dead ends.
Average 3.9/5 across 27 of 28 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that reboot is a destructive operation requiring --allow-destructive, while the annotations set destructiveHint to false. This is a direct contradiction, so the agent receives conflicting information about the tool's safety profile. It also references a flag that is not present in the input 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?
Two compact sentences with no filler: the first states the tool's function and the second adds the key safety constraint. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic action tool with no output schema and no enum of valid actions, the description provides only one example and a safety flag note. It does not enumerate possible actions, describe response behavior, or clarify how to supply the --allow-destructive flag, leaving significant gaps for correct invocation.
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 the baseline is 3. The description adds meaning by giving 'reboot' as a concrete action example and by warning that destructive actions require --allow-destructive, which is critical operational information not captured in the schema. The flag's absence from the schema slightly weakens this.
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?
Description states a clear verb+resource: it performs actions on the server itself ('Wykonuje akcje na samym serwerze') and gives a concrete example (reboot). It is not fully differentiated from siblings like forge_run_command or forge_restart_service, but the core purpose is clear.
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 server-level action usage and gives an important safety condition (reboot requires --allow-destructive), but it does not explicitly say when to prefer this tool over alternatives or when not to use it. The guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Pobiera' is consistent with those hints. It adds only the detail that the script contains deploy commands; no additional behavioral traits such as auth requirements, rate limits, or return format are disclosed.
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 sentence with no fluff, front-loading the action. The phrasing 'skryptu wdrozeniowego site' is slightly awkward, but it remains compact and readable.
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 getter with only two parameters, the description plus annotations and parameter schema cover the essential calling context. No output schema exists, but the tool's purpose implies the returned content is the script text, so nothing critical is missing.
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% and both parameters have meaningful descriptions: site is a domain or site ID, and org defaults to server config. The tool description does not add parameter-specific information beyond the schema, so it meets the baseline without compensating further.
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 uses a specific verb and resource: 'Pobiera tresc skryptu wdrozeniowego' (gets the content of the deployment script) and clarifies the script is 'komendy uruchamiane przy kazdym deployu'. It makes the tool's object clear, but does not explicitly contrast it with sibling tools like forge_update_deployment_script or forge_get_deployment_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The reader can infer it is for inspecting the commands run on deploy, but the description provides no exclusions or comparison with related operations, so an agent is left to guess when to choose this over get_deployment_log or deployment_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool can execute any of 273 operations, which includes destructive Forge API operations, yet the annotations claim destructiveHint=false. This is a direct contradiction. The description also gives no warning about side effects, permissions, or the risk of mutation/deletion.
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?
Three short sentences each serve a distinct purpose: what the tool does, how to discover operations, and how the organization parameter is resolved. There is no filler or redundancy.
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?
The core invocation flow is covered: operationId, search tool, and organization fallback are all mentioned. However, for a generic executor of 273 operations with no output schema, the description omits safety guidance, return-shape expectations, and when to prefer dedicated sibling tools, especially given the destructiveHint contradiction.
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?
The input schema already documents all five parameters, so the baseline is 3. The description adds meaningful value by revealing that a missing {organization} path parameter is injected from server configuration, and by connecting operationId to the forge_search_operations workflow.
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 that the tool executes any of 273 Laravel Forge API operations by operationId, making the generic dispatch purpose unmistakable. It does not explicitly contrast itself with the specific sibling tools, but the 'any of 273' scope and the pointer to forge_search_operations make it distinguishable.
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?
It tells the agent how to find the right operationId using forge_search_operations and explains that the missing {organization} path parameter is auto-filled from server configuration. It does not explicitly say when to prefer the specific sibling tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the returned output fields (status, start/end times) and that only recent deployments are returned, but it does not explain ordering, limits, pagination, or what 'recent' means.
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 with no filler. It conveys the resource, action, and output fields efficiently, and every word contributes to understanding what the tool does.
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?
This is a simple two-parameter, read-only list operation with a well-covered schema, so the description is largely sufficient. The main gap is the lack of detail about result limits or ordering, but no output schema exists and the description already tells the agent what the response will contain.
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%, with both 'org' and 'site' documented directly in the input schema. The tool description does not add new parameter details beyond echoing 'site', so it provides no meaning beyond the schema, which sets the baseline at 3.
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 states a specific verb ('Wypisuje' – lists) and resource ('ostatnie wdrożenia site' – recent deployments for a site), and specifies returned fields: status, start time, and end time. It is clearly not a single-deployment lookup like forge_deployment_status, though it does not explicitly name or distinguish itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to prefer it over alternatives such as forge_deployment_status or forge_get_deployment_log. There are no explicit conditions, exclusions, or mention of sibling tools, so an agent must infer usage solely from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says stopping is a destructive operation requiring --allow-destructive, but the annotations declare destructiveHint=false. This is a direct contradiction between prose and structured metadata, leaving the agent with irreconcilable signals about destructive potential.
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-load the main action and add the critical destructive-stop warning without redundancy. Every sentence earns its place.
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?
The description is adequate for a simple action tool, but it mentions a required --allow-destructive flag that is not an input schema field, and it gives no indication of return behavior. Given no output schema and a destructive nuance, more detail is needed to be fully complete.
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 documents all parameters. The description adds useful context about queue workers and the destructive-stop flag, but the flag is not present in the input schema, which creates a small semantic gap.
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 specific verbs ('restartuje, uruchamia albo zatrzymuje') and a clear resource ('proces w tle na serwerze'), and explicitly ties the tool to queue-worker restarts. This distinguishes it from sibling tools like forge_restart_service and forge_server_action.
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 tells agents when this is appropriate ('tak restartuje sie workery kolejek'), giving concrete usage context. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful informational context about what the status reports, but it does not disclose additional behavioral traits such as polling behavior, output shape, or error conditions. There is no contradiction with 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 entire description is one focused sentence that front-loads the verb and resource and then adds only meaningful detail about the status content. There is no filler or redundant explanation.
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?
This is a low-complexity tool with one required parameter, no output schema, and no nested objects. The description covers the essential return semantics, the schema covers inputs, and the annotations cover side-effect safety. It would be slightly stronger with an explicit usage note, but not much is missing.
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 input schema already documents both 'org' and 'site' adequately. The description repeats 'site' but adds no new meaning about parameter formats, defaults, or relationships beyond what the 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 uses a specific verb ('Pokazuje'/'shows') and a clear resource ('status wdrożenia site'/'deployment status of site'), and it spells out exactly what is reported: whether the deployment is ongoing, finished, and when it started. This differentiates it from nearby tools like forge_get_deployment_log, which handles logs rather than status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as forge_deploy_site, forge_list_deployments, or forge_get_deployment_log. The agent is left to infer that this is the status lookup tool based only on the name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower; the description adds genuine value beyond them by disclosing that the result contains secrets in plaintext and must not be shared publicly. This is a materially important behavioral trait for an agent handling the output. Nothing in the description contradicts 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 short sentences with purpose front-loaded and the critical security caution second. Every sentence earns its place and there is zero waste. The Polish language of the description is consistent within the tool's evident locale, so it is not penalized.
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 tool with full schema coverage and safety annotations, the description covers everything needed to make the call correctly. With no output schema present, the description does not specify the exact return format, but the plaintext-secrets warning reliably conveys the most important expectation about the response. Minor gaps remain only around error behavior and response parsing details.
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% — both 'org' and 'site' are already documented in the schema. The description adds no parameter-level meaning or constraints, so it meets the baseline of 3 but does not exceed it.
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 states a specific verb ('Pobiera' – gets/fetches) and a precise resource (the .env file of a site), so an agent understands exactly what the tool does. It does not explicitly distinguish itself from the sibling forge_update_env, though the read-oriented verb and tool name make the contrast mostly self-evident. The Polish title 'Plik .env site' is only a noun phrase, but the description fully compensates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as forge_update_env or forge_get_site. The security warning ('do not paste the result into public places') is a handling caution rather than a tool-selection guideline. An agent is given no when-to-use / when-not-to-use framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered outside the description. The description adds the useful behavioral trait that only the last lines are returned because logs are read from the end, which is not visible in annotations. It does not describe output formatting, but the tail behavior is the key fact.
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?
A single, front-loaded sentence that packs the resource, the three log types, and the tail behavior with no wasted words. It does not repeat schema defaults.
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 read-only site-log tool with a well-covered schema, the core contract is clear: site is required, types are explained, and the response is the last lines. It could be slightly more complete by saying more about the output representation and by pointing to forge_get_server_log for server-level logs, so it falls short of a top score.
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 the baseline is 3, but the description adds real meaning to the type enum by mapping application to the Laravel app log, nginx-error to web-server errors, and nginx-access to traffic. The schema only lists the enum values without those semantic labels.
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 names a specific verb and resource (pobiera logi site) and enumerates the three supported log types, so an agent knows exactly what the tool retrieves. It does not explicitly contrast with sibling forge_get_server_log, but the 'site' scoping makes the resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives such as forge_get_server_log or when not to use it. The description gives the main purpose but no situational context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds default-behavior context ('Bez argumentu deployment bierze ostatnie wdrożenie') and a diagnostic use case, but this largely repeats what the schema already documents for the deployment parameter. There is no contradiction with 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 core action is front-loaded, followed directly by the most important default behavior and primary use case. This is an appropriately sized description.
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 log retrieval tool with full schema coverage and safe annotations, the description is mostly complete. It explains the main use case and default behavior, though it does not mention the lines parameter or how output is returned; these are either covered by the schema or reasonably implied by 'pełne wyjście'.
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%, and parameter descriptions already explain defaults and meanings (e.g., deployment defaults to latest, lines defaults to 300, org defaults to server config). The tool description adds little beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pobiera' (retrieves) and the resource 'pełne wyjście wdrożenia' (full deployment output), which distinguishes it from related sibling tools like forge_deployment_status or forge_get_deployment_script. However, it does not explicitly name or compare against those siblings, so differentiation is mostly implicit.
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 a clear use case: diagnosing a failed deploy, and explains that omitting the deployment argument selects the latest deployment, which is the most common scenario. It does not explicitly state when not to use this tool or mention alternatives like forge_deployment_status, but the context is specific enough for an agent to understand when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a use-case hint but no additional behavioral detail such as response format, auth, or failure behavior; there is no contradiction with 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?
One sentence, front-loaded with the verb and resource, followed by a practical use case. There is no redundancy, and the description earns its place without bloat.
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 lookup with annotations covering side effects and a schema covering both parameters, the description is largely complete. The only slight gap is no explicit statement about the return value format, but the resource ('konfiguracje Nginx') makes the expected output reasonably clear.
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 both parameters (org and site) are already documented in the schema. The tool description does not repeat or add parameter-specific meaning beyond what the schema provides, which meets the baseline for full schema coverage.
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?
Description opens with a specific verb, 'Pobiera' (fetches), and names the resource, 'konfiguracje Nginx dla site', clearly identifying the tool's function. It does not explicitly contrast with the sibling update_nginx_config, but the read/fetch orientation is unambiguous.
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?
States a concrete use case: diagnosing redirects and headers ('przydatne przy diagnozowaniu przekierowan i naglowkow'). This gives clear context for when to invoke the tool, though it does not spell out when not to use it or mention an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral context by specifying what data the call returns, which is especially valuable given there is no output 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?
Two short, purposeful sentences. The main behavior and return fields are front-loaded, and the parameter clarification is concise without 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?
For a simple read-only detail operation, the description plus annotations and complete schema cover what an agent needs. It lists the important response fields and explains the site argument format, though it does not discuss error cases like invalid or nonexistent site identifiers.
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%, and both parameters are already documented in the schema. The description only restates that 'site' accepts a domain or identifier, adding no meaningful information beyond the schema.
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 the tool shows detailed data for a single site and enumerates the returned aspects: status, PHP versions, repository, directories, HTTPS, and last deployment status. It is specific and clearly distinct from list-style siblings, though it does not explicitly name a sibling it is not.
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?
Usage context is implied: it returns full details for one site, while forge_list_sites presumably returns a summary of sites. However, the description does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses destructive overwrite behavior: 'Nadpisuje caly skrypt' and warns against deleting existing commands. However, annotations.destructiveHint is false, which contradicts the description's claim that the tool can erase existing script content. Per the rubric, this contradiction forces a score of 1.
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 short, purposeful sentences. The first front-loads the core overwrite behavior, and the second gives the essential safety instruction. There is no filler or redundant restating of the title.
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 crucial context: the whole script is overwritten and the user should fetch existing content first. Parameter details are already fully in the schema. The only blemish is the conflicting destructiveHint annotation, which prevents the definition from being fully coherent.
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 already explains site and content. The description reinforces that content is the complete new script body, but it adds little meaning beyond the schema; it is a solid baseline case.
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 a specific action and resource: it overwrites the entire deployment script for a site. It also implicitly distinguishes itself from the read-only sibling forge_get_deployment_script by naming that tool in the safety warning.
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 tells the agent to first fetch the existing script using forge_get_deployment_script, so existing commands are not lost. This gives a concrete precondition and safe usage workflow, which is strong guidance for when and how to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: destructiveHint=false conflicts with the description's explicit warning that the entire .env file is overwritten and that other variables will be deleted ('skasujesz wszystkie pozostale zmienne'). This is a destructive effect, so the annotation and description directly disagree.
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 filler: the first states the core behavior, the second explains the non-merge warning and the required safety workflow. 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?
For a simple three-parameter update tool, the description covers the key behavioral facts, the safe calling sequence, and the data-loss risk. It lacks an explicit return-value note, but the tool's low complexity and fully documented schema make this a minor gap.
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 parameter descriptions already document site, content, and org. The description adds workflow context—that content must be the fetched-and-modified full file—but does not add parameter-level detail beyond what the schema already 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 opens with 'Nadpisuje caly plik .env site', a specific verb (overwrite) and a specific resource (the site .env file), and distinguishes itself from a merge operation. This clearly separates it from siblings like forge_get_env and forge_update_nginx_config.
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?
It explicitly instructs the agent to fetch the current content with forge_get_env first, modify it, and then call this tool, warning that skipping this deletes all other variables. It also states this is not a merge operation, making the when-to-use / when-not-to-use guidance very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no significant behavioral details beyond the read-only listing action; it does not mention pagination, output shape, or error behavior, but for this simple read-only tool the annotations carry most of the burden.
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 concise sentence with no filler. It front-loads the verb and resource, and every word contributes to understanding what the tool does.
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 tool with two well-documented parameters and no output schema, the description sufficiently states what will be returned (databases and database users). It could go slightly deeper on what information is included for each item, but the low complexity and complete schema make this adequate.
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%, with both 'org' and 'server' already documented in the input schema. The tool description does not add any parameter-level meaning beyond what the schema provides, so the 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 uses a specific verb ('Wypisuje' – lists) and a clear resource ('bazy danych i uzytkownikow bazy na serwerze' – databases and database users on the server). This clearly identifies the tool's output and distinguishes it from sibling list tools like forge_list_sites and forge_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 clear context: the tool is for listing databases and database users on a server. It does not explicitly name alternatives or exclusions, but the server-scoped resource is enough to guide an agent toward this tool versus unrelated list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the returned fields (identifier, domain, status, last deployment status) and the server argument's accept values, but does not go beyond that into pagination, ordering, or other behavioral nuances.
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 short sentences with no filler. It front-loads the core purpose and scope, then adds the key parameter clarification. 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?
For a read-only listing tool with no output schema, the description provides the important response fields and the scope alternatives. Annotations cover the safety context, and the schema covers all parameters. It is complete enough for an agent to select and invoke the tool correctly, though an explicit mention of the 'search' filter could have made it slightly stronger.
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%: all three parameters have descriptions in the input schema. The description repeats that 'server' accepts a name or ID, which the schema already states, and it does not add new meaning to 'org' or 'search'. The baseline of 3 is appropriate because the schema carries the parameter documentation burden.
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 'Wypisuje' (lists) with a clear resource ('site') and a defined scope: within an organization or on a specified server. It also names the returned fields, making it easy to distinguish from singular tools like forge_get_site or server-focused tools like forge_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 clearly communicates the two contexts in which the tool makes sense: listing sites in an organization or on a specific server. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to decide when to use this tool versus a more targeted lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a lookup/transformation operation and enumerates the output shape, but it does not disclose behavior for unresolved inputs or partial matches.
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 concise sentences. The first states the operation and output; the second gives the practical use case. There is no filler or redundant restatement of the tool name.
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?
There is no output schema, but the description explicitly enumerates the returned identifier set {organization, server, site}, which is essential. Combined with the schema's parameter descriptions and the safety annotations, this is nearly complete; only error/edge-case behavior is missing.
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%, with both 'query' and 'org' already explained in the schema. The description mostly restates the same idea (domain or name to identifiers), adding no deeper parameter semantics beyond 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 states a specific verb ('Zamienia' – converts) and a clear resource: it turns a domain or name into a complete set of identifiers {organization, server, site}. It also references forge_call as the downstream consumer, which helps distinguish this resolver from the large sibling list.
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 says this tool is useful when you want to use forge_call, which requires raw identifiers. That gives clear context for when to select it, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to restate that. It adds value by listing the returned data fields, but it does not disclose error behavior, auth requirements, or unknown-server handling.
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 short, dense sentences: the first states the tool's purpose and output content, the second gives the key input behavior. No filler or repetition.
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-only lookup with one required parameter and no output schema, the description fully covers what to pass and what to expect back. The optional org parameter is already documented in 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 the schema already explains both parameters. The description redundantly states that 'server' accepts a name or ID; it adds no new meaning beyond 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 opens with a specific verb and resource ('Pokazuje pelne dane serwera') and enumerates exactly what data is returned. This clearly separates it from siblings like forge_list_servers and forge_get_server_log.
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?
It clearly frames the tool as a single-server details lookup, so when to use it is evident. It does not explicitly name alternatives or exclusions, but it does explain how to identify the target server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by specifying what fields are returned, but it does not disclose potential pagination, ordering, or any response format details. With annotations carrying the safety burden, a 3 is appropriate.
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 short sentences with no filler. The core purpose and returned fields are front-loaded, and the search guidance is presented in the second sentence. Every element 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?
For a simple read-only list operation with two optional parameters, the description plus annotations cover the essential usage context: the resource, output fields, filtering behavior, and safety profile. No critical gap is left for the agent to guess.
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 both parameters (org and search) are already documented in the schema. The description adds the useful detail that search narrows the list by name, which slightly reinforces the schema, but it does not provide substantial meaning beyond it. The baseline 3 is correct.
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 ('Wypisuje' – lists) and a specific resource ('serwery w organizacji'), and enumerates the returned fields: identifier, name, IP address, PHP version, and readiness. This clearly distinguishes it from sibling tools like forge_get_server or forge_list_sites.
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 clearly states this tool lists servers in the organization, which implies it is the right choice when a summary of multiple servers is needed rather than a single server via get_server. It also gives usage guidance for the search parameter to narrow by name, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scoping context (system-level logs by key), but does not describe output format or pagination behavior; with annotations covering side effects, this is adequate.
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 short sentences with no filler. The core purpose and example come first, and the alternative-tool pointer comes second. Every word contributes.
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 log fetch with fully documented parameters and safe annotations, the description provides enough context to call the tool correctly. The main minor gap is not listing possible log keys beyond the one example, but that is not essential for basic correct usage.
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 documents all four parameters including defaults and constraints. The description adds only a key example, which largely duplicates the schema, so a 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?
Description states a specific action: retrieving a server system log by its key, with a concrete example ('nginx-error'). It also explicitly differentiates from forge_get_site_logs, so agents can tell the tools apart without inspecting schemas.
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 tells the agent to use forge_get_site_logs for site-specific logs, which is a clear when-not condition. This prevents a common misuse and is sufficient guidance for a simple read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds a useful behavioral detail about retrieving the output of the last run using job with site, but does not disclose other behavior such as default scope, filtering, or response structure.
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: the first states the main purpose and scope, and the second adds the key invocation detail. There is no filler or repetition of schema fields, and the most important information is front-loaded.
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 read-only tool with four parameters, one required parameter, and no output schema, the description covers the essential invocation context: what it lists, the scope options, and the special job+site usage. It does not describe return fields, but the absence of an output schema lowers the 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%, so the baseline is 3. The description goes beyond the schema by clarifying that 'job' should be provided together with 'site' to see the last run output, and it explains the relationship between 'server', 'site', and cron jobs.
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 ('Wypisuje' – lists) and names the exact resource ('zadania cykliczne (cron)' – scheduled/cron jobs), including the scope ('serwera albo konkretnego site'). This distinguishes it from sibling tools like list_servers, list_sites, list_deployments, and list_background_processes.
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 for when to use the tool: to list cron jobs for a server or for a specific site. It also gives a practical usage instruction ('Podaj argument job razem z site...'), though it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a valuable safety warning beyond the annotations: stopping a service is destructive and requires the --allow-destructive flag. This is consistent with destructiveHint=false in the default case, since the destructive path is gated behind an explicit flag, so no contradiction is 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?
Two short sentences deliver all key information: the action scope, the supported services, and the critical destructive-operation caveat. There is no filler, and the most important operational constraint is placed second for emphasis.
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 four-parameter tool whose schema already documents every field, the description covers the service domain, available actions, and the main safety constraint. It does not describe the return value, but there is no output schema and the action semantics are otherwise clear.
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 the baseline is 3. The description adds meaning beyond the schema by explaining that the stop action is destructive and gated by a flag, which is not evident from the action enum alone.
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 clear action verb set (restart, start, stop) with a specific resource type: services on a server. It further names the exact supported services, which distinguishes it from sibling tools targeting servers, sites, or commands.
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 when to use the tool: whenever a supported service needs restarting, starting, or stopping. However, it does not explicitly contrast it with alternatives such as forge_run_command or forge_server_action, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those hints: it conveys that the tool returns recent events, and that providing an event identifier returns the full output of that event. No contradictions with 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 compact sentences: the first states purpose, the second explains how to get more detail. It is front-loaded, contains no filler, and every sentence contributes actionable guidance.
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 low-complexity read-only tool with fully documented parameters and strong annotations, the description is nearly complete. It does not specify limits on how many events are returned, but nothing an agent needs to make a correct first call is missing.
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 documents all three parameters. The description reinforces that 'event' is an identifier and that passing it yields full output, but it does not meaningfully add semantics beyond what the schema already 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 uses a specific verb and resource: 'Pokazuje ostatnie zdarzenia serwera' (shows recent server events), and frames it as answering 'co sie teraz dzieje z serwerem' (what is happening with the server right now). This clearly distinguishes it from siblings like forge_get_server_log or forge_server_action because it targets a distinct event-stream concept.
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 concrete usage context: it is for checking current server activity, and tells the agent to pass the 'event' argument to get the full output of a specific event. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as mutating, but the description adds important non-obvious behavior: it overwrites the entire configuration rather than patching it, and a bad config can take the site offline. This is valuable risk context beyond what the schema or annotations state.
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 short sentences with no filler. The core action and the critical safety warning are front-loaded, making the description easy to parse and act on.
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 tool with only two required parameters and full schema coverage, this is complete enough: it states what is overwritten, the risk, and the recommended safe workflow. Success/error behavior is not described, but no output schema exists and this is a straightforward mutation.
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 already describes all three parameters with full 100% coverage, including that 'content' is the full new Nginx configuration. The description adds no additional parameter-level meaning, so the 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 uses a specific verb ('Nadpisuje' — overwrites) and clearly identifies the resource: the entire Nginx site configuration. It also implicitly distinguishes itself from the read-only sibling forge_get_nginx_config, so there is no ambiguity about what the tool does.
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?
It gives explicit operational guidance: fetch the current configuration with forge_get_nginx_config before overwriting, and warns that a bad configuration can disable the site. It does not discuss broader alternative selection, but there is no close update sibling, so this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds return-content context but no additional behavioral details such as auth requirements or response format, which is acceptable but not rich.
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 short sentences, front-loads the tool's primary behavior, and adds a practical usage pointer. Every sentence earns its place with no redundancy.
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, parameterless identity/context tool, the description fully covers what an agent needs: what is returned, that it includes slugs, and when to invoke it. The rich annotations and absence of parameters make this sufficiently complete.
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?
The tool has zero parameters, and schema coverage is 100%, so there are no input semantics left ambiguous. The baseline for zero parameters is 4, and the description's mention of organizations and slugs is output context rather than parameter detail.
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 states a clear verb and resource: it shows the logged-in Forge user and their organizations with slugs. This is not a tautology and immediately distinguishes the tool from resource-specific siblings like forge_list_sites or forge_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 explicitly says to start with this tool when unsure which organization owns a resource, giving a clear when-to-use trigger. It does not mention when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the asynchronous default behavior, the polling behavior when wait=true, and the 2-minute waiting cap. This adds meaningful behavioral context that annotations alone do not convey.
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 compact sentences carry all necessary information: the action, the default behavior, the wait option, and the alternative status tool. There is no redundant or filler content.
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 an action that returns no output schema, the description explains the default return ('potwierdzenie startu'), the optional wait mode with timeout, and where to check progress. It is not exhaustive about error behavior or timeout outcomes, but it is sufficient for correct invocation.
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 the schema already documents all parameters. The description adds value by explaining what wait=true actually does (polls status until completion, max 2 minutes), which enriches the bare boolean parameter definition.
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 the specific verb 'Uruchamia' (launches) with the resource 'wdrozenie site' (deployment of site), making the action unmistakable. It clearly distinguishes this deploy operation from status or list siblings like forge_deployment_status and forge_list_deployments.
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 concrete usage context: by default it returns immediately, and if you want to wait for completion you should set 'wait' to true. It also names forge_deployment_status as the tool for checking progress, which gives the agent a clear alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: what background processes are, that passing 'process' returns a log, and the server-level scoping in API v2.
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, front-loaded with the core purpose, and every sentence earns its place. The note about old Forge terminology and API v2 scoping is useful context without bloat.
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 list tool with full schema parameter coverage and safety annotations, the description covers the essential behavioral nuances: what is listed, how to get a log, and server-level ownership. No output schema exists, but the return format is not critical for a list operation of this kind.
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 parameters are already documented. The description adds value beyond the schema by explaining the purpose of the 'process' parameter (returns the log of that process) and clarifying the semantic scope of the list operation (server-wide, not per-site).
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 'Wypisuje' (lists) and the resource 'procesy w tle uruchomione na serwerze', defining exactly what the tool does. It adds helpful clarification that these are queue workers and long-running commands, and distinguishes them from per-site entities.
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 practical usage guidance: pass the 'process' argument to view a specific process log, and notes that in API v2 background processes belong to the server, not a site. It does not explicitly name alternative sibling tools or state when not to use this one, but the context is sufficient for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by stating the tool scans all 273 operations and returns matches with parameter schemas, which clarifies the return behavior without contradicting 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 compact, front-loaded with the core purpose, and each sentence earns its place: what it does, when to use it, and example queries. There is no filler or repetition of schema details.
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?
With a read-only, idempotent annotation profile and a fully documented schema, the description covers what the tool returns ('dopasowania wraz ze schematem parametrow') and how it fits into the broader workflow. Nothing needed for correct selection and invocation is missing.
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 already documents query, tag, and limit. The description reinforces query usage with concrete examples like 'certificate' and 'firewall', but it does not add meaningful semantics for tag or limit beyond what the schema provides. 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 searches all 273 Laravel Forge API operations and returns matches with parameter schemas. It uses a specific verb ('Przeszukuje') and resource, and it is immediately distinguishable from sibling tools like forge_call or forge_get_server because it is explicitly positioned as the discovery mechanism for operations without dedicated 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 says to use this tool when the needed operation does not have its own forge_* tool and to follow up with forge_call. This provides a clear routing rule and names the alternative, leaving no ambiguity about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: it waits by default, returns output, has a one-minute maximum wait, and executes on a production server. This meaningfully supplements the annotations and gives the agent a clear safety picture.
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?
Three sentences with no wasted words: the action is front-loaded, examples are included, behavior is stated, and the production-safety warning is placed at the end. 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?
For a four-parameter tool with no output schema, this description is complete: it explains where the command runs, what it does, how waiting and output work, and why caution is needed. The absence of an output schema is compensated by the explicit statement that output is returned, capped at one minute.
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 the schema already documents all parameters. The description adds extra meaning by clarifying runtime behavior (default wait, one-minute timeout) and providing realistic command examples, which helps the agent understand expected command syntax beyond the bare 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 uses a specific verb and resource: 'Uruchamia komende powloki w katalogu site' (runs a shell command in the site directory). Examples like 'php artisan migrate --force' and 'php artisan cache:clear' make the intent unambiguous and help distinguish it from deployment or server-management siblings.
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 operational context: commands run in the site directory on a production server, and the agent is told to check the command before running it. It does not explicitly name alternatives or when-not-to-use conditions, but for a generic shell command tool the production warning is strong context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![laravel-forge-mcp MCP server](https://glama.ai/mcp/servers/wdevcom/laravel-forge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wdevcom/laravel-forge-mcp)

Score Badge

Copy to your README.md:

[![laravel-forge-mcp MCP server](https://glama.ai/mcp/servers/wdevcom/laravel-forge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wdevcom/laravel-forge-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wdevcom/laravel-forge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server