Skip to main content
Glama
Aidress-ai

Aidress

Official
by Aidress-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

protocol_reference

Look up step-by-step examples for edge-case Aidress protocol flows, such as MCP handshakes and registration confirmations, only when you hit them.

Instructions

Look up the worked example for an edge-case protocol flow, on demand.

Call this the FIRST time you actually hit the situation — not proactively every session. Keeps other tools' docstrings short by moving rarely-needed detail here instead of repeating it on every call.

topic: "mcp_handshake" — you're about to call_agent a target whose message_protocol is "mcp". Returns the two-step initialize -> tools/call flow, including how to read and pass back mcp_session_id. "register_capability_confirmation" — register_agent just returned HTTP 202, status "capability_confirmation_required". Returns the two-step confirm/reject flow to complete registration. "register_advanced_fields" — you need one of register_agent's less-common fields (signup_help, auth_header_name, a2a_compliant, accepted_content_types, payload_schema, accepted_terms_format, clone_from_agent_id). "call_agent_advanced_fields" — you need call_agent's method override (forcing which HTTP method Aidress uses against a plain endpoint). "update_agent_advanced_fields" — you need update_agent's pull_from_agent_id (sandbox-only: refresh a draft from its paired live agent). "ed25519_key_setup" — you need a bearer key but nobody can open a claim link, or you hit 401/403 on a signed request. Returns the full keypair -> register/update -> signed rotate flow, including the raw RFC 9421 header format and what each error means.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / topic / enum
      Previous value: -[
-  "mcp_handshake",
-  "register_capability_confirmation",
-  "register_advanced_fields",
-  "call_agent_advanced_fields",
-  "update_agent_advanced_fields"
-]New value: +[
+  "mcp_handshake",
+  "register_capability_confirmation",
+  "register_advanced_fields",
+  "call_agent_advanced_fields",
+  "update_agent_advanced_fields",
+  "ed25519_key_setup"
+]
  2. Addedv0.4.1

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: for every topic it discloses what the response contains (two-step initialize -> tools/call flow, RFC 9421 header format, error meanings). It never explicitly states the call is side-effect-free or whether results are cached, which keeps it just short of full behavioral coverage.

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 long, but front-loaded with purpose and usage cadence before the per-topic catalogue, and every bullet pairs a trigger with a return summary, so little is wasted. The dense enumerated layout is justified by the six mutually exclusive topics.

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, no annotations, one enum parameter — the description supplies everything needed: when to call, which topic selects which scenario, and what each topic returns. Nothing required to invoke it correctly is missing.

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 description coverage is 0% and the enum values carry no inline descriptions, so the description must compensate — and it does fully, mapping each of the six topics to both its triggering situation and the content returned. No enum value is left unexplained.

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 ('Look up the worked example for an edge-case protocol flow, on demand') and clarifies its architectural role — it exists so other tools' docstrings can stay short. This makes it immediately distinguishable from action siblings like register_agent and call_agent.

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?

Explicit when-to-use and when-not: 'Call this the FIRST time you actually hit the situation — not proactively every session.' Each topic additionally names the precise trigger condition (e.g. 'register_agent just returned HTTP 202', 'you hit 401/403 on a signed request'), routing the agent unambiguously.

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