Skip to main content
Glama
Sign In
Blujay MCP Server

Blujay MCP Server

Official
by blujayhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Find contacts

find_contacts
Read-only

Search contacts by name, phone number, or email, or list saved and unsaved contacts with paging to find people and see who was added from texts and calls.

Instructions

Search your contacts by name, phone number or email, or with none of those, list them (newest changes first). A list shows contacts someone saved; set unsaved for the ones Blujay added on its own when you texted or called.

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

Input Schema

NameRequiredDescriptionDefault
emailNo
limitNo
queryNoName or part of one.
cursorNoWhen listing: next_cursor from a previous call, for the next page.
unsavedNoWhen listing: show the contacts nobody has saved yet instead of saved ones.
phone_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely useful behavior – list ordering (newest changes first) and the fact that a default list only shows saved contacts. It says nothing about result volume, paging behavior, or match semantics (exact vs partial), which would matter for an open-world search tool.

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?

Two tight sentences, front-loaded with the searchable fields and then the no-parameter listing mode. Every clause carries information; nothing is restated from the schema or annotations.

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 six-parameter read tool with no output schema, the description covers the searchable fields, the listing mode, ordering, and the saved-vs-unsaved distinction, which is most of what an agent needs. Missing only match-granularity and result-shape hints, which are minor given no output schema is declared.

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

Parameters4/5

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

Schema coverage is only 50%, and the description compensates by mapping the search keys to the email, phone_number and query parameters and by explaining `unsaved` more richly than the schema does (contacts nobody saved, auto-created from call/text activity). `limit` and `cursor` are left to the schema, which documents cursor adequately but not limit's meaning.

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?

States a specific verb plus resource and enumerates the three search keys (name, phone, email), then explicitly covers the fallback behavior of listing everything ordered by newest changes. This clearly separates the search mode from the list mode, which is the main ambiguity an agent would face.

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?

Gives clear conditional guidance: supply a search term to search, supply none to list, and flip `unsaved` to see the contacts Blujay created automatically from texts or calls. It does not name any sibling alternative, but the read-only lookup role is unambiguous against siblings like save_contact or opt_out_contact.

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