Provides access to Cloudflare Workers logpush data stored in R2 buckets, enabling log browsing, searching with filters, error tracking, and aggregated statistics for production and staging environments.
Reads and analyzes Cloudflare Workers Trace Events logpush data, allowing users to list log dates, search logs by worker name, status code, and outcome, retrieve error logs and exceptions, and access the most recent log entries.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Logpush MCP show me yesterday's error logs from production"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for reading Cloudflare Workers logpush data from R2 buckets.
List available log dates by environment (production/staging)
Browse and read individual log files
Search logs with filters (worker, status code, outcome, text)
Get aggregated statistics
Quick access to errors and exceptions
Get latest logs with one command
Related MCP server: Log MCP Server
# Using uv (recommended)
uv pip install -e .
# Or with pip
pip install -e .Set these environment variables (or create a .env file):
R2_ACCOUNT_ID=your_account_id
R2_ACCESS_KEY_ID=your_access_key_id
R2_SECRET_ACCESS_KEY=your_secret_access_key
R2_BUCKET_NAME=your-bucket-nameGet R2 API credentials from: Cloudflare Dashboard > R2 > Manage R2 API Tokens
uv run logpush-mcpAdd to your Claude Desktop config (~/.config/claude/claude_desktop_config.json):
{
"mcpServers": {
"logpush": {
"command": "uv",
"args": ["run", "logpush-mcp"],
"cwd": "/path/to/arross-cf-mcp",
"env": {
"R2_ACCOUNT_ID": "your_account_id",
"R2_ACCESS_KEY_ID": "your_access_key_id",
"R2_SECRET_ACCESS_KEY": "your_secret_access_key",
"R2_BUCKET_NAME": "your-bucket-name"
}
}
}
}list_log_datesList available date folders in the bucket.
environment: production, staging, or omit for all
limit: max dates to return (default 30)
list_log_filesList log files for a specific date.
date: YYYYMMDD format
environment: production or staging
limit: max files (default 50)
cursor: pagination token
read_log_fileRead contents of a specific log file.
path: full object key
limit: max entries (default 100)
search_logsSearch logs with filters.
date: YYYYMMDD format
environment: production or staging
script_name: filter by worker name
status_code: exact status code
status_gte: status >= value (e.g., 400)
status_lt: status < value
outcome: "ok" or "exception"
search_text: search in URL and log messages
limit: max entries (default 50)
get_log_statsGet aggregated statistics for a date.
date: YYYYMMDD format
environment: production or staging
get_errorsGet error logs and exceptions.
date: YYYYMMDD format
environment: production or staging
script_name: optional filter
limit: max entries (default 50)
get_latestGet the most recent log entries.
environment: production or staging
script_name: optional filter
limit: max entries (default 50)
Expects Cloudflare Workers Trace Events logpush format:
bucket/
├── production/YYYYMMDD/*.log.gz
└── staging/YYYYMMDD/*.log.gzFiles are NDJSON with Cloudflare's workers_trace_events schema.
Go to fastmcp.cloud
Sign in with your GitHub account
Click "Create Project"
Select this repository (logpush-mcp)
FastMCP will auto-detect the pyproject.toml entry point
In the FastMCP Cloud dashboard, add these environment variables:
Variable | Description |
| Your Cloudflare account ID |
| R2 API token access key ID |
| R2 API token secret access key |
| Name of your logpush R2 bucket |
Click "Deploy" - FastMCP handles the rest automatically.
FastMCP Cloud provides a URL like https://your-project.fastmcp.cloud/mcp
For Claude Desktop, add to your config:
{
"mcpServers": {
"logpush": {
"command": "npx",
"args": ["mcp-remote", "https://your-project.fastmcp.cloud/mcp"]
}
}
}Go to Cloudflare Dashboard → R2 → Manage R2 API Tokens
Create a new API token with:
Permissions: Object Read & Write
Scope: Specific bucket (your logpush bucket)
Copy the Access Key ID and Secret Access Key
MIT
Get error logs and exceptions for a specific date.
Args: date: Date in YYYYMMDD format. environment: Environment (production or staging). script_name: Filter by worker script name (optional). limit: Maximum entries to return (default 50).
Returns: Dict with error entries including exceptions and error-level logs.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| environment | No | production | |
| script_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves error logs and exceptions, implying a read-only operation, but doesn't mention permissions, rate limits, pagination, or what happens if no errors exist for the date. This leaves significant behavioral gaps for a tool with 4 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement followed by Args and Returns sections. It's appropriately sized at 4 sentences, with each sentence earning its place by defining the tool, detailing parameters, and specifying the return type. However, the front-loading could be slightly improved by integrating usage context earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description does well on parameters but lacks behavioral context. The output schema exists (Returns specifies a Dict), so return values don't need explanation, but the tool's interaction with siblings and operational constraints are underdeveloped. This makes it adequate but with clear gaps in a moderately complex context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining all 4 parameters: date format (YYYYMMDD), environment options (production or staging), script_name as an optional filter, and limit with default 50. This adds essential meaning beyond the bare schema, making parameter usage clear and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get error logs and exceptions for a specific date.' It specifies the resource (error logs/exceptions) and verb (get), but doesn't explicitly differentiate from sibling tools like get_latest or search_logs, which might also retrieve error-related data. This makes it clear but not fully sibling-aware.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_latest, search_logs, or list_log_dates. It mentions filtering by date and optional script_name, but doesn't explain scenarios where this tool is preferred over others, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent log entries.
Args: environment: Environment (production or staging). script_name: Filter by worker script name (optional). limit: Maximum entries to return (default 50).
Returns: Dict with the most recent log entries.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | production | |
| script_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool returns 'the most recent log entries' and specifies parameters, it lacks critical behavioral details such as authentication requirements, rate limits, error handling, or whether it's a read-only operation (though implied by 'Get'). For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by an 'Args' section detailing parameters and a 'Returns' section. Each sentence earns its place, with no wasted words, though the formatting could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains the purpose and parameters adequately. Since an output schema exists, the description doesn't need to detail return values beyond the high-level 'Dict with the most recent log entries,' which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does so by explaining all three parameters: 'environment' (with allowed values 'production or staging'), 'script_name' (as an optional filter), and 'limit' (with a default of 50). This adds meaningful context beyond the bare schema, though it doesn't cover edge cases or format details for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the most recent log entries.' This specifies the verb ('Get') and resource ('most recent log entries'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_errors' or 'search_logs,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With sibling tools like 'get_errors,' 'search_logs,' and 'list_log_dates,' there's no indication of when this specific tool is appropriate or what distinguishes it from others in the logging context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated statistics for logs on a specific date.
Args: date: Date in YYYYMMDD format. environment: Environment (production or staging).
Returns: Dict with statistics including request counts by worker, status distribution, error rate.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| environment | No | production |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns aggregated statistics in a dict format, including specific metrics like request counts and error rate, which adds useful context. However, it doesn't cover behavioral traits such as rate limits, authentication needs, or potential side effects, leaving gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The 'Args' and 'Returns' sections add structure without redundancy. However, the inclusion of 'Returns' details might be slightly redundant given the output schema, but it's still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is fairly complete. It explains the purpose, parameters, and return values. Since an output schema exists, it doesn't need to detail return values extensively, but it still provides a summary. There are minor gaps in usage guidelines and full behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying the date format (YYYYMMDD) and environment options (production or staging), which are not in the schema. However, it doesn't fully document all parameters (e.g., default values or constraints), but it provides enough context to justify a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get aggregated statistics for logs on a specific date.' It specifies the verb ('Get aggregated statistics'), resource ('logs'), and scope ('on a specific date'). However, it doesn't explicitly differentiate from sibling tools like 'get_errors' or 'search_logs', which might also retrieve log-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention sibling tools like 'get_errors' for error-specific data or 'search_logs' for detailed queries, nor does it specify prerequisites or exclusions. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available date folders in the logpush R2 bucket.
Args: environment: Filter by environment (production, staging). None for all. limit: Maximum number of dates to return (default 30).
Returns: Dict with dates array containing date, environment, and prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool lists date folders and returns a dict with specific fields, but lacks details on permissions, rate limits, error handling, or whether it's read-only or destructive. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured, with a clear purpose statement followed by labeled sections for Args and Returns. Each sentence adds value without redundancy, making it easy to parse. However, the 'Returns' section could be slightly more concise by integrating with the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the tool's purpose, parameters, and return format. Since an output schema exists, it doesn't need to detail return values extensively. The main gap is the lack of behavioral context, but overall, it provides a solid foundation for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'environment' filters by values like 'production' or 'staging', and 'limit' controls the maximum number of dates returned with a default of 30. This clarifies the purpose and usage of both parameters, compensating well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List available date folders in the logpush R2 bucket.' It specifies the verb ('List') and resource ('date folders in the logpush R2 bucket'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_log_files' or 'get_log_stats', which might also involve listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 filtering by environment but doesn't explain why one would choose this over siblings like 'list_log_files' or 'search_logs'. There's no mention of prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List log files for a specific date.
Args: date: Date in YYYYMMDD format (e.g., "20260111"). environment: Environment (production or staging). limit: Maximum number of files to return (default 50). cursor: Pagination cursor from previous response.
Returns: Dict with files array, count, and next_cursor for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| environment | No | production | |
| limit | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a list operation with pagination support ('cursor' and 'next_cursor'), which implies read-only behavior, but does not address permissions, rate limits, or error handling. This is a minimal but adequate disclosure for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by organized sections for 'Args' and 'Returns'. Every sentence adds value without redundancy, making it easy for an agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, pagination) and no annotations, the description is largely complete: it explains the purpose, parameters, and return structure. With an output schema present, it need not detail return values further. Minor gaps include lack of error cases or sibling differentiation, but it covers core functionality adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It effectively explains all four parameters: 'date' format, 'environment' options, 'limit' default, and 'cursor' purpose for pagination. This adds significant meaning beyond the bare schema, though it could detail constraints like 'environment' enum values more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List log files for a specific date.' It specifies the verb ('List') and resource ('log files') with a scope constraint ('for a specific date'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'list_log_dates' or 'search_logs', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the tool's function but does not specify scenarios for its use, prerequisites, or exclusions compared to siblings such as 'list_log_dates' or 'search_logs', leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and parse a specific log file from R2.
Args: path: Full object path/key (e.g., "production/20260111/filename.log.gz"). limit: Maximum number of entries to return (default 100).
Returns: Dict with entries array and count.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic behavior ('Read and parse'). It doesn't disclose permissions needed, rate limits, error handling, or whether it handles compressed files (implied by '.gz' in example). This leaves significant gaps for a tool interacting with storage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement followed by clear Arg/Returns sections. Every sentence adds value, and it's front-loaded with the core functionality, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no annotations, and an output schema (which handles return values), the description covers purpose and parameters adequately. It could improve by adding more behavioral context (e.g., auth needs), but the output schema reduces the burden, making it mostly complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains 'path' as 'Full object path/key' with an example, and 'limit' as 'Maximum number of entries to return' with a default, adding clear meaning beyond the bare schema. However, it doesn't detail format constraints for 'path' or bounds for 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read and parse'), the resource ('a specific log file from R2'), and distinguishes it from siblings like 'list_log_files' (which lists files) and 'search_logs' (which searches content). It's specific about what it does versus other available tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it reads a 'specific log file', suggesting it's for individual file access rather than listing or searching. However, it doesn't explicitly state when to use this versus alternatives like 'get_latest' or 'search_logs', leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search logs with filters.
Args: date: Date in YYYYMMDD format. environment: Environment (production or staging). script_name: Filter by worker script name. status_code: Filter by exact HTTP status code. status_gte: Filter by status code >= value (e.g., 400 for errors). status_lt: Filter by status code < value. outcome: Filter by outcome ("ok" or "exception"). search_text: Search in URL and log messages. limit: Maximum entries to return (default 50).
Returns: Dict with matching entries and count.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| environment | No | production | |
| script_name | No | ||
| status_code | No | ||
| status_gte | No | ||
| status_lt | No | ||
| outcome | No | ||
| search_text | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format ('Dict with matching entries and count') and default behavior ('limit: Maximum entries to return (default 50)'). However, it doesn't mention important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or what happens when no matches are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses bullet-point style formatting. Every sentence adds value by explaining parameters or return values. While efficient, the opening line 'Search logs with filters.' is somewhat generic and could be more specific about the tool's unique value among siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 9 parameters and no annotations, the description does well by documenting all parameters thoroughly and specifying the return format. Since there's an output schema (though not shown), the description doesn't need to detail return structure. The main gap is lack of behavioral context (rate limits, auth, etc.) and sibling differentiation, but parameter documentation is excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 9 parameters. Each parameter gets specific context: format requirements ('Date in YYYYMMDD format'), allowed values ('production or staging'), filtering logic ('Filter by exact HTTP status code'), comparison operators ('Filter by status code >= value'), search scope ('Search in URL and log messages'), and default values ('default 50'). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search logs with filters' which is a specific verb+resource combination. It distinguishes itself from siblings like 'get_errors', 'get_latest', or 'list_log_dates' by emphasizing search functionality with multiple filter parameters. However, it doesn't explicitly contrast with all siblings (e.g., 'read_log_file' might also involve log access).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_errors' (which might retrieve error logs specifically) or 'list_log_dates' (which might list available dates). There's no mention of prerequisites, performance considerations, or typical use cases that would help an agent choose between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_errorsget_latestget_log_statslist_log_dateslist_log_filesread_log_filesearch_logsEach tool has a clearly distinct purpose with no ambiguity: get_errors retrieves error logs, get_latest fetches recent entries, get_log_stats provides aggregated data, list_log_dates lists available dates, list_log_files enumerates files for a date, read_log_file reads a specific file, and search_logs performs filtered searches. The descriptions reinforce these distinct roles, making tool selection straightforward.
All tool names follow a consistent verb_noun pattern using snake_case, such as get_errors, list_log_dates, and search_logs. This uniformity enhances readability and predictability across the toolset, with no deviations in naming conventions.
With 7 tools, this server is well-scoped for log management, covering essential operations like retrieval, listing, statistics, and search. Each tool serves a specific function without redundancy, making the count appropriate for the domain's needs.
The toolset provides comprehensive coverage for log management, including listing dates and files, reading specific files, retrieving errors and latest entries, gathering statistics, and performing searches with filters. There are no obvious gaps, enabling agents to handle typical log analysis workflows effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only access to Auralogs production logs: search logs, inspect errors, review AI analyses.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DigiBugCat/logpush-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
