Skip to main content
Glama
freeagent-mcp-server

freeagent-mcp-server

by samaxbytez

freeagent_list_credit_notes

Read-only

List FreeAgent credit notes and filter by view, contact, project, or updated date, with sorting and pagination to review open, overdue, draft, or refunded credits.

Instructions

List credit notes from FreeAgent with optional filtering and sorting

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

Input Schema

NameRequiredDescriptionDefault
pageNoPage number to fetch (default 1)
sortNoSort order, e.g. "created_at" or "-updated_at"
viewNoFilter credit notes by view
contactNoFilter by contact URL
projectNoFilter by project URL
per_pageNoResults per page (default 25, max 100). Check pagination.next_page in the response for more results.
updated_sinceNoOnly return credit notes updated since this ISO 8601 date
nested_credit_note_itemsNoWhether to include nested credit note items in the response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page
      Added value: +{
      +  "description": "Page number to fetch (default 1)",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / per_page
      Added value: +{
      +  "description": "Results per page (default 25, max 100). Check pagination.next_page in the response for more results.",
      +  "maximum": 100,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. First observedv1.3.0

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing beyond them — no mention of pagination behavior, default page size, auth requirements, or what the response contains — so it fails to add context the structured data doesn't already supply.

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?

A single front-loaded sentence with no wasted wording. It is efficient, though its brevity comes partly at the cost of the details noted in other dimensions.

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?

With 8 optional parameters, full schema coverage, and annotations covering the safety profile, the essentials are present. Still, for a paginated list endpoint with no output schema, the description could usefully note pagination and return shape, so it is only minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (page, sort, view, contact, project, per_page, updated_since, nested_credit_note_items) is already documented in the schema. The description only says filtering and sorting exist, adding no syntax or meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (List) and resource (credit notes from FreeAgent), which lets an agent distinguish it from the singular freeagent_get_credit_note. However, it doesn't explicitly call out that distinction or contrast with sibling list tools, so it stops just short of full sibling differentiation.

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

Usage Guidelines3/5

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

"Optional filtering and sorting" implies the tool is used to browse/query credit notes, but no guidance is given on when to use this versus freeagent_get_credit_note or how to page through results. Usage is only implied, with no exclusions or alternatives named.

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