Skip to main content
Glama

Search contacts

search_contacts
Read-onlyIdempotent

Finds saved contacts on this seat. name and number are separate filters. Set either one, or both. A contact matches every filter that is set. Omit both to match every contact. A number matches saved numbers, including a national form of the same number. Returns names and phone numbers for one page. limit and offset are the page that was applied, and total is the full match count.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional. Saved contact name, or part of a name. Omit it to leave the name filter off.
limitNoRows in this page. Default 10, maximum 25.
numberNoOptional. One phone number. Matches saved numbers, including a national form of the same number. Omit it to leave the number filter off.
offsetNoRows to skip before this page. The following page starts at offset plus count.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "Optional. Saved contact name, or part of a name. Omit it to leave the name filter off.",
      +  "type": "string"
      +}
    • addedInput schema / properties / number
      Added value: +{
      +  "description": "Optional. One phone number. Matches saved numbers, including a national form of the same number. Omit it to leave the number filter off.",
      +  "type": "string"
      +}
    • removedInput schema / properties / query
      Removed value: -{
      -  "description": "Optional. Name, part of a name, or one phone number. Omit it or leave it blank to match every contact.",
      -  "type": "string"
      -}
  2. Changed2 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Name, part of a name, or one phone number. Blank matches every contact."New value: +"Optional. Name, part of a name, or one phone number. Omit it or leave it blank to match every contact."
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  3. Changed3 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"Rows in this page. Default 10, maximum 25."
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Rows to skip before this page. The following page starts at offset plus count.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / query / description
      Added value: +"Name, part of a name, or one phone number. Blank matches every contact."
  4. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description usefully adds what a match means for phone numbers (national form also matches) and what one page contains, but it stops short of stating ordering of results or what happens when total exceeds limit.

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?

Purpose comes first, then filter semantics, then result shape — a sensible order with no filler. The filter rules are stated three times in slightly different phrasings ('separate filters,' 'either one or both,' 'matches every filter that is set'), which costs a little length.

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?

With no output schema, the description correctly takes on the job of describing the return payload (names, phone numbers, one page) and the limit/offset/total triple. That covers what an agent needs; only result ordering and page-advance behavior remain unstated.

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 100%, so the baseline is 3, and the description adds genuinely new semantics: filters combine with AND logic and an unset filter matches all. The pagination sentence restates limit/offset established by the schema, so it is slightly redundant rather than additive.

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?

Opens with a specific verb and resource, 'Finds saved contacts,' and narrows scope with 'on this seat,' which separates it from account-wide or number-inventory lookups. It does not explicitly name the nearest sibling (search_numbers), so a small inference is still required to route between them.

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 operating context: set either filter or both, a contact matches every filter set, and omitting both matches everything. That removes most ambiguity about when and how to call it, though it never states when to prefer a different search tool or any prerequisites.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.