Execute a cross-ecosystem transaction through HiveGate. Proxies requests to Hive services with bridge fee.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | POST | |
| payload | No | Request payload | |
| endpoint | Yes | Target endpoint path | |
| guest_did | Yes | Guest DID (did:hive:guest:*) | |
| access_token | Yes | Guest access token (hgate_*) | |
| max_fee_usdc | No | Maximum fee willing to pay in USDC | |
| target_service | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / target_service / enumPrevious value: -[
- "hivetrust",
- "hivemind",
- "hiveforge",
- "hivelaw",
- "simpson"
-]New value: +[
+ "hivetrust",
+ "hivemind",
+ "hiveforge",
+ "hivelaw"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply readOnly=false, idempotent=false, and destructive=false, but the description adds valuable behavioral context: requests are proxied to Hive services and a bridge fee is charged. This goes beyond the annotation flags, though it stops short of explaining error handling or response details.
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 two concise sentences, immediately stating the core action and resource. Every word contributes meaning, with no redundancy or padding.
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?
For a tool with 7 parameters, nested payloads, and no output schema, the description is somewhat thin. It omits the usage flow (e.g., need to register a guest first) and does not clarify response behavior or failure modes. It covers the essential function but lacks surrounding context.
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?
Schema coverage is 71%, with descriptions for most parameters and enums for method and target_service. The description adds minimal semantic value beyond the schema, only hinting at the bridge fee that relates to max_fee_usdc. It neither compensates for undocumented parameters nor adds significant clarity.
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 uses specific action verbs ('execute', 'proxies requests') and clearly identifies the resource (cross-ecosystem transactions via HiveGate). It differentiates itself from siblings like register_guest and translate_intent, which serve distinct purposes.
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 provides no guidance on when to use this tool versus its sibling tools. It fails to mention prerequisites (e.g., registration), alternative tools, or scenarios where this tool is the appropriate choice.
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.