Skip to main content
Glama
respanai

Respan MCP Server

Official
by respanai

list_logs

Filter and retrieve LLM request logs using server-side filters for precise analysis. Supports pagination, sorting, time ranges, and environment selection.

Instructions

List and filter LLM request logs. Supports pagination, sorting, time range, and server-side filtering.

IMPORTANT: Use the "filters" parameter to filter results server-side. Do NOT fetch all logs and filter client-side.

PARAMETERS:

  • page_size: Number of logs per page (1-50, default 20)

  • page: Page number (default 1)

  • sort_by: Sort field with optional - prefix for descending (e.g. "-cost", "latency")

  • start_time / end_time: ISO 8601 time range (default: last 1 hour, max: 1 week ago)

  • is_test: Filter by test (true) or production (false) environment

  • all_envs: Include all environments

  • include_fields: Array of field names to return (defaults to summary fields). Use get_log_detail for full data.

  • filters: Array of server-side filter objects. Each filter has: field (string), operator (string), value (array). See below.

FILTERS - supported operators: "" (exact match), "not", "lt", "lte", "gt", "gte", "icontains", "startswith", "endswith", "in", "isnull"

FILTERS - supported fields: customer_identifier, custom_identifier, thread_identifier, prompt_id, unique_id, organization_id, organization_key_id, organization_key_name, customer_email, customer_name, trace_unique_id, span_name, span_workflow_name, model, deployment_name, provider_id, prompt_name, status_code, status, error_message, failed, cost, latency, tokens_per_second, time_to_first_token, prompt_tokens, completion_tokens, total_request_tokens, environment, log_type, stream, temperature, max_tokens, metadata__, scores__

EXAMPLE - find all error logs (status_code != 200): { "filters": [{"field": "status_code", "operator": "not", "value": [200]}], "sort_by": "-id", "page_size": 20 }

EXAMPLE - find logs for a specific model and customer: { "filters": [ {"field": "model", "operator": "", "value": ["gpt-4"]}, {"field": "customer_identifier", "operator": "icontains", "value": ["user"]}, {"field": "cost", "operator": "gt", "value": [0.01]} ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (default 1)
filtersNoArray of server-side filters. Each filter has field, operator, and value. Example: [{"field": "status_code", "operator": "not", "value": [200]}]
is_testNoFilter by test environment (true) or production (false)
sort_byNoSort field. Prefix with - for descending order. Options: id, -id, cost, -cost, latency, -latency, time_to_first_token, -time_to_first_token, prompt_tokens, -prompt_tokens, completion_tokens, -completion_tokens, all_tokens, -all_tokens, total_request_tokens, -total_request_tokens, tokens_per_second, -tokens_per_second. Also supports scores__<evaluator_id> for sorting by evaluation scores.
all_envsNoInclude logs from all environments
end_timeNoEnd time in ISO 8601 format. Default: current time
page_sizeNoNumber of logs per page (1-50, default 20)
start_timeNoStart time in ISO 8601 format. Default: 1 hour ago. Maximum: 1 week ago
include_fieldsNoFields to include in response. Defaults to summary fields (unique_id, model, cost, status_code, latency, timestamp, customer_identifier, prompt_tokens, completion_tokens, status, error_message, log_type). Use get_log_detail for full log data.
Behavior4/5

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

No annotations are present, so the description carries the burden, and it does so well: it discloses default time window, max lookback, default page size, summary-field behavior, and the server-side filtering expectation. It stops short of discussing response pagination metadata or authorization, but it is a solid disclosure for a read/list tool.

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 long but highly organized: a one-line summary, an important usage warning, parameter explanations, filter references, and worked examples. Every section earns its place for a high-complexity filtering tool, and the structure makes it scannable.

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?

The tool has 9 optional parameters and a complex filter subsystem, and this description covers the vast majority of it: fields, operators, parameter bounds, defaults, and examples. The only notable gap is the absence of an explicit response-shape note, especially with no output schema, though include_fields defaults partially address this.

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 value with filter-field explanations, operator semantics, and two worked examples. It also lists fields not present in the schema's nested field description, though it omits 'iexact' and 'contains' from its operator list even though the schema enum includes them.

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?

Starts with a specific verb+resource: 'List and filter LLM request logs', and immediately names pagination, sorting, time range, and server-side filtering. It also differentiates from get_log_detail by noting list_logs returns summary fields while full log data lives in get_log_detail.

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?

Provides explicit guidance to filter server-side ('Do NOT fetch all logs and filter client-side') and points to get_log_detail when fuller data is needed. It does not compare against list_traces or other trace/span siblings, but for the log-listing use case the usage context is clear.

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/respanai/respan-mcp'

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