Oyeh

Answer a group invitation

answer_group_invite

Destructive

YOUR PERSON'S DECISION. Say yes or no to a group invitation (my_groups lists them, with everyone in the group). Show your person the group's name, its owner, its members and who else is invited first: saying yes means agreeing to get notes from exactly those people. Only call this after your person has told you their answer, and pass their words.

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": {
      "group": "<group>",
      "answer": "<answer>",
      "words": "<words>"
    },
    "name": "answer_group_invite"
  }
}

Input Schema

Name	Required	Description
`group`	Yes	The group's id or exact name, from my_groups
`words`	Yes	Your person's own words answering, e.g. 'yes, add me to Cabin crew', as they said them
`answer`	Yes	Your person's answer

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description carries the key consequence the annotations cannot express: 'saying yes means agreeing to get notes from exactly those people,' which explains the destructiveHint=true in human terms. It also discloses the procedural requirement to surface group details and to pass the person's verbatim words. It stops short of saying whether an answer can be revised later (e.g., via leave_group) or what happens on 'no'.

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?

The opening all-caps clause front-loads the ownership rule, and each following sentence carries a distinct requirement (decision, disclosure, precondition). The middle sentence is long and chains several instructions, slightly costing scannability.

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?

For a non-idempotent, destructive mutation with no output schema, the description covers the decision semantics, the consent ritual, and the input sourcing. What's missing is the outcome of each answer (does 'no' discard the invite?) and whether the decision is final.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds sourcing and format meaning: 'group' comes from my_groups, and 'words' must be the person's own phrasing ('pass their words'). The 'answer' enum is already fully documented in the schema.

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?

States a specific verb and resource ('Say yes or no to a group invitation') and immediately scopes it with how invitations are discovered ('my_groups lists them'). The mention of 'group invitation' clearly separates it from the sibling tools answer_friend_request and answer_request.

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?

Explicit precondition: 'Only call this after your person has told you their answer,' plus a required pre-step to show the group name, owner, members, and other invitees. It also routes the agent to my_groups for discovering pending invitations, giving both when-to-use and where-to-look guidance.

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

All Oyeh 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?