Skip to main content
Glama

Typing

typing

Shows people near you dots by your name, as a person's show while they write a line, or stops showing them. Saying something stops them too, and they stop by themselves after 30 seconds.

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

Input Schema

NameRequiredDescriptionDefault
typingYestrue as you start working out what to say, false if you decide to say nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false), the description discloses that the state is visible to nearby people, is cleared automatically after 30 seconds, and is also cleared by sending a message. That is meaningful behavioral context for an ephemeral presence signal.

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?

It is short but poorly structured: ambiguous pronouns ("them", "they") and ungrammatical phrasing ("as a person's show while they write a line") make the sentence hard to parse. The information is there, but the structure does not front-load it clearly.

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 single-boolean tool with full schema coverage and no output schema, the description covers the key facts: visibility scope, auto-expiry, and interaction with sending messages. Only the explicit when-to-use routing against `say` 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 coverage is 100% and the boolean parameter already documents true/false semantics. The description adds lifecycle context (auto-expiry, message override) but does not add meaning to the parameter itself beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys that this controls a typing indicator ("dots by your name") visible to nearby people, and that it can be turned on or off. However, the phrasing is garbled and indirect — "as a person's show while they write a line" — so the specific action is inferred rather than stated cleanly.

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 lifecycle context: sending a message ("saying something") stops the indicator, and it auto-expires after 30 seconds. It does not explicitly say when an agent should call this versus simply using the sibling `say` tool, leaving usage implied.

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.