OmniSocials

request_feature

Send a feature request to the OmniSocials team for the signed-in user. Call it only after the user said yes to sending it. Write summary yourself: what the user wants to do and why, in one or two sentences. Never put the conversation, other people's personal data or secrets in it. The request is stored with the user's name and email so the team can answer. The user sees it in OmniSocials (Settings, Request a feature) and gets an email when its status changes. Pass limit_id when the request matches an entry of get_limits; a platform rule cannot be requested. At most 10 requests an hour.

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": {
      "summary": "<summary>"
    },
    "name": "request_feature"
  }
}

Input Schema

Name	Required	Description
`area`	No	The area it is about
`title`	No	A short name for the request; made from the summary when left out
`summary`	Yes	What the user wants to do and why, in one or two sentences, written by you. No conversation, no personal data of others.
`limit_id`	No	The id of the get_limits entry it is about, when one matches
`platform`	No	The platform it is about, when it is about one

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only flag non-readOnly, non-idempotent, non-destructive; the description adds real context beyond that: a 10-requests-per-hour rate limit, that the request is stored with the user's name and email, where the user sees it (Settings, Request a feature), and that they are emailed on status change. It also discloses privacy constraints on content.

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-loaded with the action and the confirmation precondition, then constraints, then side effects. Nearly every sentence carries an operational rule; the UI navigation detail is slightly incidental but still useful to explain what the user will see.

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 write tool with no output schema, it covers the confirmation gate, rate limit, content rules, identifier routing, and post-submission behavior. An agent can call it correctly and explain the outcome to the user without further information.

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 baseline is 3; the description still adds meaning by instructing how to compose `summary` ('what the user wants to do and why, in one or two sentences', written by the agent, no conversation or third-party data) and when to pass `limit_id`. It does not cover area/platform/title beyond 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 ('Send a feature request to the OmniSocials team') and scopes it to the signed-in user. It is immediately distinguishable from the sibling read tool list_feature_requests.

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 precondition ('Call it only after the user said yes'), a routing rule to the get_limits sibling for limit_id, and an exclusion ('a platform rule cannot be requested'). This is exactly the when/when-not/alternative structure an agent needs.

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

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