Skip to main content
Glama

taxapp.nz

by nz.taxapp
OverviewDiscussionsAdmin

Change a contact

update_contact
DestructiveIdempotent

Changes a contact that is already there, by its id from list_contacts: its name, contact types, email, phone numbers, website, addresses, IRD number or notes. contact_types replaces the types it has now, so include the ones it keeps. A contractor's PAYE salary and ACC classifications have their own tools. Give only what changes: every parameter left out keeps the value the record has now. Read the record first, and confirm the change with the person before making it. Only for an organisation where this connection may add and change records (list_organisations says which). The answer is the changed contact.

Input Schema

NameRequiredDescriptionDefault
nameNoA business's name.
clearNoOptional fields to empty, by parameter name, any of: name, first_name, last_name, email, phone, mobile, website, physical_address_line, postal_address_line, ird_number, notes.
emailNoEmail address.
notesNoFree text kept with the contact.
phoneNoPhone number.
mobileNoMobile phone number.
websiteNoWebsite address.
last_nameNoA person's last name.
contact_idYesThe contact's id, from list_contacts.
first_nameNoA person's first name.
ird_numberNoTheir IRD number, as the person gives it.
contact_typesNoEvery type the contact has from now on, one or more of: supplier, tenant, contractor, property-owner, landlord or accountant, or a type the organisation added itself (list_choices gives every one with its label).
organisation_idNoThe id of the organisation to use, from list_organisations. Leave it out when the connection covers only one organisation; it is required when it covers more than one.
postal_address_lineNoPostal address, on one line.
physical_address_lineNoStreet address, on one line.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false; the description adds important behavioural nuance beyond them, including partial-update semantics, the replacement behaviour of contact_types, the need to read/confirm before mutation, and permission constraints. There is no contradiction with the 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?

Despite covering many parameters and constraints, the description is front-loaded and dense with no wasted sentences. Each clause serves a distinct purpose: scope, replacement semantics, alternative tools, partial-update rule, safety steps, permission requirement, and return value.

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?

For a 15-parameter mutation tool with no output schema, the description supplies the critical missing behavioural context: omission semantics, contact_types replacement, permission gating, pre-read/confirmation guidance, and the return value. This is complete for correct invocation.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining that omitted parameters keep existing values and that contact_types replaces current types, though it does not explain the clear parameter beyond what the schema already provides.

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 states a specific verb and resource ('Changes a contact that is already there') and lists the mutable fields, clearly distinguishing this tool from create_contact and from the specialised PAYE/ACC tools. An agent can identify the operation and its scope immediately.

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?

It explicitly says to provide only changed values, that omitted parameters retain current values, to read the record first, and to confirm with the person before changing it. It also names alternatives for contractor PAYE salary and ACC classifications, and states the organisational permission prerequisite.

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

All taxapp.nz toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources