Skip to main content
Glama
hostinger

hostinger-api-mcp

Official
by hostinger

Get Node.js runtime logs

hosting_getNode_jsRuntimeLogsV1
Read-only

Retrieve Node.js application runtime console logs with timestamp, level, and message. Fetch by time window or poll new entries using the last total_lines value.

Instructions

Returns the Node.js application's runtime console log entries, oldest first, each with timestamp, level and message. On the first call send period (1h, 1d, 1w or 1m) and optionally levels and limit (1-5000, default 1000); when more entries match than limit, the newest are kept.

To poll for new entries send total_lines + 1 from the previous response as from_line and omit period; period and from_line cannot be combined. Lines that are not JSON with a timestamp, level and message are skipped, so logs may hold fewer than limit entries while total_lines counts every raw line. Entries with a timestamp before last_deployed_at belong to the previous deployment. Returns an empty logs list when the application has not written a log file yet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of log entries to return. When more entries match, the newest are kept.
domainYesDomain name
levelsNoReturn only entries with these log levels, sent as a comma-separated list, e.g. ERROR,WARN. Matching runs on the raw log line, so entries written with numeric levels (for example by pino) are excluded while this filter is set.
periodNoTime window for the first fetch. Required when `from_line` is not sent.
usernameYesusername parameter
from_lineNo1-based line of the log file to start from. For polling send `total_lines + 1` from the previous response. Cannot be combined with `period`.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv1.57.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses oldest-first ordering, skipping of non-JSON lines, the difference between logs and total_lines, previous-deployment exclusion via last_deployed_at, and empty logs when no log file exists. No contradiction with the annotations.

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 front-loads the result and then organizes usage into first-call versus polling, with each sentence carrying a distinct rule or edge case. Despite its length, there is no filler or repetition.

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 compensates by naming the response fields it references (logs, total_lines, last_deployed_at) and covering edge cases such as non-JSON lines, no log file yet, and previous deployments. An agent has enough information to make a correct first call, interpret the response, and poll for new entries.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds operation-level meaning: period applies to the first call, from_line is used for polling, period and from_line are mutually exclusive, and limit has a default of 1000 with newest entries kept on overflow. This materially improves correct parameter usage beyond the bare schema.

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?

States a specific verb and resource: 'Returns the Node.js application's runtime console log entries, oldest first, each with timestamp, level and message.' The 'runtime console' wording distinguishes it from sibling build/deployment log tools such as hosting_getNodeJSBuildLogsV1 and hosting_showJsDeploymentLogs.

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 first-call protocol ('send period ... optionally levels and limit') and polling protocol ('send total_lines + 1 ... as from_line and omit period'), including the exclusion rule that period and from_line cannot be combined. It does not name sibling alternatives, but the usage context is clear and actionable.

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/hostinger/api-mcp-server'

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