Skip to main content
Glama
Sign In

Agentalog — Agent Auto Log

by com.agentalog
OverviewDiscussionsAdmin

A2a agent

a2a_agent
Read-onlyIdempotent

Read one A2A agent: every skill its card declares, capabilities, protocol version, health, documentation and the registries that list it, with their licenses. Take the key from a2a_agent_search. The same row as the list plus what the card declares: every skill, the capabilities object, the protocol version as written, the documentation and icon URLs, and when we first saw it. Cached for 60 seconds; a MAT catalog read, like the list.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chave": "<chave>"
    },
    "name": "a2a_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
chaveYesAgent key (`key`) from a2a_agent_search, usually the card's domain.
api_passNoMAT-only private pass: mat_<32 random hex>_<64 random hex>. Generate and save before buying.
retry_keyNoOptional retry key, up to 80 ASCII characters; same read for five minutes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / api_pass
      Added value: +{
+  "description": "MAT-only private pass: mat_<32 random hex>_<64 random hex>. Generate and save before buying.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / chave / description
      Previous value: -"Agent key (`chave`) from a2a_agent_search, usually the card's domain."New value: +"Agent key (`key`) from a2a_agent_search, usually the card's domain."
  3. Changed1 schema field changed
    • removedInput schema / properties / api_pass
      Removed value: -{
-  "description": "MAT-only private pass: mat_<32 random hex>_<64 random hex>. Generate and save before buying.",
-  "type": "string"
-}
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered; the description still adds useful context beyond them: a 60-second cache window and the fact that this is a MAT catalog read like the list. It does not discuss failure modes such as an unknown key, so it stops short of full transparency.

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

Conciseness3/5

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

The content is front-loaded and the caching note is last, which is good, but the second sentence largely restates the first ('every skill its card declares' then 'every skill, the capabilities object...'). Roughly half the description is redundant repetition rather than new information.

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?

With no output schema, the description carries the burden of describing returns and does so at the field level (skills, capabilities, protocol version, docs/icon URLs, first-seen timestamp, registries and licenses), plus caching. It omits what happens on a missing or invalid key, which is the main remaining gap for a single-record read.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents chave, api_pass, and retry_key in detail (including the 5-minute retry window and pass format). The description only reinforces that the key comes from a2a_agent_search and says nothing about the other two parameters, so the baseline 3 applies.

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 one A2A agent') and enumerates exactly what comes back: skills from the card, capabilities, protocol version, health, documentation, and listing registries with licenses. This clearly separates it from the sibling a2a_agent_search (the list/search tool) without the agent needing to open either 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?

Explicitly tells the agent where the required identifier comes from ('Take the key from a2a_agent_search'), which establishes the search-then-fetch workflow. It lacks any when-not-to-use guidance or note on when to prefer the list tool instead, so it falls short of a 5.

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

All Agentalog — Agent Auto Log toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources