Skip to main content
Glama

resolve_person_batch

Resolve up to 200 people to canonical AnchorIDs in one batch call. Provide a client reference and at least one identifier; ambiguous matches return needs_review status with candidates.

Instructions

Resolve multiple people to AnchorIDs in a single call (max 200). Each item needs a client_ref for correlation and at least one identifying field. Ambiguous matches return status needs_review with candidate AnchorIDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesArray of person resolution requests

Implementation Reference

  • src/tools.ts:171-212 (registration)
    The tool 'resolve_person_batch' is registered via server.tool() call on line 172 within the registerTools() function. The registration includes the tool name, description, Zod schema for inputs (items array of person resolution requests, max 200), and the async handler function.
    // ─── 4. resolve_person_batch ─────────────────────────────────────
    server.tool(
      "resolve_person_batch",
      "Resolve multiple people to AnchorIDs in a single call (max 200). " +
        "Each item needs a client_ref for correlation and at least one identifying field. " +
        "Ambiguous matches return status needs_review with candidate AnchorIDs.",
      {
        items: z
          .array(
            z.object({
              client_ref: z.string().describe("Your reference ID for correlation"),
              email: z.string().optional(),
              name: z.string().optional(),
              company_entity_id: z.string().optional(),
              company_domain: z.string().optional(),
              identifiers: z
                .object({
                  slack_user_id: z.string().optional(),
                  google_user_id: z.string().optional(),
                  salesforce_contact_id: z.string().optional(),
                  hubspot_contact_id: z.string().optional(),
                  phone: z.string().optional(),
                })
                .optional(),
              min_confidence: z.number().min(0).max(1).optional(),
            }),
          )
          .max(200)
          .describe("Array of person resolution requests"),
      },
      async (input) => {
        try {
          const data = await api.post(
            "/resolve/person:batch",
            input as Record<string, unknown>,
          );
          return jsonContent(data);
        } catch (e) {
          return errorContent(e);
        }
      },
    );
  • The handler for 'resolve_person_batch' (lines 201-211) is an async function that posts the input to '/resolve/person:batch' via the ApiClient, returning JSON content on success or error content on failure. It catches errors and delegates formatting to helper functions.
    async (input) => {
      try {
        const data = await api.post(
          "/resolve/person:batch",
          input as Record<string, unknown>,
        );
        return jsonContent(data);
      } catch (e) {
        return errorContent(e);
      }
    },
  • The input schema for 'resolve_person_batch' uses Zod to define an 'items' array (max 200 items). Each item requires a 'client_ref' string and has optional fields: email, name, company_entity_id, company_domain, identifiers (slack_user_id, google_user_id, salesforce_contact_id, hubspot_contact_id, phone), and min_confidence.
    {
      items: z
        .array(
          z.object({
            client_ref: z.string().describe("Your reference ID for correlation"),
            email: z.string().optional(),
            name: z.string().optional(),
            company_entity_id: z.string().optional(),
            company_domain: z.string().optional(),
            identifiers: z
              .object({
                slack_user_id: z.string().optional(),
                google_user_id: z.string().optional(),
                salesforce_contact_id: z.string().optional(),
                hubspot_contact_id: z.string().optional(),
                phone: z.string().optional(),
              })
              .optional(),
            min_confidence: z.number().min(0).max(1).optional(),
          }),
        )
        .max(200)
        .describe("Array of person resolution requests"),
    },
  • The jsonContent() helper function formats successful API responses as MCP tool text content. Used by the handler to return results.
    function jsonContent(data: unknown) {
      return {
        content: [{ type: "text" as const, text: JSON.stringify(data, null, 2) }],
      };
    }
  • The errorContent() helper function formats errors (especially ApiError instances) as MCP tool error content with isError flag. Used by the handler for error reporting.
    function errorContent(err: unknown) {
      if (err instanceof ApiError) {
        const payload = {
          error: err.message,
          status_code: err.status_code,
          request_id: err.request_id,
          details: err.details,
        };
        return {
          content: [{ type: "text" as const, text: JSON.stringify(payload, null, 2) }],
          isError: true,
        };
      }
      return {
        content: [{ type: "text" as const, text: (err as Error).message ?? String(err) }],
        isError: true,
      };
    }
Behavior3/5

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

With no annotations, the description carries full burden. It discloses that ambiguous matches return a 'needs_review' status with candidate AnchorIDs and imposes a 200-item limit. However, it does not mention potential side effects, authorization needs, or error handling, leaving gaps for a batch mutation 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 concise sentences with zero redundancy. The key constraints (batch, max 200, client_ref, identifying field, ambiguous match behavior) are front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch tool with nested objects and no output schema, the description covers essentials (batch size, field requirements, ambiguous match handling) but lacks details on success response format, error cases, or prerequisites. It is adequate but leaves some completeness gaps.

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% (baseline 3). The description adds value by stating 'at least one identifying field' and explaining the client_ref's purpose for correlation, which goes beyond the schema's property descriptions.

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 resolves multiple people to AnchorIDs in a single call, distinguishing it from the singular resolve_person sibling. It specifies 'max 200' and uses the verb 'resolve' with an explicit resource.

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 provides clear context for when to use this batch tool (for multiple people, max 200) and outlines requirements (client_ref, at least one identifying field). It implies the singular alternative for single requests but does not explicitly state when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nolenation04/anchord-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server