Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

search_contacts

Read-only

Find contact IDs by searching names, emails, customer or vendor numbers, and roles so you can use the correct ID in follow-up contact and accounting operations.

Instructions

Find contacts by name, email address, number or role.

One API call per page. This is how a name becomes an id: every tool taking a contact_id expects one from here, never a guessed value. Use get_contact afterwards for the full record with its addresses.

Rows carry the id, name, customer and vendor numbers and one way to get in touch. A row marked archived is no longer in active use.

Filters combine with AND. Giving none lists the account in name order. Read page before asking for another one.

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

Input Schema

Name	Required	Description	Default
`name`	No	Part of the contact's name, matched case-insensitively against company names and person names. At least 3 characters, the API rejects anything shorter.
`page`	No	Zero-based page number. Read the `page` block of the previous result before asking for another one, rather than paging blindly.
`role`	No	Restrict to contacts that are customers, or that are vendors. 'any' does not restrict.	any
`size`	No	Rows per page. A larger page costs the same single API call but more of the answer's token budget, so raise it only when the whole list is genuinely needed.
`email`	No	Part of any email address on the contact, matched case-insensitively. At least 3 characters.
`number`	No	The customer or vendor number a human uses for this contact, for example 10001. This is not the contact id.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.3Nov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotation readOnlyHint=true already establishes the safety profile, and the description adds cost and shape context beyond it: "One API call per page," rows carrying id/name/customer and vendor numbers plus one contact method, and that an `archived` row is out of active use. It does not describe error or empty-result behavior, which keeps it short of a 5.

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 purpose and the id-resolution rationale, then rows, then filter/paging rules. Nearly every line earns its place, though the "Read `page` before asking for another one" instruction restates the schema's own `page` description.

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?

No output schema exists, so the description must describe the returned rows — it does, including the id and the one-contact-method limitation. For a 6-parameter, entirely optional-parameter search tool, nothing an agent needs to call it correctly is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds genuine disambiguation the schema lacks — notably that `number` is the human-facing customer/vendor number and "not the contact id," and that paging should be driven by the returned `page` block rather than guessed. That meaning reduces a real misuse mode.

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+resource ("Find contacts") and enumerates the searchable fields (name, email, number, role). It also positions the tool against siblings by naming `get_contact` as the follow-up for the full record, so an agent can distinguish search from retrieve without opening either schema.

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

Usage Guidelines5/5

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

Explicit about when to use it ("This is how a name becomes an id: every tool taking a `contact_id` expects one from here, never a guessed value") and when to go elsewhere ("Use `get_contact` afterwards for the full record"). Also states AND-combination of filters and the no-filter default ordering, leaving little to inference.

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