Teardrop

Delegate To Agent

delegate_to_agent

Delegate a task to a remote A2A-compliant agent: discover its capabilities via its agent card, send it a message, handle payment, and return the result. Use only when no local platform tool can fulfil the request.

Use when: Use when a task requires specialist capabilities beyond the local tool set. Call discover_agents first when the remote agent URL is unknown. Do not retry unchanged after error_type=advertised_price_exceeds_cap; pick another result or adjust the cap.

Limitations: Requires an allowlisted remote URL and sufficient delegation budget; the remote agent's price and capability claims are read from its card and are not independently verified. Involves real payment.

Alternatives: discover_agents, web_search

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.

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.3/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and the description adds critical behavior beyond that: it involves real payment, requires allowlisted URL and budget, and notes that remote agent claims are not verified. This goes beyond annotations by warning about payment and unverified capabilities. Slight deduction for not mentioning error handling beyond the specific error_type, but substantial transparency.

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?

Description is well-structured with headings 'Use when', 'Limitations', 'Alternatives', making it scannable. It is appropriately sized given the tool's complexity. The opening sentence is concise, and the sections are efficient. Minor redundancy in mentioning 'payment' twice (in opening sentence and limitations), so 4 rather than 5.

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?

Given the tool's complexity (involving payment, remote agent, A2A protocol), the description covers key operational aspects: discovery, retry behavior, preconditions. An output schema exists, so return format is not required. It lacks detailed communication protocol expectations, but for a delegation tool, this is sufficient. Strong coverage.

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?

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds a small note about task_type being for telemetry (echoing schema's 'never include user data'), which aligns but doesn't add new meaning. It doesn't explain how task_description should be formatted beyond natural language, but baseline 3 is appropriate given full schema coverage.

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 clearly specifies the action (delegate a task to a remote A2A-compliant agent), the resource (remote agent), and the outcome (return the result). It distinguishes itself from local tools by stating 'only when no local platform tool can fulfil the request', which differentiates it from siblings like http_fetch and web_search.

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?

Provides explicit 'Use when' conditions, requires calling discover_agents first if URL unknown, and warns against retrying on specific error_type. It also names alternatives (discover_agents, web_search) in the Alternatives section, giving clear guidance on when to use this tool versus alternatives.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?