Skip to main content
Glama
ShellFrameAI

AgentSecure Community

Official
by ShellFrameAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

agentsecure.audit_context

Inspect recent local Mesh audit events to troubleshoot messages, registrations, approvals, or policy denials, with optional resource filtering and result limits.

Instructions

Inspect recent local Mesh history for troubleshooting messages, registrations, approvals, or policy denials. Returns an events array containing only mesh.* records from the configured audit log, optionally filtered by resource, with the last limit matches in log order (oldest first within that slice). A missing log returns an empty array and malformed JSON lines are skipped. Does not change state or include non-Mesh HTTP/secret audit events. Text fields may be redacted with summary/hash metadata; this is not an immutable audit service. Example: {"limit": 10}.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of most recent matching events to return; defaults to 50. Use a positive integer (values are converted with int); 0 returns all matches, not zero events.
resourceNoOptional filter, e.g. {"path": "src/app.py"}; defaults to {} (all Mesh events). Each key and stringified value must occur in serialized event details. This is substring matching, not exact structured matching.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"Number of most recent matching events to return; defaults to 50. Use a positive integer (values are converted with int); 0 returns all matches, not zero events."
    • addedInput schema / properties / resource / description
      Added value: +"Optional filter, e.g. {\"path\": \"src/app.py\"}; defaults to {} (all Mesh events). Each key and stringified value must occur in serialized event details. This is substring matching, not exact structured matching."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the return shape (events array), ordering semantics ('last limit matches in log order, oldest first within that slice'), edge-case behavior (missing log returns empty array, malformed JSON lines skipped), read-only nature, and two important caveats (redaction with summary/hash metadata, not an immutable audit service). That is unusually complete behavioral disclosure.

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?

Front-loads purpose, then return semantics, then edge cases, then caveats, then a minimal example. Every sentence adds information an agent would otherwise have to guess; nothing is repeated from the schema verbatim.

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?

Two optional parameters, no output schema, no annotations — and the description still covers purpose, filtering, ordering, paging behavior, error tolerance, and data-fidelity caveats. An agent can call this correctly and interpret the result without further information.

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 earns above that by clarifying that limit selects the last N matches and that ordering is oldest-first within the returned slice, which the schema does not state. It also confirms resource is an optional substring filter over serialized details, reinforcing the schema's caveat that it is not exact structured matching.

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 ('Inspect') and resource ('recent local Mesh history') and enumerates the record types covered (messages, registrations, approvals, policy denials). It also explicitly scopes out what it does NOT return ('non-Mesh HTTP/secret audit events'), which separates it from siblings like check_messages, secret.status, and http.request.

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?

Frames the use case clearly as 'troubleshooting' and lists the event categories it covers, plus an explicit exclusion of non-Mesh HTTP/secret events. It stops short of naming an alternative tool to use for those other cases, so the agent must infer the routing from sibling names.

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

This server cannot be deployed

Other Tools