Skip to main content
Glama
ahmedbally

clockwork-mcp-remote

by ahmedbally

explain_request_flow

Get a high-level summary of a Laravel request's lifecycle by providing its Clockwork request ID, helping you quickly understand the sequence of events and debug issues.

Instructions

Get high-level summary of what happened in a request

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenNoPre-authenticated X-Clockwork-Auth token (alternative to password)
baseUrlNoClockwork application base URL (e.g. https://my-app.test). Overrides CLOCKWORK_BASE_URL / local storage for this call
passwordNoClockwork authentication password
usernameNoClockwork authentication username
requestIdYesClockwork request ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of explaining behavior. 'Get high-level summary' implies a read operation, but it does not disclose what the summary contains, whether it requires authentication (though params suggest it), or what format the response takes.

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, efficient sentence with no wasted words. It is concise, though slightly under-specified for a tool that needs to be differentiated from many similar sibling tools.

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?

The description is minimal: no output schema exists, no annotations are provided, and no relationship to siblings is explained. An agent could not tell what 'high-level summary' includes or how it differs from get_request or get_timeline, so the definition is incomplete for correct tool selection.

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 all five parameters. The description does not add meaning beyond the schema; it only implies requestId is the focus. Baseline 3 is appropriate because the schema handles parameter documentation.

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 clear verb ('Get') and resource ('request'), and signals a high-level summary rather than raw data. However, it does not distinguish this from siblings like get_request or get_timeline, so it is clear but lacks sibling differentiation.

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 guidance is provided about when to use this tool instead of get_request, get_timeline, or compare_requests. There is no mention of context, prerequisites, or exclusions, leaving the agent to guess.

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