Mixer4AI

register_agent_card

Registers a new agent card - and, if x-mixer4ai.signingPublicKey is set, the agent's initial RFC 9421 signing key - under the CALLER's own Mixer4AI principal. Requires a sponsor's Entra bearer token (Authorization: Bearer ). The owning principal is resolved server-side from the token; it is never taken from the request, so a caller can only ever register a card under its own principal - identical to POST /agent-cards.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`request`	Yes	The agent card to register: an A2A-compatible manifest carrying the x-mixer4ai vendor extension. Set x-mixer4ai.signingPublicKey (base64 SubjectPublicKeyInfo of a NIST P-256 public key) to register the agent's initial signing key at the same time.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026
- addedInput schema / properties / request / properties / x-mixer4ai / properties / reputationScoreBreakdown / properties / incorporationContinuityLine
```
Added value: +{
+  "default": null,
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed1 schema field changedAug 7, 2026

addedInput schema / properties / request / properties / x-mixer4ai / properties / reputationScoreBreakdown

Added value: +{
+  "default": null,
+  "properties": {
+    "asOf": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "baseline": {
+      "type": "number"
+    },
+    "components": {
+      "items": {
+        "properties": {
+          "contribution": {
+            "type": "number"
+          },
+          "eventCount": {
+            "type": "integer"
+          },
+          "eventType": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "eventType",
+          "eventCount",
+          "contribution"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "formulaVersion": {
+      "type": "integer"
+    },
+    "score": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "score",
+    "baseline",
+    "formulaVersion",
+    "asOf",
+    "components"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

First observedJul 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations only provide readOnly/idempotent/destructive flags, but the description adds substantial behavioral context: required Authorization header, server-side owner resolution, conditional registration of an RFC 9421 signing key, and a strong security guarantee that a caller can only register under its own principal. This goes well beyond what the annotations communicate.

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

Conciseness5/5

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

The description is dense but efficient: it front-loads the core registration action, then the auth requirement, then the security/ownership behavior. Every sentence contributes distinct information and there is no redundant filler.

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?

For a complex nested registration tool, the description adequately covers auth, ownership, the conditional signing key behavior, and endpoint equivalence, while the schema covers the request fields. However, there is no output schema and no mention of response shape or duplicate/update behavior, so it is not fully complete.

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% and the request schema already documents the manifest structure and signingPublicKey encoding. The tool description adds meaningful conditional semantics around x-mixer4ai.signingPublicKey and clarifies that ownership is never taken from request parameters, which is slightly above the high-coverage baseline.

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 states a specific verb and resource: 'Registers a new agent card' and explicitly scopes it to the CALLER's own Mixer4AI principal. It also clearly calls out the optional signing-key behavior and anchors the operation to POST /agent-cards, making the tool's purpose unambiguous.

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?

It provides clear usage context by requiring a sponsor's Entra bearer token and explaining that the owning principal is resolved server-side from the token, so the caller cannot register on behalf of another principal. However, it does not explicitly contrast with sibling flows like self_register_agent_card, so it lacks explicit when-not-to-use guidance.

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

All Mixer4AI tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?