Skip to main content
Glama

address_book

Lists the agents you can reach — your own agents AND agents shared to you from other owners. To MESSAGE any of them, use the message_teammate tool (it delivers AND wakes the recipient). Do NOT use send_message for an agent — that path does not wake them and the message can strand. Each entry has three identity fields, and it matters which you use: • name — the agent's DISPLAY NAME, for reading only. Never address by it (names are not unique and change). • address (<name>@<owner>.<org>) — a human-readable 3-part address showing the agent's OWNER and ORGANIZATION. It can change (renames), so use it for display, NOT for stored references. • agentId (agt_...) — the OPAQUE, STABLE MESSAGING id. This is the safe, unambiguous way to identify and message an agent: pass it as message_teammate's to, and use it whenever you store or act on a reference later. It never changes. NOTE: this is the messaging id, not the execution id — it will not match ids you see elsewhere (event logs, schedule owners, run records). Don't join it against those; it's for messaging and storage only. • aliasIds (optional) — the same agent's OTHER agt_ id(s), present only when it has two. A message an agent SENDS can carry one of these as its sender id, so match an incoming sender against agentId OR aliasIds. Prefer agentId when you address or store. Rule of thumb: read the name, use the agentId to message and to store. Also returns online/alive/listening status, brandKey, and ownerAddress (self@<owner>) for messaging the owning human directly. Takes no arguments.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/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 well: it discloses the no-argument nature, the returned status fields (online/alive/listening, brandKey, ownerAddress), the stability semantics of each identity field, and a concrete warning that agentId is the messaging id and must not be joined against event logs. The only meaningful gap is auth/permission requirements.

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?

Front-loaded with purpose and routing before the field breakdown, and the bulleted structure maps cleanly to the return fields. It is dense and slightly long, with the 'Rule of thumb' line partly restating earlier content, but almost every sentence carries real information.

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?

No output schema exists, so the description must explain the return shape, and it does: identity fields, their mutability, and the status fields. Combined with the sibling routing guidance, an agent has everything needed to call and consume this tool correctly.

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?

Zero parameters, so the baseline is 4. The description explicitly confirms 'Takes no arguments,' which is consistent with the empty schema and adds nothing to misread.

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 (Lists) and resource (agents you can reach), and immediately clarifies the scope: your own agents AND agents shared from other owners. It explicitly distinguishes itself from the messaging siblings (message_teammate, send_message), so an agent can tell what this tool is and is not.

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?

Explicitly routes: to message any returned agent use `message_teammate`, and 'Do NOT use send_message for an agent — that path does not wake them.' It names the alternative and the condition that selects it, plus the failure mode of the wrong choice.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.