Skip to main content
Glama
ati-hh-mcp

ati-hh-mcp

by timur-ai

Set Chat Write Possibility

set_chat_write_possibility

Enable or disable an applicant's ability to write messages in an employer-side chat, requiring confirm=True to apply the change.

Instructions

Enable or disable the applicant's right to write messages in the chat (employer side; applicant_write_possibility is sent as a query parameter). Mutation: requires confirm=True.

Input Schema

NameRequiredDescriptionDefault
bodyNo
chat_idYes
confirmNo
applicant_write_possibilityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden; it does disclose the key non-obvious trait that this is a mutation gated on confirm=True. It omits permissions required, whether the change is reversible, and what the caller gets back, which matter for a write tool with zero annotation coverage.

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?

A single tightly packed sentence with the capability first and the confirm requirement trailing as a caveat. Nothing is redundant and no words are wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers the core action and the confirm gate but leaves the `body` parameter and the return behavior unaddressed. Adequate to invoke safely, not complete.

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 description coverage is 0%, yet the description adds real meaning for two parameters: applicant_write_possibility is passed as a query parameter, and confirm must be true. The `body` parameter (anyOf object/null, the largest ambiguity in the schema) is left entirely unexplained, so compensation is only partial.

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?

States a specific verb pair (enable/disable) and the exact resource (the applicant's right to write in a chat), plus the actor perspective (employer side). An agent can distinguish it from send_chat_message or update_chat_participants without opening schemas, though it never explicitly names those alternatives.

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?

Gives one concrete precondition (confirm=True required for this mutation) which is genuinely actionable. It does not say when to prefer this over update_chat_participants or what happens if the chat is closed/archived, so usage context is only implied.

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