Skip to main content
Glama

Local MCP

by com.local-mcp
OverviewDiscussionsAdmin

Signal Search Messages

signal_search_messages
Read-only

Full-text search across locally-cached Signal messages. Only messages Signal Desktop has stored on disk are searched — no network access required. Optionally restrict search to a specific chat_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (default 50)
queryYesSearch text (case-insensitive substring match)
chat_idNoOptional chat ID to restrict search

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of results returned
resultsYesMatching messages

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedOutput schema / properties / results / items / properties / body / description
      Previous value: -"Message body text"New value: +"Message body text (null for messages without text)"
    • changedOutput schema / properties / results / items / properties / body / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / results / items / properties / sender / description
      Previous value: -"Sender phone number"New value: +"Sender phone number (null for messages sent by you)"
    • changedOutput schema / properties / results / items / properties / sender / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The annotation readOnlyHint=true already indicates a non-destructive operation. The description adds transparency by explaining that the search is limited to locally-cached data and that no network access is involved, providing a clear picture of the tool's behavior beyond the annotation.

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?

The description is concise, consisting of two sentences. It front-loads the main purpose and immediately provides key scope constraints. There is no superfluous information or redundancy.

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?

The description provides sufficient context to understand the tool's purpose, scope, and optional parameter. It does not explicitly mention the return format, but this is expected to be covered by the output schema. The description is complete enough for an agent to decide when and how to invoke the 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?

Schema coverage is 100% with each parameter (query, limit, chat_id) having a descriptive explanation. The description does not add additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.

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?

The description clearly states the tool's purpose: performing a full-text search on locally-cached Signal messages. It specifies the resource (Signal messages), the action (search), and the scope (locally-cached), which distinguishes it from network-based search tools like slack_search_messages or gdrive_search_files.

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?

The description explicitly notes that only messages stored on disk are searched and that no network access is required, which serves as a guideline for when to use this tool over alternatives that may require connectivity. It also mentions the optional chat_id restriction, giving practical usage context.

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

All Local MCP toolsInspect
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