laravel-forge-readonly-mcp

Get Server Event Output

get_server_event_output

Read-onlyIdempotent

Fetch a Forge server event's output by event ID to troubleshoot failed provisioning steps, service restarts, or configuration changes.

Instructions

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

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>",
      "event": "<event>"
    },
    "name": "get_server_event_output"
  }
}

Input Schema

Name	Required	Description
`event`	Yes	Event id from list_server_events.
`server`	Yes	Server id from list_servers.
`tail_lines`	No	Return only the last N lines, where failures appear (default 200). Output is additionally capped by character count, so a very long single line cannot flood the response.
`organization`	No	Organisation slug. Optional when the server has a default configured.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 20, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered structurally. The description adds diagnostic framing ('finding out why a Forge-side operation failed') but says nothing about truncation, pagination, or how much output is returned that isn't already in the schema.

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

Conciseness4/5

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

Two tight sentences, front-loaded with what the tool returns and immediately followed by the prerequisite and the motivating use case. No filler, though the first sentence is a noun phrase rather than a directive verb.

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 diagnostic tool with no output schema and fully documented parameters, the description supplies purpose, prerequisite, and use case. It is nearly complete; only return-shape/pagination expectations remain unaddressed.

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 tail_lines already documents the default, cap, and truncation behavior in the schema itself. The description only echoes the event-id provenance, adding little beyond the structured fields. Baseline 3 applies.

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?

States a specific resource (the output of a Forge server event) and enumerates what an event represents (provisioning step, service restart, config change). It is clearly separable from log/output siblings like get_command_output or get_scheduled_job_output by resource, though it never names those 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?

Gives a concrete prerequisite ('get the event id from list_server_events') and a clear use case, debugging Forge-side failures. No explicit when-not or named alternative tool, 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.