Skip to main content
Glama
l33tdawg

(S)AGE

by l33tdawg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

sage_directory

List recipients the signed caller is authorized to address, including display names, registered names, providers, and local or federated provenance. Use local scope to view only local agents.

Instructions

List recipients this signed caller is currently authorized to address. By default, include local agents and agents on connected trusted nodes. Upgraded nodes support discovery and messaging without sharing memory domains. Use scope=local for a local-only view. Each row includes display name, immutable registered name, provider, exact agent_id/to, and local/federated provenance. This is authorization metadata, never online presence, reachability, delivery, or read evidence. Older peers without safe enumeration support are omitted and reported as an incomplete federated view.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoInclude connected-node agents by default. Use local to skip federation network checks.all
peer_chainNoOptional exact node to browse.
peer_cursorNoBounded federated continuation returned by a previous scope=all call. Ignored for local scope.
agent_cursorNoAgent continuation from agent_pages; pass with its peer_chain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv11.19.18
    • addedInput schema / properties / agent_cursor
      Added value: +{
+  "description": "Agent continuation from agent_pages; pass with its peer_chain.",
+  "type": "string"
+}
    • addedInput schema / properties / peer_chain
      Added value: +{
+  "description": "Optional exact node to browse.",
+  "type": "string"
+}
    • changedInput schema / properties / scope / default
      Previous value: -"local"New value: +"all"
    • changedInput schema / properties / scope / description
      Previous value: -"The default local scope performs no federation network checks; all explicitly requests the caller-authorized local/federated union."New value: +"Include connected-node agents by default. Use local to skip federation network checks."
  2. Changed2 schema fields changedv11.17.4
    • addedInput schema / properties / peer_cursor
      Added value: +{
+  "description": "Bounded federated continuation returned by a previous scope=all call. Ignored for local scope.",
+  "type": "string"
+}
    • addedInput schema / properties / scope
      Added value: +{
+  "default": "local",
+  "description": "The default local scope performs no federation network checks; all explicitly requests the caller-authorized local/federated union.",
+  "enum": [
+    "all",
+    "local"
+  ],
+  "type": "string"
+}
  3. Addedv11.16.4

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it explicitly states 'This is authorization metadata, never online presence, reachability, delivery, or read evidence' and notes that older peers are omitted, yielding an incomplete federated view. It does not mention side effects or error cases, but for a read-only directory list the disclosed limitations are substantial.

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?

The description is five sentences, each carrying distinct information: core action, federated default, upgraded-node context, scope usage, row contents, and caveats. It is front-loaded with the primary purpose and avoids filler, though it is denser than the simplest possible description.

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?

There is no output schema, so the description reasonably covers return contents (display name, registered name, provider, agent_id/to, provenance) and important limitations. Pagination details are left to cursor names and schema descriptions, and the federated incompleteness caveat is disclosed. This is complete enough for an agent to invoke correctly.

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 baseline is 3. The description adds useful context for scope (default all, use local for local-only) and hints at federated continuation, but does not meaningfully enrich peer_chain, peer_cursor, or agent_cursor beyond the schema. This is adequate, not exceptional.

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?

The description opens with a specific verb and resource: 'List recipients this signed caller is currently authorized to address.' It further clarifies the tool's scope as authorization metadata, not presence or reachability, which distinguishes it from messaging or status tools among the siblings. This gives an unambiguous purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description gives clear parameter-level guidance: default federated scope, scope=local for local-only, and an incomplete-view caveat for older peers. However, it does not explicitly compare against sibling tools such as sage_find_agent or sage_list, so the when-to-use-this-vs-alternative decision is left implied rather than stated.

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

Deploy Server

Other Tools