Teardrop

Delegate To Agent

delegate_to_agent

Delegate a task to a remote A2A-compliant agent. Discovers the agent's capabilities via its agent card, sends it a message, and returns the result. Use when a task requires specialist capabilities beyond your own tools.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_url`	Yes	Base URL of the remote A2A agent (e.g. https://agent.example.com)
`task_type`	No	Broad task class for routing telemetry; never include user data or task text.	general
`task_description`	Yes	Natural language description of the task to delegate

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Error message, if any
`result`	Yes	Text result extracted from the remote agent's response
`status`	Yes	A2A task state: completed, failed, etc.
`cost_usdc`	No	Cost of this delegation in atomic USDC
`agent_name`	Yes	Name of the remote agent (from its agent card)
`error_type`	No	Stable error type for delegation failures that require planner recovery.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 4, 2026

addedOutput schema / properties / error_type

Added value: +{
+  "anyOf": [
+    {
+      "const": "advertised_price_exceeds_cap",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Stable error type for delegation failures that require planner recovery.",
+  "title": "Error Type"
+}

Changed5 schema fields changedAug 14, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / agent_url / title
```
Added value: +"Agent Url"
```
- addedInput schema / properties / task_description / title
```
Added value: +"Task Description"
```
- addedInput schema / properties / task_type / title
```
Added value: +"Task Type"
```
- addedInput schema / title
```
Added value: +"mcp_delegate_to_agentArguments"
```

Changed1 schema field changedJul 20, 2026

addedInput schema / properties / task_type

Added value: +{
+  "default": "general",
+  "description": "Broad task class for routing telemetry; never include user data or task text.",
+  "enum": [
+    "general",
+    "research",
+    "analysis",
+    "data_retrieval",
+    "coding",
+    "transaction",
+    "automation"
+  ],
+  "type": "string"
+}

First observedJul 9, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false and idempotentHint=false, so mutation and non-idempotency are known. The description adds the specific behavioral flow: agent-card discovery, message sending, and result returning. However, it does not warn about potential side effects on the remote agent side or failure modes, which would add useful behavioral context for a non-read-only tool.

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?

Three short, purposeful sentences: what it does, how it does it, and when to use it. No filler or repeated schema content.

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?

The description, combined with a fully described schema and an output schema, is nearly complete for correct invocation. It justifies when to use the tool and explains the delegation flow. The main gap is not explicitly addressing remote side effects or cautioning that the target agent may perform actions with consequences, which matters given readOnlyHint=false.

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?

The schema description coverage is 100% and each parameter already has a clear description, including the task_type enum and its telemetry/routing purpose. The tool description adds nothing beyond the schema for parameters, so the baseline of 3 is appropriate.

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 uses a specific verb ('Delegate') and identifies the exact resource (a remote A2A-compliant agent), then explains the mechanism: discovers capabilities, sends a message, returns the result. This distinguishes it from sibling tools like discover_agents or web_search, which serve different purposes.

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?

The description gives a clear usage condition: use when a task requires specialist capabilities beyond your own tools. It does not explicitly name alternatives or state when not to use the tool, but the intended context is well conveyed without ambiguity.

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

All Teardrop tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

Most tools target distinct data sources, but several near-duplicates exist: get_token_approvals/get_wallet_approvals, get_defi_positions/get_wallet_positions, and get_wallet_portfolio/get_eth_balance. The descriptions do cross-reference and clarify the differences, so an agent can disambiguate with effort, but names alone are not enough.

Naming Consistency4/5

The dominant get_<noun> pattern is clear and nearly all names use lowercase snake_case with verb-first conventions. A few tools like calculate, record_predictions, http_fetch, and web_search break the get_ pattern, but the overall style remains predictable.

Tool Count2/5

34 tools is excessive for a single server, even for a broad DeFi/onchain analytics domain. The count is inflated by generic utilities such as calculate, count_text_stats, web_search, and http_fetch, plus multiple overlapping data-retrieval endpoints, making the surface hard to scan.

Completeness4/5

The set covers an unusually wide range of domain operations: prices, balances, portfolio/positions, approvals, yields, TVL, DEX quotes/volume, transactions, blocks, gas, ENS, contract reads, and risk assessments. It is view-only by design, so missing write/transaction tools is acceptable; minor gaps like address-based token pricing or transaction simulation are workaround-able.

Resources

Need Help?