Skip to main content
Glama
hofill
by hofill

list_requests

Retrieve captured HTTP, DNS, SMTP, or TCP requests with filtering options to inspect and manage network traffic data in RequestRepo MCP.

Instructions

List captured requests with optional filtering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
request_typeNo
include_rawNo
include_bodyNo
max_bytesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The core business logic handler for list_requests tool. Validates parameters (limit, offset, max_bytes), resolves configuration, calls the requestrepo client's list_requests method, optionally filters by request_type, and serializes the results using serialize_request.
    def list_requests(
        self,
        *,
        limit: int = 100,
        offset: int = 0,
        request_type: RequestType | None = None,
        include_raw: bool = False,
        include_body: bool = False,
        max_bytes: int | None = None,
    ) -> dict[str, Any]:
        if limit < 1:
            raise ValueError("limit must be >= 1.")
        if offset < 0:
            raise ValueError("offset must be >= 0.")
    
        resolved_max_bytes = self._resolved_max_bytes(max_bytes)
        requests = self._client().list_requests(limit=limit, offset=offset)
        if request_type is not None:
            requests = [request for request in requests if request.type == request_type]
    
        return {
            "limit": limit,
            "offset": offset,
            "request_type": request_type,
            "count": len(requests),
            "requests": [
                serialize_request(
                    request,
                    include_raw=include_raw,
                    include_body=include_body,
                    max_bytes=resolved_max_bytes,
                )
                for request in requests
            ],
        }
  • MCP tool registration using @mcp.tool() decorator. This exposes the list_requests functionality as an MCP tool with parameters including limit, offset, request_type, include_raw, include_body, and max_bytes.
    @mcp.tool()
    def list_requests(
        limit: int = 100,
        offset: int = 0,
        request_type: RequestType | None = None,
        include_raw: bool = False,
        include_body: bool = False,
        max_bytes: int = 65536,
    ) -> dict[str, Any]:
        """List captured requests with optional filtering."""
        return resolved_service.list_requests(
            limit=limit,
            offset=offset,
            request_type=request_type,
            include_raw=include_raw,
            include_body=include_body,
            max_bytes=max_bytes,
        )
  • RequestType schema definition used for filtering requests by type (http, dns, smtp, tcp). This type is used as the request_type parameter in the list_requests tool.
    RequestType = Literal["http", "dns", "smtp", "tcp"]
  • Helper function that serializes request objects (HttpRequest, DnsRequest, SmtpRequest, TcpRequest) into dictionaries. Called by list_requests handler to format each request with optional raw data and body content based on include_raw and include_body flags.
    def serialize_request(
        request: HttpRequest | DnsRequest | SmtpRequest | TcpRequest,
        *,
        include_raw: bool,
        include_body: bool,
        max_bytes: int,
    ) -> dict[str, Any]:
        payload: dict[str, Any] = {
            "id": request.id,
            "type": request.type,
            "uid": request.uid,
            "ip": request.ip,
            "country": request.country,
            "date_unix": request.date,
            "date_iso": _iso_from_unix(request.date),
        }
    
        if isinstance(request, HttpRequest):
            payload.update(
                {
                    "method": request.method,
                    "path": request.path,
                    "http_version": request.http_version,
                    "headers": request.headers,
                }
            )
            if include_body and request.body is not None:
                payload["body"] = bytes_envelope(request.body, max_bytes=max_bytes)
        elif isinstance(request, DnsRequest):
            payload.update(
                {
                    "port": request.port,
                    "query_type": request.query_type,
                    "domain": request.domain,
                    "reply": request.reply,
                }
            )
        elif isinstance(request, SmtpRequest):
            payload.update(
                {
                    "command": request.command,
                    "data": request.data,
                    "subject": request.subject,
                    "from_addr": request.from_addr,
                    "to": request.to,
                    "cc": request.cc,
                    "bcc": request.bcc,
                }
            )
        elif isinstance(request, TcpRequest):
            payload.update({"port": request.port})
    
        if include_raw:
            payload["raw"] = bytes_envelope(request.raw, max_bytes=max_bytes)
    
        return payload
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'optional filtering' but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by limit/offset but not explained), or what 'captured' means in context. The description is minimal and lacks necessary operational context for safe use.

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 extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose. While it lacks detail, every word earns its place by stating the basic action and scope efficiently.

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?

Given the complexity (6 parameters, no annotations, but has output schema), the description is incomplete. The output schema existence means return values needn't be explained, but the description doesn't cover parameter meanings, usage context, or behavioral traits. It's minimally adequate for a simple list tool but leaves significant gaps for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'optional filtering' but doesn't explain what parameters are available or their purposes. The six parameters (limit, offset, request_type, include_raw, include_body, max_bytes) are undocumented in both schema and description, leaving their semantics unclear. The description adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List captured requests with optional filtering' clearly states the verb ('List') and resource ('captured requests'), but it's somewhat vague about what 'captured requests' specifically are. It doesn't distinguish this tool from sibling tools like 'list_dns' or 'list_files', leaving ambiguity about the scope of 'requests' versus other listable resources.

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 provides no guidance on when to use this tool versus alternatives. It mentions 'optional filtering' but doesn't specify scenarios where filtering is appropriate or when to choose this over other list tools like 'list_dns' or 'list_files'. No prerequisites, exclusions, or comparison to siblings are provided.

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

Install Server

Other Tools

Latest Blog Posts

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/hofill/RequestRepo-MCP'

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