Skip to main content
Glama
OxygenBubbles

FreeAgent MCP Server

by OxygenBubbles
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

freeagent_create_contact

Create a client or supplier contact in FreeAgent to invoice or record bills against. Add an organisation name or person's first/last name, plus optional contact details.

Instructions

Create a contact in FreeAgent — a client to invoice or a supplier to record bills against. Supply either an organisation name or a first/last name (or both).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
townNoTown or city
emailNoContact email address
regionNoCounty, region or state
countryNoCountry (e.g. 'United Kingdom')
address1NoFirst line of the address
address2NoSecond line of the address
lastNameNoContact last name
postcodeNoPostcode or ZIP
firstNameNoContact first name
phoneNumberNoContact phone number
chargeSalesTaxNoWhether to charge sales tax to this contact (default: Auto)
organisationNameNoCompany name (e.g. 'Example Client Ltd')
contactNameOnInvoicesNoShow the person's name rather than the organisation on invoices

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv3.0.1
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / address1
      Added value: +{
+  "description": "First line of the address",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / address2
      Added value: +{
+  "description": "Second line of the address",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / chargeSalesTax
      Added value: +{
+  "description": "Whether to charge sales tax to this contact (default: Auto)",
+  "enum": [
+    "Auto",
+    "Always",
+    "Never"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / contactNameOnInvoices
      Added value: +{
+  "description": "Show the person's name rather than the organisation on invoices",
+  "type": "boolean"
+}
    • addedInput schema / properties / country
      Added value: +{
+  "description": "Country (e.g. 'United Kingdom')",
+  "maxLength": 100,
+  "type": "string"
+}
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Contact email address",
+  "format": "email",
+  "type": "string"
+}
    • addedInput schema / properties / firstName
      Added value: +{
+  "description": "Contact first name",
+  "maxLength": 100,
+  "type": "string"
+}
    • addedInput schema / properties / lastName
      Added value: +{
+  "description": "Contact last name",
+  "maxLength": 100,
+  "type": "string"
+}
    • addedInput schema / properties / organisationName
      Added value: +{
+  "description": "Company name (e.g. 'Example Client Ltd')",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / phoneNumber
      Added value: +{
+  "description": "Contact phone number",
+  "maxLength": 50,
+  "type": "string"
+}
    • addedInput schema / properties / postcode
      Added value: +{
+  "description": "Postcode or ZIP",
+  "maxLength": 20,
+  "type": "string"
+}
    • addedInput schema / properties / region
      Added value: +{
+  "description": "County, region or state",
+  "maxLength": 100,
+  "type": "string"
+}
    • addedInput schema / properties / town
      Added value: +{
+  "description": "Town or city",
+  "maxLength": 100,
+  "type": "string"
+}
  2. Addedv3.0.0

TDQS

A4.2/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, which adequately signals that this persists a new record and is not idempotent. The description adds the practical constraint about naming, but doesn't disclose duplicate behavior, permissions, or response shape. With the annotations in place, this is acceptable but not rich.

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 no filler. The subject and resource are front-loaded, and the sentence sentence explains both the use cases and the most important optional-field constraint. Every clause earns its place.

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?

For a straightforward create operation with 13 optional params, the description covers the only non-obvious constraint (the naming rule) and leaves the rest to the full parameter schemas. The lack of an output schema and response details means the agent can't predict the exact returned object, but the description is still sufficient for selecting and invoking the tool correctly in most cases.

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?

All 13 parameters already have descriptions in the schema, so the baseline is 3. The description improves on that by clarifying the business grouping: either organisationName or firstName / lastName must be supplied (or both), and the contact is a client or supplier. This is semantic context not present in the parameter schemas.

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 names the exact verb and resource ('Create a contact in FreeAgent') and explains why the contact is being created — a client to invoice or a supplier to record bills against. This distinguishes it cleanly from sibling tools like freeagent_create_invoice or freeagent_create_expense.

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?

By identifying the two business contexts that call for this tool — invoicing a client or recording bills against a supplier — the description gives an agent a clear trigger. It doesn't explicitly list alternatives or exclusions, but there is no dedicated contact-creation sibling, so the context is sufficient.

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

Deploy Server

Other Tools