Hailbell

get_ai_replies

Read-only

The app's AI replies settings, as in the dashboard's Settings › AI replies. The AI answers customers in the app's support chat when nobody has replied within the wait. Returns settings (enabled, wait, name, knowledge, guide, appInfo, pricing, faq), limits (the most characters each text field keeps; longer text is cut) and aiConfigured (whether the server has an AI key; without one the AI never answers, even when enabled). The settings belong to the app, so every platform (iOS, Android, web) of it returns the same. Read this before update_ai_replies.

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": "get_ai_replies"
  }
}

Input Schema

Name	Required	Description	Default
`appId`	No	The app to act on, from list_apps. Optional when the key belongs to one app.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description goes well beyond them: it discloses the return shape (settings, limits, aiConfigured), explains that text fields are truncated to the limits, that aiConfigured=false means the AI never answers even when enabled, and that settings are app-scoped and therefore identical across platforms. These are non-obvious behavioral facts an agent could not infer from annotations or schema.

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

Conciseness4/5

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

Front-loaded with the identity of the resource and the dashboard mapping, then the behavioral details, then the sibling handoff. It is longer than strictly necessary — the 'AI answers customers ... within the wait' sentence partly restates what 'enabled'/'wait' mean — but each sentence carries real information and the ordering is logical.

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

Completeness5/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 carries the burden of describing returns and does so field by field (enabled, wait, name, knowledge, guide, appInfo, pricing, faq, limits, aiConfigured). Combined with the platform-invariance note and the update handoff, an agent has everything needed to call and interpret this tool.

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?

The single appId parameter already has a full schema description (100% coverage) naming list_apps as its source. The description reinforces app-scoping by stating the settings belong to the app and are shared across platforms, but adds no format, default, or omission-rule detail beyond the schema. Baseline 3 applies.

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?

Names a specific verb and resource (the app's AI replies settings) and anchors it to a concrete UI location ('Settings › AI replies'), then explains the underlying behavior the settings control. Nothing among the siblings (list_apps, get_user, list_notifications, etc.) overlaps, so the tool is unambiguously identifiable.

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

Usage Guidelines4/5

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

Explicitly says 'Read this before update_ai_replies', giving a clear read-before-write ordering against the natural alternative. It does not state any when-not-to-use case or note that appId may be omitted in single-app keys, but for a simple getter the guidance is concrete.

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

All Hailbell 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?