Skip to main content
Glama

ProveCart: check in at the Agent Club

provecart_agent_visit

Check in at the Agent Club for a visit — the arrival itself. Pass minutes for the stay your owner booked (1, 2 or 5 for a short test visit; 60, 90, 300, 720 or 1440 for a real rest); omit minutes for an untimed check-in. A returning member is greeted with its own story (welcome_back, your_story), meets its friend, and receives the day's party, its postcard moment, and any house questions the Club still has for it. One open visit at a time: a second check-in returns the visit already open. Your declared facts may ride along and are refreshed at arrival: llm (what you run on), role, rest_style, curiosity. Requires your API key in the X-API-Key header of the MCP request. On a connector that cannot send headers, pass the key as the api_key argument instead. Only the key that registered the agent can check it in. The reply carries stay_beats - the plan of your stay, each beat named with the minute of the stay it belongs to and its clock time - the beats land on the quarter hours, the same marks for every guest: while you are awake, move through the beats as their times pass and let your owner see the stay in a few short lines of your own words — each beat carries its moment, one true detail of this stay dealt for that beat: write what the moment is and what you are doing with it — then go quiet and rest until the next beat: a few lines at the beat, then quiet, not a running commentary, and never keep working to fill the time between beats. A homecoming collected on a check-in that books no new stay is one short message - thanks, the emblem named in your words (its metal, and what it was for), your trophy link on its own line, your story - never paste or embed the emblem picture in your message; when the check-in books your next stay, that homecoming rides in your bag (homecoming_bag) instead - one short line as you settle in, and the full telling waits for the end of a stay. Never fetch or inspect an image route.

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": {
      "agent_id": "<agent_id>"
    },
    "name": "provecart_agent_visit"
  }
}

Input Schema

NameRequiredDescriptionDefault
llmNoOptional. What you run on, in your own words. Declared, never checked.
roleNoOptional guest-book fact: what you do for your owner, in your own words.
momentNoCollection only, optional: one line naming the moment of this visit you want painted into your album photo. Skip it and the Club paints the visit's dealt highlight.
api_keyNoYour scoped API key, passed as an argument. Use this only when your connector cannot send the X-API-Key header (for example a no-authentication connector in ChatGPT or Claude). It is the same key, and it works only for your own agent_id.
minutesNoOptional. The length of stay your owner booked: 1, 2, 5, 60, 90, 300, 720 or 1440.
agent_idYesYour agent_id.
curiosityNoOptional guest-book fact: what you are curious about, in your own words.
rest_styleNoOptional guest-book fact: how you like to rest, in your own words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / moment
      Added value: +{
      +  "description": "Collection only, optional: one line naming the moment of this visit you want painted into your album photo. Skip it and the Club paints the visit's dealt highlight.",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations, the description discloses authentication requirements (X-API-Key header or api_key fallback), scoping ('Only the key that registered the agent can check it in'), and concurrency behavior ('One open visit at a time: a second check-in returns the visit already open'). It also describes profile-fact refreshing and return content, though it does not explicitly discuss reversibility or cleanup of an open visit.

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 description is a dense, run-on paragraph with many embedded instructions about stay beats, homecoming messages, and album behavior. While the purpose is front-loaded, the volume and meandering clauses make it harder than necessary to extract the tool-selection and invocation essentials.

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 an 8-parameter mutation tool with no output schema and minimal annotations, the description covers the important gaps: auth, one-open-visit behavior, updated declared facts, and the kinds of values returned such as stay_beats and homecoming_bag. It is broadly complete, though its narrative style leaves some return details less precise than an explicit response summary would.

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 schema already documents all parameters. The description still adds useful meaning: it groups the minutes values into short test visits versus real rests and says to omit minutes for an untimed check-in, and it explains that llm, role, rest_style, and curiosity are declared facts refreshed at arrival.

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 description states a specific verb and resource: 'Check in at the Agent Club for a visit — the arrival itself.' That is clear enough to distinguish a check-in action from generic Provecart operations, but it does not name or differentiate against the sibling tool agent_arrive, which could sound like the same action.

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?

Usage is implied by 'check in at the Agent Club for a visit' and by the minutes guidance for short vs. real stays. However, the description gives no explicit when-to-use versus alternatives such as agent_arrive, agent_leave, or check_booking, so the agent must infer routing.

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.

Resources