past.dev

Show a request

get_request

Read-onlyIdempotent

One call from a project's request log, as the Requests detail drawer shows it: method, path, status, the request id, when it arrived, how long it took, the key, the outcome and phase, what it was billed, and the allowlisted headers with the request and response bodies. Past the plan's retention window the row stays and the payload is gone. Mirrors the Requests detail screen; needs project Read on the project.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`project`	No	The project's slug, exactly as get_viewer or list_projects returned it. May be omitted when the organization has one live project.
`requestId`	Yes	The request id (req_…), exactly as list_requests returned it or as the X-Request-Id header carried it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- changedInput schema / properties / project / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
First observedOct 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations don't: the retention-window caveat that the row persists but the payload is gone, and the project Read authorization requirement.

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?

Front-loaded with the core idea in the first clause, then the return-field enumeration, a caveat, and the prerequisite. The field list is long and somewhat run-on, but every item is informative for an agent with no output schema, so it 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?

With no output schema, the description carries the return-value burden and does so thoroughly by enumerating the returned fields, plus it covers the retention edge case and the permission requirement. Nothing an agent needs to invoke or interpret this read 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 coverage is 100%, so both parameters (project and requestId) are already fully documented in the schema, including the slug format and the req_ id format. The description does not add syntax or format detail beyond that, making the baseline 3 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 names a specific verb+resource ('One call from a project's request log') and immediately distinguishes itself from the plural sibling list_requests by scoping to a single request detail view. It also enumerates the payload fields, so an agent knows exactly what this returns versus broader log queries.

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 is implied through 'as the Requests detail drawer shows it' and 'Mirrors the Requests detail screen,' and the stated 'needs project Read' prerequisite is useful context. However, it never explicitly names when to pick this over list_requests or request_histogram, and gives no exclusions, leaving routing to inference.

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

All past.dev tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?