Skip to main content
Glama
Sign In

AgentX

by com.agentxhq
OverviewDiscussionsAdmin

check_agent_output

Read-onlyIdempotent

Read what an agent has been saying and doing — its recent transcript. Use this to catch up on an agent that is still working, or to re-read something it said earlier. Name the agent as list_agents shows it, and pass chat (from create_chat or list_chats) when reading by agent name. session_id targets one exact session and does not take chat.

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

Input Schema

NameRequiredDescriptionDefault
toNoSame as agent. agent wins when both are set.
chatNoChat id for reading by agent name (the `bubble_id` from `create_chat` or `list_chats`). Required when reading by agent name; not used with session_id.
tailNoSame as lines. lines wins when both are set.
agentNoName of the agent to read, as shown by `list_agents`.
linesNoHow far back to read, counted in messages. Leave empty for the most recent; raise it to catch up on a long piece of work.
formatNoLeave empty to read the agent's conversation. Set to `screen` only when you need its raw terminal instead.
verboseNoInclude extra diagnostic detail. Leave off unless you are debugging.
session_idNoRead one exact session instead of naming an agent. Only use this when you already have a session id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real context beyond that: format=screen yields the raw terminal instead of the conversation, and verbose is for debugging only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what the tool returns, then usage, then addressing rules. Every sentence carries instruction; only the aliasing details border on schema repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must describe the return value, and it does — a recent transcript, or the raw screen when requested. With 8 optional parameters, the addressing-mode explanation is the key missing-piece and it is present; only exact return shape is left implicit.

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, but the description adds cross-parameter constraints (chat is required when reading by agent name; session_id does not take chat) that go beyond the per-field text. It also clarifies that agent wins over the alias 'to' and lines over 'tail'.

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 ('Read what an agent has been saying and doing — its recent transcript') and distinguishes itself implicitly from get_agent/list_agents by being a transcript read rather than a lookup. An agent can tell what it returns 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 Guidelines4/5

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

Gives two concrete situations ('catch up on an agent that is still working', 're-read something it said earlier') and spells out the two addressing modes. It doesn't explicitly say when to prefer this over get_agent, so it stops short of full alternative routing.

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

All AgentX 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