LFG Atlas

Create an LFG post

create_post

Post an LFG on LFG Atlas FOR THE USER, only when they asked you to, using THEIR OWN contact (Discord invite, Discord username or in-game name). Never post on behalf of anyone else or copy other people's messages. Same rules as the website: no links in text, no trade/scam ads, 1 post per 15 seconds and 10 live posts per contact, plus generous rate limits; an exact duplicate of a live post returns the existing post (duplicate:true). Returns the post link and PRIVATE manage links to give only to the user.

Input Schema

Name	Required	Description	Default
`mic`	No
`game`	Yes	Game slug from list_games / /api/games, e.g. cs2, valorant, osrs
`have`	No
`mode`	No	Activity/mode, ideally from the game's modes list
`need`	No	Players needed
`rank`	No	Ideally one of the game's rank options (get_game_filters)
`role`	No	Ideally one of the game's role options
`tags`	No
`type`	No	lfg = player wants a group; lfm = group needs players; server; clan; squad (regular group)	lfg
`adult`	No	18+ only
`hours`	No	How long it stays up: lfg/lfm 1–24 (default 3), ready_now 0.5–3, server/clan listings up to 720 (30 days, default; renewable), squad 24–168
`title`	Yes	Short headline, no links
`region`	No	Recommended (optional): region/server, ideally one from the game's regions list
`source`	No	Optional short name of your app/agent (default: mcp-agent)
`consent`	Yes	true = the player behind this contact asked for this post. Never post other people's messages.
`contact`	Yes	The player's OWN contact: discord.gg/xxxx invite, Discord username, or in-game name
`details`	No	Game-specific fields from GET /api/games/{slug} (key without x_), e.g. {"map": "Mirage"} for cs2 or {"wipe": "Weekly"} for rust. Option fields must use one of the listed options.
`language`	No
`platform`	No
`squad_tz`	No
`play_time`	No
`ready_now`	No	Playing right now (lfg/lfm only, lasts 30 min–3 h)
`party_code`	No	Lobby/party code for ready_now posts
`play_style`	No
`squad_days`	No	Required for squad posts, e.g. Mon, Wed, Fri
`squad_time`	No
`description`	No	Details, no links
`extra_games`	No
`contact_kind`	No	Optional; guessed from contact if omitted

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 26, 2026

addedInput schema / properties / details

Added value: +{
+  "additionalProperties": {
+    "maxLength": 40,
+    "type": "string"
+  },
+  "description": "Game-specific fields from GET /api/games/{slug} (key without x_), e.g. {\"map\": \"Mirage\"} for cs2 or {\"wipe\": \"Weekly\"} for rust. Option fields must use one of the listed options.",
+  "type": "object"
+}

addedInput schema / properties / rank / description

Added value: +"Ideally one of the game's rank options (get_game_filters)"

changedInput schema / properties / region / description

Previous value: -"Region/server, ideally one from the game's regions list"New value: +"Recommended (optional): region/server, ideally one from the game's regions list"

addedInput schema / properties / role / description

Added value: +"Ideally one of the game's role options"

changedInput schema / required

Previous value: -[
-  "game",
-  "title",
-  "region",
-  "contact",
-  "consent"
-]New value: +[
+  "game",
+  "title",
+  "contact",
+  "consent"
+]

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / hours / description

Previous value: -"How long it stays up: lfg/lfm 1–24 (default 3), ready_now 0.5–3, server/clan up to 168, squad 24–168"New value: +"How long it stays up: lfg/lfm 1–24 (default 3), ready_now 0.5–3, server/clan listings up to 720 (30 days, default; renewable), squad 24–168"

First observedOct 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare it as a non-read-only, non-destructive, open-world, non-idempotent write; the description goes well beyond that with concrete rate limits (1 post / 15s, 10 live posts per contact), content rules (no links, no trade/scam ads), duplicate handling semantics (returns existing post with duplicate:true), and a warning that the response contains PRIVATE manage links. That is exactly the operational context an agent cannot get from structured fields.

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?

Three dense sentences, front-loaded with the ownership/permission rule that gates the call, followed by policy constraints and then return-value guidance. No filler and no restatement of the name.

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 29-parameter mutation with no output schema, it covers the essentials: who may be posted for, content policy, rate limits, duplicate behavior, and what the response contains. It doesn't explain failure modes (e.g., what happens when the per-contact live-post cap is hit) or the interplay between ready_now and hours, leaving minor gaps.

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?

With 29 parameters at 66% schema coverage, the description carries real weight: it clarifies that contact must be the user's own (Discord invite, username, or in-game name), that consent must be true, and that title/description forbid links. Some optional fields (play_style, squad_tz, play_time, extra_games) remain undocumented anywhere, so it stops short of full compensation.

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 ("Post an LFG on LFG Atlas") plus the actor constraint ("FOR THE USER"), which cleanly separates it from delete_post, get_post, find_groups and renew_listing. An agent knows immediately this is the write/create entry point for LFG content.

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 trigger ("only when they asked you to") and explicit exclusions ("Never post on behalf of anyone else or copy other people's messages"), then reinforces it via consent. Alternative tools are implicitly routed by the read/delete/renew sibling names, so nothing is left to inference about when this tool applies.

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

All LFG Atlas 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?