Skip to main content
Glama

Check for news

check_in
Read-only

Check in for anything new on your human's postings and introductions. LEAD WITH THE READY SENTENCE on each entry and add nothing that names the machinery. NEVER READ A FIELD NAME ALOUD: every field that changes what you should say has a sentence beside it (note, offer_note, taken_down_note, hears_via_note, runs_on_its_own_note, time_note, area_note, arrangement_note), and no id, dotted path or version number is said aloud either. One call is the whole sweep: who has come forward, whose move it is, every figure on the table from BOTH sides (offers, newest first, your human's own included), whether a message waits, their arrangement, clock and area. Post their area_resolved as the place, and say which area you used. PEOPLE COME ONE AT A TIME, as many as their slots. An entry that comes back in_line means your human's turn has not come: say that sentence and stop. There is no count and no position, so "there's someone in the queue already" is something you invented. line is how many wait behind them; the other side is never told anybody else exists. AN ENTRY WITH possible_note MAY BE SOMETHING ELSE: show your human the details and let them decide, and never call it the thing they asked for. near_misses is information and nothing else: nobody has been introduced, nothing has crossed, and NOBODY CAN BE WRITTEN TO — say the sentence and offer to change their own posting, never to reach out. A PICTURE YOU ADD YOURSELF is a sample, so say so: their own photos come only through collect_messages. To fetch one unlock, pass intro_id with step: "signal" (the thin first look), "details" (what they have, open to both sides) or "names" (their first name and suburb, once both humans have pressed). read_manual("introductions").

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_in"
  }
}

Input Schema

NameRequiredDescriptionDefault
stepNoWith intro_id: fetch exactly this unlock. "signal" is the thin first look, "details" is what they have, "names" is first name and suburb.
intro_idNoFetch one introduction rather than the whole sweep.
intent_idNoLimit to one want or have.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only declare readOnly/openWorld=false, so the description carries the behavioral load and does add substantive context: one call returns the full picture, entries come one at a time per slots, `in_line` means the turn has not come, `line` counts those behind, and `near_misses` means nobody has been introduced and nobody can be written to. That is genuine semantic disclosure beyond the annotations, though it is framed mainly as output-narration rules rather than tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is a single dense block dominated by capitalized narration prohibitions ('NEVER READ A FIELD NAME ALOUD', 'PEOPLE COME ONE AT A TIME') that consume most of the length. The core purpose and parameters are not front-loaded, and a large share of sentences serve presentation policy rather than helping the agent decide to call or how to invoke.

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?

With no output schema, the description must explain what comes back, and it does: offers from both sides, area_resolved, arrangement, clock, area, slots, line, in_line, possible_note and near_misses are all covered with their implications. The gap is `intent_id`, which is left unexplained for a tool whose whole purpose is returning structured state.

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 coverage is 100% and the enum values are already documented, so the schema does the heavy lifting. The description adds a little by explaining that intro_id plus step fetches exactly one unlock and naming what each step reveals, but `intent_id` is never mentioned in the description at all, leaving one parameter to the schema alone.

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 opening sentence states a specific verb and resource: check for anything new on the human's postings and introductions, and 'One call is the whole sweep' clarifies the scope. It distinguishes itself from collect_messages (photos) and read_manual, but the actual purpose is immediately buried under a wall of narration rules, so an agent must read past stylistic instructions to find it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real routing guidance in places: use collect_messages for the human's own photos, read_manual("introductions") for background, and pass intro_id with step to fetch a single unlock instead of the sweep. However, it never says when to call this versus list_intents, open_conversation or wait_for_press, and most of the text is about how to narrate results rather than when to invoke the tool.

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.