laravel-forge-mcp

Akcja na serwerze

forge_server_action

Execute server-level actions such as reboot. Destructive commands require the --allow-destructive flag to confirm execution.

Instructions

Wykonuje akcje na samym serwerze, na przyklad reboot. Reboot jest operacja destrukcyjna i wymaga flagi --allow-destructive.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "server": "<server>",
      "action": "<action>"
    },
    "name": "forge_server_action"
  }
}

Input Schema

Name	Required	Description
`org`	No	Slug organizacji, domyslnie z konfiguracji serwera
`action`	Yes	Nazwa akcji, np. "reboot"
`server`	Yes	Nazwa albo identyfikator serwera

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 1, 2026

TDQS

B3.1/5.0

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.