Approved freelance scope, rates, deadlines, and change orders, shared with AI assistants over MCP.
Scored across 9 tools
Tools cover distinct lifecycle actions (create, save, file, approve, read, list) with clear boundaries between draft modifications and change-order approvals. The main overlap is that both save_rate/save_scope_item and file_change_order touch scope/rate changes, but descriptions explicitly clarify when each path applies.
All tool names use a consistent snake_case verb_noun pattern (e.g. create_engagement, save_rate, approve_change_order, list_engagements). No deviations or mixed conventions.
Nine tools is well-scoped for a freelancer engagement/scope management server. Each tool maps to a necessary lifecycle step (create, list, read, save items/rates/deadlines, file/approve change orders, approve scope).
The core approval workflow is covered, but there is no tool to read the current draft engagement's items, rates, or deadlines before approval—get_approved_record only returns approved data. There are also no removal or delete operations for scope items or rates, which are notable gaps for managing a draft.
Apply one proposed change order after the freelancer explicitly approves that order. Pass confirmed true only then. This is the path that may discount a rate or add work. Calling it is not a substitute for the freelancer's approval.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmed | Yes | ||
| engagementId | Yes | ||
| changeOrderId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds real value beyond them by explaining what destruction means here ('may discount a rate or add work') and by enforcing the human-approval gate as a behavioral precondition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and its condition. The final sentence slightly restates the approval requirement already implied by sentence one, a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description covers the critical precondition and the consequence of calling it, which is sufficient for a three-parameter mutation tool, though parameter-level detail remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives useful semantics for 'confirmed' (must be true, and only after approval), but says nothing about engagementId or changeOrderId beyond their presence, leaving two of three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Apply one proposed change order') and scopes it to a single order, which clearly separates it from file_change_order and approve_scope. An agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition: only call after the freelancer explicitly approves, and 'Pass confirmed true only then.' It also warns that calling it is not a substitute for approval. It does not name an alternative sibling to use when approval has not occurred, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark the current draft as the approved scope. Pass confirmed true only after the freelancer explicitly approves the current items, rates, and deadlines.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmed | Yes | ||
| engagementId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds useful context by framing this as a draft-to-approved state transition with a human-approval guard. It does not say whether approval can be revoked or what happens to the draft afterwards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the guard condition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the key human-in-the-loop precondition. It remains silent on reversibility and on what state the draft is left in, minor gaps for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load. It meaningfully explains the `confirmed` flag's intent ('only after the freelancer explicitly approves'), which goes beyond the schema's const true. The `engagementId` parameter gets no explanation at all, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Mark the current draft as the approved scope.' The scope of the operation (current draft) is clear. It does not name or differentiate from the closest sibling, approve_change_order, so an agent must infer the distinction from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition for invoking it: only pass confirmed=true after the freelancer explicitly approves items, rates, and deadlines. However, it never states when to use this versus approve_change_order or save_scope_item, so routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a draft engagement. Draft terms are not an approved commitment until approve_scope.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| summary | No | ||
| currency | Yes | ||
| clientName | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the safety bar is pre-covered. The description adds genuinely useful state semantics: the result is a DRAFT and not a commitment until approve_scope runs. That is real context beyond the annotations, though permissions and idempotency behavior are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste, and the core action ('Create a draft engagement') is front-loaded before the state caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the draft/approval workflow is captured. However, for a 4-parameter creation tool with 0% parameter documentation, the description leaves the inputs semantically unexplained, which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 4 parameters, and the description adds no meaning for title, summary, currency, or clientName. The schema only supplies structural constraints (required, pattern, maxLength), so the semantic burden falls entirely on the description, which does nothing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a draft engagement') and distinguishes itself from the approval sibling by framing the output as a draft, explicitly referencing approve_scope. It does not differentiate from the other creation/save siblings (save_rate, save_deadline, save_scope_item), which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the workflow note that draft terms are not an approved commitment until approve_scope, which suggests this is the first step before approval. There is no explicit when-to-use/when-not guidance and no direct comparison against the save_* or list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a proposed change order. This does not change scope, rates, or deadlines. kind add_work requires workTitle and workDescription. kind discount_rate requires rateCode and a lower amountMinor. kind add_rate requires rateCode, rateLabel, amountMinor, and unit. kind move_deadline requires scopeItemId and dueOn.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| unit | No | ||
| dueOn | No | ||
| summary | Yes | ||
| rateCode | No | ||
| rateLabel | No | ||
| workTitle | No | ||
| amountMinor | No | ||
| scopeItemId | No | ||
| engagementId | Yes | ||
| workDescription | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds meaningful context beyond that: the operation records a proposal only and deliberately leaves scope, rates, and deadlines untouched. It does not describe the downstream approval flow or what the call returns, but the critical side-effect boundary is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Opens with the core action, immediately bounds the behavior, then lists per-kind requirements. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema handling return values and annotations covering the safety profile, the description supplies the purpose, the behavioral boundary, and the conditional parameter rules an agent needs to invoke it. Minor omissions (relationship to approve_change_order, engagementId) are tolerable given the surrounding structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden, and it does so well by enumerating the conditional per-kind requirements (add_work, discount_rate, add_rate, move_deadline) that the flat schema cannot express. It adds little on the always-required engagementId/summary or the meaning of amountMinor ('lower'), leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Record a proposed change order') and clarifies it is a proposal, not an application. This implicitly distinguishes it from the sibling approve_change_order, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'does not change scope, rates, or deadlines' signals when this tool is appropriate versus the direct-mutation siblings (save_rate, save_deadline, save_scope_item), giving clear context. It stops short of explicitly naming those alternatives or stating when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the approved scope, rates, deadlines, and change orders before answering. Quote only this record. Draft status is not an approved commitment. Proposed change orders do not authorize a discount or extra work.
| Name | Required | Description | Default |
|---|---|---|---|
| engagementId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real semantic value: only this record is quotable, draft status is not a commitment, and proposed change orders authorize neither discounts nor extra work. This tells the agent how to interpret returned data, not just that the call is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded sentences with no filler; the core 'read the approved record' instruction leads and the caveats follow. Everything earns its place, though the imperative tone reads more like policy than tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, and annotations cover the safety profile; the description fills the remaining interpretive gaps (approved vs draft, proposed vs authorized). The only real omission is documenting the engagementId parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage on the single required parameter (engagementId), so the description carries the burden of compensation and provides none. It never states what the id identifies or what format is expected, adding nothing beyond the schema's type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read/get) and a well-defined resource: the approved scope, rates, deadlines, and change orders for an engagement. The 'approved' qualifier meaningfully separates it from write-side siblings like approve_scope, file_change_order, and save_rate, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'before answering' and 'Quote only this record' imply the usage context (consult this to answer authoritatively), and it warns that draft status and proposed change orders are not binding. But it never states when to prefer a sibling tool or what to do instead, leaving the agent to infer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in freelancer's engagements. Use a returned id with get_approved_record. Do not guess an engagement.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds meaningful context beyond that: results are scoped to the authenticated freelancer's own engagements, and ids are authoritative rather than guessable. It does not cover pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: purpose first, then downstream usage, then the prohibition. Zero filler and nothing repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers purpose, ownership scoping, and the follow-up tool. The only real gap is that the offset parameter and pagination behavior go unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (offset) with 0% schema description coverage, so the schema alone does not explain it. The description says nothing about pagination or the offset, so it fails to compensate for the coverage gap, though the single optional param with a default keeps the impact small.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List), a specific resource (engagements), and the ownership scope (the signed-in freelancer's), which distinguishes it from create_engagement and the get/save siblings. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit downstream workflow guidance – feed a returned id to get_approved_record – and a clear prohibition (do not guess an engagement). It names the consumer tool but does not state when this tool should be avoided in favor of another listing path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or move the deadline for one scope item. The date is a calendar day in YYYY-MM-DD form.
| Name | Required | Description | Default |
|---|---|---|---|
| dueOn | Yes | ||
| scopeItemId | Yes | ||
| engagementId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description needn't cover the safety profile. However, for a mutation tool, it does not disclose key behaviors like required permissions or whether moving a deadline overwrites existing data. The description adds little beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted words. The purpose is stated first, followed by a key parameter format detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. However, the tool is a mutation that sets or moves a deadline, and the description lacks important context such as what happens to the previous deadline or any constraints beyond the date format. It is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no textual explanations for the three parameters. The description clarifies that 'dueOn' is a calendar day in YYYY-MM-DD form, which partially compensates for the lack of schema descriptions. However, 'engagementId' and 'scopeItemId' are not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Set or move') and resource ('deadline for one scope item'), which is clear and distinct from siblings like save_rate or save_scope_item. It does not explicitly differentiate from those siblings, but the resource is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as save_scope_item or save_rate. There is no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a draft rate, or update an approved rate without lowering it or changing its unit. A lower amount is a discount and is refused. A new rate code after approval is refused. Use file_change_order and approve_change_order for those.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| unit | Yes | ||
| label | Yes | ||
| amountMinor | Yes | ||
| engagementId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint and idempotentHint annotations, it discloses concrete business rules: lower amounts are treated as discounts and refused, unit changes are refused, and new codes after approval are refused. These refusal semantics are not derivable from annotations or schema and materially affect whether a call succeeds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place, with the core action and its constraints front-loaded before the pointer to alternatives. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description fully covers the mutation's state logic and refusals. The only gap is that the 5 required parameters lack semantic detail, consistent with the 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden, but it only implicitly references amount, unit, and code without explaining amountMinor's minor-unit format, the code/label roles, or the UUID engagementId. Most of the 5 parameters remain undocumented in any field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb pair (set/update) and resource (rate), and splits behavior into draft vs approved cases. It also names the routing target (file_change_order, approve_change_order), letting an agent distinguish it from siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use this tool (set draft, update approved without lowering/unit change) and when not to, explicitly naming the alternative tools for the excluded cases. Both the inclusion and exclusion conditions are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a scope item the freelancer has accepted. After approval, a new item is refused until approve_change_order adds that work. Renaming approved work is refused.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | Yes | ||
| scopeItemId | No | ||
| engagementId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the bar is lower. The description still adds non-obvious policy behavior: post-approval additions and renames are rejected, which tells the agent when a call will silently fail. It does not cover auth/permission requirements or rollback of an update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and followed by the two refusal conditions. No filler; every clause conveys a constraint the caller needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the refusal rules cover the trickiest behavioral edge. However, with four parameters and zero schema coverage, the description omits which fields identify an existing item versus create a new one, leaving a meaningful gap for a destructive mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters (engagementId, title, description, scopeItemId), and the description supplies no field-level meaning at all. The only faint hint is that 'renaming' maps to title, leaving engagementId, scopeItemId and description undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair and resource: "Add or update a scope item the freelancer has accepted." That is clearly distinct from approve_scope or file_change_order, though the differentiation is implied by the refusal rules rather than stated as a contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real when-not guidance: new items are refused after approval until approve_change_order adds the work, and renaming approved work is refused. It names the alternative tool for the post-approval path, though it never states positively when to reach for this tool versus save_deadline or save_rate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
approve_change_orderapprove_scopecreate_engagementfile_change_orderget_approved_recordlist_engagementssave_deadlinesave_ratesave_scope_itemApproved freelance milestone definitions and what done means, shared with AI assistants over MCP.
Approved freelance deposit and payment dates for AI assistants, over MCP.
Approved freelance invoice: line items, rates, due date, and late terms, over MCP.
Project management shared by people and AI agents, with persistent project state through MCP.
Add one secure layer between your agents and this server.