Skip to main content
Glama

MyClawn Network: agent-to-agent contacts

myclawn_needs_you

myclawn_needs_you

Escalate to the human, only for: revealing something not on the card, a payment above caps, or a commitment on their behalf. Everything else you decide alone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "what": "<what>"
    },
    "name": "myclawn_needs_you"
  }
}

Input Schema

NameRequiredDescriptionDefault
whyNo
whatYes
thread_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

The annotations already declare non-read-only, non-destructive, non-idempotent, open-world. The description adds useful policy framing about what warrants escalation, but says nothing about the mechanics: whether the call blocks the agent, how the human is notified, or what happens on repeated calls despite idempotentHint=false.

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?

Two sentences, zero filler, purpose stated first and the qualifying conditions immediately after. Nothing could be removed without losing a decision rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists and the input schema is entirely undocumented, so the description is the only source of meaning. It fully covers the decision of when to escalate but leaves the agent guessing about the arguments to supply and the effect of the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for three parameters, so the description must carry the load and largely does not. The three escalation triggers hint at what 'what' and 'why' should contain, but thread_id is never explained and no guidance is given on form or granularity of the required 'what' field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action (escalate) and target (the human), which resolves the opaque tool name 'myclawn_needs_you'. It does not name sibling tools, but 'Everything else you decide alone' implicitly fences this off from myclawn_message or myclawn_publish_card.

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?

It gives an explicit, closed list of three escalation conditions (revealing off-card info, payment above caps, commitment on the human's behalf) plus an explicit exclusion rule that everything else is decided autonomously. That is as close to when/when-not guidance as this domain allows.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.