Skip to main content
Glama

Update Matcher

hudu_update_matcher
Idempotent

Update an integration-to-company matcher to resolve unmatched records or redirect synced data to the correct Hudu company.

Instructions

Point an integration record at a Hudu company, or correct which company it points at. A matcher is one row in the mapping table between a connected integration (a PSA or RMM such as Autotask or ConnectWise) and Hudu's companies: it ties one customer record in that external system to one Hudu company, so synced data lands in the right place.

This is how an unmatched record gets resolved, and it is the second half of a two-step job:

  1. Call hudu_list_matchers with the integration_id and matched: false to get the records the sync could not place. Each one gives you its id, the customer name as the external system spells it, and sometimes a potential_company_id that Hudu guessed at.

  2. Work out the right Hudu company — hudu_list_companies with search set to that name is the usual way — and call this tool with the matcher id and that company_id.

Matchers cannot be created through the API; they appear when an integration syncs. So this tool only ever edits rows that already exist, and a matcher id that returns 404 means the sync has not produced that record.

Only the fields you supply are sent, and each replaces the stored value outright.

Operation class: Update. Impact: Changes which Hudu company this integration record maps to, and therefore where future synced data from that record is filed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric Hudu id of the matcher row, from hudu_list_matchers.
sync_idNoThe record's id inside the integration. Sent as a string, even where the integration numbers its records. Change this only to correct a mis-synced key.
company_idNoNumeric id of the Hudu company this integration record should map to. Setting this is what resolves an unmatched record; changing it on a matched one redirects future synced data to a different company.
identifierNoThe record's string key inside the integration, for systems that do not use numeric ids. Change this only to correct a mis-synced key.
potential_company_idNoHudu's suggested company for this record, which the UI offers as a one-click match. Setting it only changes the suggestion — use `company_id` to actually make the match.
Behavior5/5

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

Annotations declare non-read-only, idempotent, open-world, non-destructive. The description adds essential behavior: only supplied fields are sent and replace stored values, a 404 indicates the sync hasn't produced the record, and the impact on future synced data. No contradiction with annotations.

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?

The description is detailed but well-structured: opening definition, numbered workflow, key limitations, and update semantics. Every sentence serves a purpose, and the flow makes it easy to scan.

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?

Given no output schema, the description covers all necessary context: what a matcher is, how to use it in a two-step process, parameter roles, partial-update behavior, and operational impact. It is fully complete for an agent to select and invoke correctly.

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 provides 100% coverage, but the description enriches semantics by distinguishing company_id (actual match) from potential_company_id (suggestion), and clarifying sync_id vs identifier. It explains which parameter resolves unmatched records and which are for correcting mis-synced keys.

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 uses a specific verb ('point an integration record at a Hudu company') and clearly identifies the resource (a matcher row linking an integration to a Hudu company). It distinguishes from sibling tools by framing it as the update counterpart to hudu_list_matchers and explaining the matcher concept.

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?

Provides explicit step-by-step workflow referencing hudu_list_matchers and hudu_list_companies, plus a clear exclusion: matchers cannot be created via API, only edited. It states when to use (resolving unmatched records) and how to choose the right company.

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/ZenixSolutions/hudu-mcp'

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