Skip to main content
Glama
Clockbook-com

Freelance MCP server

Official
by Clockbook-com
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

freelance_approve_milestone

Approve submitted work to release escrow funds to the freelancer. Requires explicit acknowledgment when the milestone is funded, confirming the payee and amount before funds are released.

Instructions

MOVES MONEY, AND CANNOT BE UNDONE. Approve submitted work, moving the milestone SUBMITTED -> APPROVED -> PAID. On a milestone whose escrowStatus is FUNDED this is the call that RELEASES the escrow: the held money becomes the freelancer's cash-out balance, and nothing in this product can pull it back. Requires the SPEND scope, enforced by the server. ON A FUNDED MILESTONE YOU MUST SEND acknowledge: true, and that flag means one specific thing: the person you are acting for has been told the amount and the payee and has said yes to THIS release. It is not a formality to set by default. Call it without the flag first if you are unsure - the refusal comes back as FREELANCE_ACKNOWLEDGEMENT_REQUIRED and carries the exact amount, currency and payee, which is the sentence to put in front of the person before you re-send with the flag. The flag is per call and never per session: a milestone's amount can change between two calls, so consent to an earlier one is consent to a different number. On a milestone nobody funded, the flag is ignored and this only moves the status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe contract id.
acknowledgeNoConfirmation that the person you are acting for has approved THIS release, after being told the amount and who receives it. Required when the milestone is FUNDED.
milestoneIdYesThe milestone id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden. It discloses the irreversible, money-moving nature, the acknowledgment requirement, the error response, and the per-call scope of the flag. This is exemplary behavioral transparency.

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?

The description is dense but front-loaded with the most critical warning, and every sentence adds value. It is longer than typical but justified by the high-stakes, irreversible nature of the operation.

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 the tool's complexity (irreversible money movement), the lack of annotations, and no output schema, the description is thorough. It covers when to use, prerequisites, error handling, and consent semantics, leaving no critical gaps.

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 coverage is 100%, so parameters are fully documented. The description adds crucial context for 'acknowledge', explaining its meaning and conditional requirement, which goes beyond the schema. The 'id' and 'milestoneId' are straightforward and don't need extra description.

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 clearly states the tool approves submitted work and moves milestones through statuses, specifically releasing escrow on funded milestones. It distinguishes this from siblings like submit_milestone and fund_milestone by focusing on the approval and payment action.

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 explains when to use the tool (on submitted or funded milestones) and provides critical guidance on the acknowledge flag, including when not to use it. It also references sibling tools implicitly by contrasting with funding and refunding.

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