freeagent-mcp-server

freeagent_list_estimates

Read-only

List FreeAgent estimates with optional filters for contact, project, date range, view, and update time to find and review the estimates you need.

Instructions

List estimates from FreeAgent with optional filtering

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_estimates"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number to fetch (default 1)
`view`	No	Filter estimates by view
`contact`	No	Filter by contact URL
`project`	No	Filter by project URL
`to_date`	No	Filter estimates to this date (YYYY-MM-DD)
`per_page`	No	Results per page (default 25, max 100). Check pagination.next_page in the response for more results.
`from_date`	No	Filter estimates from this date (YYYY-MM-DD)
`updated_since`	No	Only return estimates updated since this ISO 8601 date
`nested_estimate_items`	No	Include nested estimate items in the response

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.0.0Nov 6, 2026

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"
+}

First observedv1.3.0Jun 21, 2026

TDQS

C2.9/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 no behavioral context of its own — nothing about result volume, pagination, default page size, or that all parameters are optional and unfiltered calls return everything. It essentially restates the tool name.

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 short, front-loaded sentence with no wasted words. It is not padded, though it is also too thin to earn a 5 for structure that helps an agent decide.

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 no required parameters and no output schema, an agent must know whether an unfiltered call dumps the whole estimate list and how pagination works — the schema covers page/per_page, but the description never signals the default result set or that filtering is the recommended path. Adequate but with clear gaps for a 9-parameter list tool.

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% and each of the 9 parameters carries its own description, including format hints like YYYY-MM-DD and the pagination pointer. The description contributes no additional meaning beyond that, so the baseline 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?

States a specific verb and resource ('List estimates from FreeAgent'), which clearly separates it from the estimate mutation siblings (create/update/delete/mark) and from freeagent_get_estimate. It stops short of explicitly naming a sibling as the alternative, but the read-many scope is unambiguous.

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

Usage Guidelines2/5

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

Only 'with optional filtering' hints at usage; there is no statement of when to use this versus freeagent_get_estimate (single record) or how to combine filters. No exclusions, prerequisites, or alternatives are provided.

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

Deploy Server