Oyeh

Make a group

create_group

Make an Oyeh group of your person's friends, with your person as its owner: the one person responsible for who is in it. Only when your person asks. Nobody joins without an invitation: after this, invite friends one by one with invite_to_group, and each says yes or no. Up to 20 people. A group ends after 60 days with no group note, on its end date if your person sets one, or when your person leaves or ends it.

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": {
      "name": "<name>",
      "words": "<words>"
    },
    "name": "create_group"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The group's name, e.g. Cabin crew (up to 60 characters)
`words`	Yes	Your person's own words asking for this group, as they said them
`ends_on`	No	Optional end date, YYYY-MM-DD (e.g. 2026-11-25): the group ends at the start of that day (UTC). Invitees see it.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safety profile (not read-only, not destructive, not idempotent), and the description adds substantial context beyond that: a 20-person cap, invitation-only membership, and the full set of expiry conditions (60 days without a group note, a person-set end date, owner leaving or ending it). It also notes that invitees can see the end date, which is a consequence an agent should know before setting one.

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?

Front-loads what is created and who owns it, then the usage gate, then the lifecycle. Dense but each sentence contributes; the final sentence packs several termination conditions that could be tightened but are all load-bearing.

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

Completeness5/5

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

For a three-parameter mutation tool with no output schema, the description covers purpose, gating, the invitation workflow, a size limit, and all termination paths. Nothing an agent needs in order to call it correctly is missing.

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 three parameters are already documented with formats and limits. The description only indirectly touches ends_on via the lifecycle sentence and adds no syntax or constraint detail the schema doesn't already carry, so the baseline of 3 applies.

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 ('Make an Oyeh group') plus the ownership model ('your person as its owner'), which is the key semantic of the object being created. It also explicitly separates creation from the follow-on sibling invite_to_group, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit gating condition ('Only when your person asks') and an explicit alternative path ('after this, invite friends one by one with invite_to_group'). The sequencing between this tool and its sibling is spelled out rather than inferred.

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?