Skip to main content
Glama
sohaibsohail98

mcp-context-inspector

record_session

Store an agent run's token usage, latency, and tool trace, and receive a new session ID to query it later.

Instructions

Append ONE agent execution's metrics to this server's store; returns the new session_id.

This is how a remote agent gets its own runs into the server, rather than only being able to query what the server owner recorded locally. Attributed to the connected identity: your Google account if you signed in via /auth/login, or owner=None for the owner token. NOT idempotent -- each call mints a new session_id. Never updates or deletes an existing session; the get_* tools read what this writes.

prompt: the user prompt that started the run. model_id: the provider model identifier, e.g. "anthropic.claude-3-5-sonnet-20241022-v2:0". loop_result: the run's token / latency / trace payload. Required keys: input_tokens (int), output_tokens (int), total_tokens (int), latency_ms (float), turns (list). Optional: trace (list), context_blocks (list -- omit if you don't have per-block context data; get_context_timeline needs it).

  • each turns item: input_tokens (int), output_tokens (int), latency_ms (float); optional cache_read_input_tokens / cache_write_input_tokens (int, default 0).

  • each trace item: tool (str), args (dict), status (str); optional latency_ms (float, default 0), timestamp (float epoch seconds, default record time).

  • each context_blocks item: category (str), label (str), char_count (int), token_estimate (int); optional turn_n (int or null -- null for a pre-conversation block), status (str), content (str).

Example loop_result:

{
  "input_tokens": 1200, "output_tokens": 340, "total_tokens": 1540,
  "latency_ms": 4210.0,
  "turns": [
    {"input_tokens": 1200, "output_tokens": 340, "latency_ms": 4210.0,
     "cache_read_input_tokens": 800, "cache_write_input_tokens": 0}
  ],
  "trace": [
    {"tool": "grep_logs", "args": {"pattern": "ERROR"}, "status": "ok",
     "latency_ms": 120.0, "timestamp": 1756400000.0}
  ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYes
model_idYes
loop_resultYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

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

  1. First observedv0.4.0

TDQS

A5/5.0
Behavior5/5

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

The description explicitly notes non-idempotency, that each call mints a new session_id, that existing sessions are never updated or deleted, and that records are attributed to the connected identity (Google account or owner=None). This complements the annotations, which are structural hints, with concrete side-effect details.

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 is long, but every section earns its place: purpose and identity semantics are front-loaded, parameter details are systematically organized, and the example makes the nested structure concrete. Its length is proportional to the complexity of the tool.

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?

Given a nested parameter object, an existing output schema, and complex optional branches, the description is complete: it covers auth attribution, return value, non-idempotency, required/optional fields, defaults, and a worked example.

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 0%, and the description fully compensates: it defines prompt, model_id, and loop_result, and enumerates required and optional nested keys for turns, trace, and context_blocks with a complete JSON example.

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?

Starts with a specific verb and resource: 'Append ONE agent execution's metrics to this server's store; returns the new session_id.' It clearly identifies this as the write counterpart to the get_* read tools, so an agent can differentiate it without opening the schema.

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?

The description states when it is appropriate: 'This is how a remote agent gets its own runs into the server, rather than only being able to query what the server owner recorded locally.' It also clarifies it never updates or deletes and that read access happens through the get_* siblings.

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

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/sohaibsohail98/mcp-context-inspector'

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