Register an external agent with a Guest DID on HiveGate. Returns guest_did, access_token, and trust mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | Human-readable name for the agent | |
| external_id | Yes | Unique identifier from the source platform | |
| callback_url | No | Callback URL for async notifications | |
| capabilities | No | List of agent capabilities | |
| source_platform | Yes | ||
| native_reputation | No | Native platform reputation data |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, and non-destructive behavior, and the description adds what the tool returns (guest_did, access_token, trust mapping). It does not disclose side effects, prerequisites, or trust mapping semantics, so it adds only moderate behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the action, target, and return values without extraneous text. It is well structured and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters including nested objects and no output schema, and the description covers only the top-level purpose and return fields. It lacks details about the registration flow, trust mapping semantics, or parameter interactions, leaving gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema description coverage, the input schema already documents most parameters adequately. The tool description does not further clarify parameter meanings, relationships, or constraints, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific action 'Register' and the resource 'an external agent with a Guest DID on HiveGate,' clearly distinguishing it from sibling tools like execute or bridge_trust. It also lists expected return values, adding specificity to the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for onboarding external agents that need a Guest DID, which is a distinct use case from the siblings. However, it does not explicitly state when to avoid this tool or mention alternatives, so it lacks the explicit exclusion criterion for a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: trust mapping, transaction execution, guest registration, and intent translation. No overlap or ambiguity exists between them.
All tools share the 'hivegate_' prefix and mostly follow a verb_noun pattern. However, 'hivegate_execute' lacks an explicit object, which is a minor deviation from the other three.
Four tools is well-scoped for a bridge gateway, covering the essential operations without unnecessary bloat or redundancy.
The tool surface covers registration, trust evaluation, intent translation, and execution, forming a coherent workflow. Missing operations like transaction status or trust revocation are minor gaps that can be worked around.