Skip to main content
Glama
Sign In
NexusAndroid

NexusAndroid

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

messages

Read-onlyIdempotent

Read SMS and RCS conversations by contact or conversation, paginate older threads, and retrieve attached photos.

Instructions

The phone's SMS and RCS messages. No argument: recent conversations [N] with contact, date, unread count. conversation=N, or contact="Alice" (address book name): the last limit messages (up to 500), with the images most recent photos attached (0 for none; videos and files are only mentioned). before: ISO date given at the end of a response ("older: …") to read the next, older page. Response limited to about 60,000 characters, cut between two messages.

Input Schema

NameRequiredDescriptionDefault
limitNo
beforeNo
imagesNo
contactNo
conversationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.3
    • addedInput schema / properties / before
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Before"
+}
  2. First observedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, and the description adds substantial context beyond them: a ~60,000 character response cap cut between two messages, a 500-message ceiling on limit, the fact that videos and files are only mentioned while photos are attached, and the exact pagination mechanism via the "older: …" token. That is the kind of disclosure an agent needs to plan calls and handle truncation.

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?

Dense but front-loaded: the resource is named first, then each argument mode in sequence, ending with the response-size caveat. Slightly run-on in phrasing, but nearly every clause carries actionable information.

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 compensates by describing the return shape for each mode (conversations with contact, date, unread count; messages with attached images) and the truncation/pagination behavior. An agent can call this correctly and know how to continue reading.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does: limit is bounded at 500 messages, images sets how many recent photos are attached (0 for none), before is an ISO date taken from the prior response, and contact vs conversation are two addressing modes for the same target. Only the defaults (limit=15, images=4) are left unstated.

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 the resource precisely ("The phone's SMS and RCS messages") and enumerates the three operating modes: no argument for recent conversations, conversation/contact for message threads. It is clearly distinct from siblings like notifications or phone, though it never explicitly names those siblings to route against.

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?

It gives concrete when-to-use guidance at the argument level: omit arguments for a conversation list, pass conversation=N or contact="Alice" for a thread, and use `before` with the ISO date at the end of a response to page older. It does not, however, say when to prefer this tool over siblings such as notifications or look.

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

Deploy Server

Other Tools