Skip to main content
Glama
Sign In

InfraNest

by io.infranest
OverviewDiscussionsAdmin

Search the audit log

search_audit_log
Read-onlyIdempotent

Who changed what in the organization, newest first. Filter with the dates from and to, action (matches part of the name), resource_type and token_id for changes made through one API token; page with per_page (default 25, at most 100) and page. Changes by people and API tokens; for deploys use list_deploys, for DNS edits made at the provider dns_outside_changes.

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": "search_audit_log"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoUp to this date (YYYY-MM-DD).
fromNoFrom this date (YYYY-MM-DD).
pageNoPage number, from 1.
actionNoPart of the action name, e.g. dns_record or monitor.paused.
categoryNoOnly this area.
per_pageNoRows per page, up to 100 (default 25).
resource_typeNoOnly changes to this kind of thing, e.g. MonitoringCheck, DnsZone, DnsRecord, CloudServer, Domain.
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the description adds useful context by stating newest-first ordering and pagination defaults and limits. It does not describe the shape of returned audit entries or permission requirements, but that gap is less severe given the safety 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 core purpose, then covers filtering, pagination, and sibling alternatives without wasted prose. It is appropriately sized for an eight-parameter search tool.

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?

It covers purpose, ordering, pagination, and alternatives for a read-only search tool with no output schema, which is useful. However, it does not explain what an audit-log entry contains, and the reference to a nonexistent `token_id` parameter leaves an important completeness and accuracy gap.

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 coverage is 100%, so all eight parameters are already documented in the input schema. The description restates some filters, but it introduces `token_id`, which does not exist in the schema, and it omits `category` and `organization_id`; the nonexistent parameter is materially misleading.

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?

The description gives a specific verb and resource: searching the audit log for 'who changed what in the organization, newest first.' It also distinguishes the tool from siblings by naming list_deploys and dns_outside_changes for adjacent use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly directs agents to alternatives: use list_deploys for deploys and dns_outside_changes for DNS edits made at the provider. It also clarifies the audit-log scope as changes by people and API tokens, with concrete filters.

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

All InfraNest toolsInspect
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.

Resources