OneUptime

List Monitor Logs

list_monitor_logs

Read-only

Query Monitor Logs telemetry. Telemetry tables are large: always filter on time and keep limit small (10-50).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_monitor_logs"
  }
}

Input Schema

Name	Required	Description
`skip`	No
`sort`	No	For example {"time":"DESC"}.
`limit`	No	Default: 10, maximum: 100.
`query`	No	A field's value, or an operator such as {"_type":"GreaterThan","value":...}. Fields and operators: oneuptime_describe_resource.
`select`	No	Field names to return. Select only what you need: telemetry rows can be large.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 6, 2026

changedInput schema / properties / limit / description

Previous value: -"Records to return. Default: 10, maximum: 100."New value: +"Default: 10, maximum: 100."

changedInput schema / properties / query / description

Previous value: -"Filter. Each field takes a value (exact match) or an operator, such as {\"_type\":\"GreaterThan\",\"value\":...}. Fields and operators: oneuptime_describe_resource."New value: +"A field's value, or an operator such as {\"_type\":\"GreaterThan\",\"value\":...}. Fields and operators: oneuptime_describe_resource."

removedInput schema / properties / skip / description
```
Removed value: -"Records to skip. Default: 0."
```

changedInput schema / properties / sort / description

Previous value: -"Fields to sort by. Example: {\"time\":\"DESC\"}."New value: +"For example {\"time\":\"DESC\"}."

Changed13 schema fields changedNov 4, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of records to return. Default: 10, Maximum: 100. Keep small for telemetry queries."New value: +"Records to return. Default: 10, maximum: 100."

changedInput schema / properties / query / additionalProperties
```
Previous value: -falseNew value: +true
```

changedInput schema / properties / query / description

Previous value: -"Filter criteria for Monitor Logs. Always include a time-range filter. Each field accepts a direct value (exact match) or an operator object {\"_type\": \"<Operator>\", \"value\": ...}. Operators: EqualTo, NotEqual, IsNull, NotNull, EqualToOrNull, GreaterThan, LessThan, GreaterThanOrEqual, LessThanOrEqual, InBetween (numbers/dates), Search (partial text), Includes (array of values). Example — items from the last 24 hours: {\"createdAt\": {\"_type\": \"GreaterThan\", \"value\": \"2026-01-01T00:00:00.000Z\"}}."New value: +"Filter. Each field takes a value (exact match) or an operator, such as {\"_type\":\"GreaterThan\",\"value\":...}. Fields and operators: oneuptime_describe_resource."

removedInput schema / properties / query / properties

Removed value: -{
-  "_id": {
-    "description": "_id field",
-    "type": "string"
-  },
-  "createdAt": {
-    "description": "createdAt field",
-    "type": "string"
-  },
-  "logBody": {
-    "description": "logBody field",
-    "type": "string"
-  },
-  "monitorId": {
-    "description": "monitorId field",
-    "type": "string"
-  },
-  "projectId": {
-    "description": "projectId field",
-    "type": "string"
-  },
-  "retentionDate": {
-    "description": "retentionDate field",
-    "type": "string"
-  },
-  "time": {
-    "description": "time field",
-    "type": "string"
-  }
-}

removedInput schema / properties / select / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / select / description

Previous value: -"Fields to return, as an object of field names to true (e.g. {\"time\": true, \"body\": true}). Select only the fields you need — telemetry rows can be large."New value: +"Field names to return. Select only what you need: telemetry rows can be large."

addedInput schema / properties / select / items
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / select / properties

Removed value: -{
-  "_id": {
-    "description": "Select _id field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "createdAt": {
-    "description": "Select createdAt field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "logBody": {
-    "description": "Select logBody field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "monitorId": {
-    "description": "Select monitorId field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "projectId": {
-    "description": "Select projectId field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "retentionDate": {
-    "description": "Select retentionDate field in the response",
-    "example": true,
-    "type": "boolean"
-  },
-  "time": {
-    "description": "Select time field in the response",
-    "example": true,
-    "type": "boolean"
-  }
-}

changedInput schema / properties / select / type

Previous value: -"object"New value: +"array"

changedInput schema / properties / skip / description

Previous value: -"Number of records to skip. Default: 0."New value: +"Records to skip. Default: 0."

changedInput schema / properties / sort / additionalProperties

Previous value: -falseNew value: +{
+  "enum": [
+    "ASC",
+    "DESC"
+  ],
+  "type": "string"
+}

changedInput schema / properties / sort / description

Previous value: -"Sort order. Use \"ASC\" or \"DESC\". Example: {\"time\": \"DESC\"} for most recent first."New value: +"Fields to sort by. Example: {\"time\":\"DESC\"}."

removedInput schema / properties / sort / properties

Removed value: -{
-  "_id": {
-    "description": "_id field",
-    "type": "string"
-  },
-  "createdAt": {
-    "description": "createdAt field",
-    "type": "string"
-  },
-  "monitorId": {
-    "description": "monitorId field",
-    "type": "string"
-  },
-  "projectId": {
-    "description": "projectId field",
-    "type": "string"
-  },
-  "retentionDate": {
-    "description": "retentionDate field",
-    "type": "string"
-  }
-}

First observedOct 19, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed world), so the description's job is to add operational context — and it does, warning that telemetry tables are large and that unfiltered or high-limit queries are expensive. It stops short of saying what happens on an unfiltered query (error, timeout, or full scan) or how results are ordered by default.

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?

Two short sentences, front-loaded with purpose and immediately followed by the operational constraint that matters most. No filler and nothing repeated from the schema verbatim.

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?

For a read-only list tool with no output schema, the description covers the performance hazard but leaves gaps: it never names which field carries the time filter (the query param points to 'oneuptime_describe_resource' for field names), says nothing about pagination via skip, and does not indicate the shape of returned log rows.

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 80% and the schema already documents sort, limit, query, and select, so the baseline is 3. The description adds real meaning on top: it tells the agent to constrain the time dimension and to prefer limits of 10-50, refining the schema's stated default of 10 and maximum of 100 into practical advice.

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?

States a specific verb and resource ('Query Monitor Logs telemetry'), which separates it from generic 'list_logs' and from the 'count_monitor_logs' sibling by implication. It does not explicitly say how it differs from those siblings, so an agent still has to infer that this returns rows rather than counts.

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?

Gives practical guidance on how to call it (always filter on time, keep limit small), but no guidance on when to choose it over 'list_logs', 'count_monitor_logs', or 'oneuptime_describe_resource'. Usage context is implied by the telemetry framing rather than stated.

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

All OneUptime tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.