eranfinish/ezatwork-mcp

Name: eranfinish/ezatwork-mcp
Author: eranfinish

by eranfinish

Overview Schema Source Related Servers Discussions Admin

Python

Remote

EZ@Work MCP Server

Connect EZ@Work — all-in-one business management for freelancers, lawyers, agencies, and service businesses — to Claude, Gemini, Cursor, and any MCP-compatible AI.

Tools (v1)

Tool	Description	Type
`list_clients`	List your clients/customers	Read
`list_projects`	List your projects/cases/work orders	Read
`log_time_entry`	Log billable hours to a project	Write
`create_invoice`	Create a draft invoice (auto currency/language/VAT)	Write

Related MCP server: bill4time-mcp

Setup

Claude Desktop / Claude.ai (OAuth — recommended)

Settings → Connectors → Add custom connector

URL: https://mcp.ezatwork.com/mcp
Authentication: OAuth (automatic)

Claude Code / Cursor / MCP Inspector (API token)

Create a free EZ@Work account at https://app.ezatwork.com
Generate an API token at https://app.ezatwork.com/settings/api-tokens
Connect to https://mcp.ezatwork.com/mcp with header Authorization: Bearer ezw_pat_...

Local testing with MCP Inspector:

npx @modelcontextprotocol/inspector

Connect to http://localhost:8080/mcp with header Authorization: Bearer ezw_pat_...

Security

Your data stays in your EZ@Work account
OAuth mode: Google identity → EZ@Work account lookup; no credentials stored in the MCP
API token mode: scoped permissions — grant only what you need; mandatory expiration
Authorization is verified on every request

Privacy Policy

https://www.ezatwork.com/privacy

Universal Design

EZ@Work adapts to your business type: a lawyer sees "cases," a freelancer sees "projects," a service business sees "work orders." Currency, language (24 supported), and tax rules auto-detect from your profile — no configuration needed in the MCP.

Development

Run locally

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install -e .

cp .env.example .env
# Edit .env: EZ_API_BASE=http://localhost:5000 for local backend

python -m ezatwork_mcp.server
# Server starts at http://localhost:8080/mcp

Run tests

pip install pytest pytest-asyncio
pytest tests/

Docker

docker build -t ezatwork-mcp .
docker run -p 8080:8080 -e EZ_API_BASE=https://api.ezatwork.com ezatwork-mcp

Deploy to Cloud Run

gcloud run deploy ezatwork-mcp \
  --source . \
  --region europe-west1 \
  --project ezatwork-production \
  --allow-unauthenticated \
  --port 8080 \
  --update-env-vars "EZ_API_BASE=https://api.ezatwork.com,MCP_BASE_URL=https://mcp.ezatwork.com" \
  --update-secrets "GOOGLE_CLIENT_ID=ezmcp-google-client-id:latest" \
  --update-secrets "GOOGLE_CLIENT_SECRET=ezmcp-google-client-secret:latest" \
  --update-secrets "EZ_MCP_MASTER_TOKEN=ezmcp-master-token:latest"

--allow-unauthenticated is correct — auth is enforced at the MCP layer (OAuth or API token), not at the Cloud Run IAM level.

Technical notes

Transport: Streamable HTTP (/mcp endpoint)
Library: fastmcp 3.3.1
Auth (OAuth): GoogleProvider from fastmcp.server.auth.providers.google
Auth (token): get_http_headers() from fastmcp.server.dependencies
Dual-auth: OAuth active when GOOGLE_CLIENT_ID + GOOGLE_CLIENT_SECRET + MCP_BASE_URL are set
Backend: GET /api/users/me for locale; GET /api/internal/users/by-email for OAuth→user mapping
Time entries: POST /api/timeentry with isBillable field
Invoices: POST /api/invoices with computed dueDate and total per item

Built by

EZ@Work — the business OS for independents.

Available Tools

5 tools

create_clientCreate ClientBInspect

Create a new client/customer.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Client's name (required)
`email`	No	Contact email
`notes`	No	Free-text notes
`phone`	No	Phone number (international format, e.g. +972501234567)
`status`	No	'active', 'inactive', or 'prospect' (default 'active')	active
`website`	No	Website URL
`vat_number`	No	VAT / tax registration number
`company_name`	No	Company/business name
`payment_terms_days`	No	Default invoice payment terms in days
`default_hourly_rate`	No	Default billing rate for this client

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

The description adds no behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false). It does not disclose potential side effects, validation, uniqueness constraints, or permission requirements, so transparency is limited.

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?

The description is a single sentence, 'Create a new client/customer,' which is extremely concise and front-loaded. It contains no filler and every word contributes to the purpose.

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?

The description, combined with the comprehensive input schema and output schema, is adequate for a basic create operation. However, it lacks usage timing and behavioral caveats, which are not covered elsewhere, leaving some gaps in the complete picture.

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?

The input schema already describes all 10 parameters with full coverage, so the description's lack of parameter details is acceptable. The baseline of 3 applies because the schema carries the semantic load.

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 clearly identifies the action (create) and the resource (client/customer), which distinguishes it from sibling tools like list_clients and create_invoice. However, it does not explicitly contrast with alternatives, so it misses the highest rating.

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?

The description offers no guidance on when to use this tool versus alternatives, nor does it state any prerequisites or exclusions. It simply states the action, leaving usage decisions entirely to the agent.

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

create_invoiceCreate InvoiceAInspect

Create a draft invoice. Currency, language, and VAT/tax rate are auto-detected from the user's EZ@Work profile — no need to specify.

ParametersJSON Schema

Name	Required	Description
`items`	Yes	List of line items, each {"description": str, "quantity": float, "unitPrice": float}
`client_id`	Yes	The client to invoice
`due_in_days`	No	Payment terms in days (default 30)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations indicate a non-read-only, non-destructive operation, which aligns with creating a draft. The description adds specific behavioral context: the invoice is created as a draft, and currency/language/VAT are auto-filled from the EZ@Work profile. This goes 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the primary action in the first sentence and supplementary detail in the second. No wasted words.

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?

Given the output schema exists and annotations cover safety, the description adequately covers the tool's core behavior. It doesn't repeat schema details, but it adds the essential auto-detection information. Minor gaps like payment terms are already in schema, so no further description needed.

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?

While the schema fully describes the three parameters, the description adds crucial context by explaining that currency, language, and VAT/tax rate are auto-detected and should not be specified. This prevents the agent from attempting to pass these as parameters and clarifies why they are absent from the schema.

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 opens with 'Create a draft invoice,' which clearly states the action and resource. It also distinguishes from sibling tools by focusing on invoice creation, while siblings handle clients, projects, and time entries. The auto-detection note further clarifies scope.

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?

The description implicitly signals when to use the tool (when creating a draft invoice) and clarifies that no currency/language/VAT specification is needed. However, it doesn't explicitly mention alternative tools or when not to use it, so it falls just 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.

list_clientsList ClientsA

Read-only

Inspect

List the user's clients/customers.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter by status — 'all', 'active', 'inactive', 'prospect'	all

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

The description adds user-scoping beyond the readOnlyHint annotation, indicating results are limited to the current user. It does not describe pagination or return format, but output schema covers these. Annotations already provide safety, and the added context is minimal.

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?

The description is a single short sentence with a clear verb and resource, front-loaded and without any unnecessary words. It earns every character.

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 simple read-only list tool with one optional parameter and an output schema, the description provides essential scope. It doesn't mention status filtering, but the schema compensates. The combination of description, annotations, and schema is sufficient.

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?

The input schema fully describes the 'status' parameter with 100% coverage. The description adds no additional parameter semantics, leaving the schema to carry this dimension. Baseline of 3 is appropriate.

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 uses the specific verb 'List' and identifies the resource 'clients/customers', clearly distinguishing it from sibling tools like create_client. It also adds the scope 'user's' to clarify ownership, making the purpose unambiguous.

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?

No explicit guidance on when to use vs alternatives. The read-only list nature is evident from the description and sibling context, so usage is implied rather than stated. It lacks direct 'when not to use' or alternative recommendations.

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

list_projectsList ProjectsA

Read-only

Inspect

List the user's projects (or cases/work orders — label adapts to businessMode).

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Optional status filter (e.g. 'in_progress', 'completed', 'on_hold')

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral context by disclosing that the label adapts to businessMode (e.g., cases or work orders), which is not inferable from annotations alone.

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?

The description is a single concise sentence that immediately states the tool's purpose and adds a relevant caveat. There is no wasted content, and the key information is front-loaded.

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?

For a simple read-only list operation, the description fully covers the tool's behavior, especially with an output schema present and the businessMode adaptation noted. No significant missing context remains.

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?

The input schema already fully describes the single 'status' parameter with 100% coverage, so the description does not need to repeat it. It adds no additional parameter semantics, hence a baseline score of 3 is appropriate.

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 starts with the verb 'List' and clearly identifies the resource as 'the user's projects', with a helpful note that labels adapt to businessMode (cases/work orders). This effectively distinguishes it from sibling tools like list_clients.

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?

The description states that it lists projects, which implies usage for project-related queries, but it does not explicitly provide when-to-use guidance, mention alternatives, or state when not to use it. The sibling tool list_clients exists, but the description itself does not differentiate.

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

log_time_entryLog Time EntryAInspect

Log a time entry (billable hours) to a project/case.

ParametersJSON Schema

Name	Required	Description
`hours`	Yes	Number of hours (e.g. 2.5)
`billable`	No	Whether these hours are billable (default true)
`project_id`	Yes	The project/case ID
`description`	Yes	What was done

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation. The description adds no further behavioral context: no permissions, side effects, or reversibility, and it doesn't explain what happens after logging. It merely restates the action, adding nothing 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, directly stating the action and target. It is appropriately concise and front-loaded.

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 simple tool with fully described schema parameters, safety annotations, and an output schema, the description is adequate. It captures the core purpose, though it omits any mention of prerequisites (e.g., project must exist) or when to choose this over alternatives. These gaps are minor given the tool's simplicity.

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?

All four parameters have full descriptions in the schema (100% coverage). The description text provides no additional parameter meaning beyond what the schema already documents, so the baseline of 3 applies.

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 uses the specific verb 'log' with the resource 'time entry' and target 'project/case', clearly differentiating it from sibling tools like create_client or create_invoice. It is immediately obvious what this tool does.

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?

The description implies usage (log hours to a project/case) but provides no explicit when-to-use instructions, prerequisites, or exclusions. There are no alternative tools mentioned, though the sibling list makes it unlikely to be confused. Guidance is minimal.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Aug 13, 2026
- First observedcreate_client
- First observedcreate_invoice
- First observedlist_clients
- First observedlist_projects
- First observedlog_time_entry

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-13 08:10 across 5 tools

Disambiguation5/5

Each tool targets a distinct resource and action: client creation/listing, project listing, time logging, and invoice creation. There is no overlap in purpose, so an agent can easily select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_client, list_projects, log_time_entry). The naming is predictable and uniform, with no mixed conventions.

Tool Count5/5

With 5 tools, the server is well-scoped for a small business management domain covering clients, projects, time tracking, and invoicing. Each tool serves a distinct purpose, and the count feels neither thin nor heavy.

Completeness4/5

The tools cover the core workflow from creating clients to logging time and generating invoices. Minor gaps like update/delete for clients or listing invoices exist, but agents can work around them for typical use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
mcp-serverOAuth
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
Mini AccountantOAuth
app.miniaccountant
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
E-commerce & Retail Finance ERP Systems
1
invoice-badgerOAuth
com.invoicebadger
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Finance Payments & Billing
2

Related MCP Servers

Clio Manage MCP
Legal & Compliance Project Management
patrickking67
A
license
A
quality
C
maintenance
MCP server that connects Clio Manage to Claude via OAuth, enabling law firm management tasks like matter lookup, time tracking, billing, calendar, and document retrieval through natural language.
Updated a month ago (2026-08-04 18:52 UTC)
41
MIT
bill4time-mcp
Legal & Compliance Finance
RosenAdvertising
A
license
C
quality
A
maintenance
MCP server for Bill4Time providing API coverage for legal billing and time tracking, enabling natural language interaction with clients, projects, time entries, invoices, payments, and more from Claude Desktop.
Updated 7 days ago (2026-09-07 22:31 UTC)
59
1
MIT
invoiceninja-mcp
Finance CRM Payments & Billing
ambaloo
A
license
B
quality
D
maintenance
MCP server for Invoice Ninja v5 API. Enables AI assistants to manage clients, invoices, quotes, payments, and time tracking through natural language.
Updated 8 months ago (2026-01-23 14:26 UTC)
32
16 npm
2
MIT
freshbooks-mcp-server
Finance Project Management
bitovi
F
license
Not graded
quality
A
maintenance
An MCP server that connects Claude to FreshBooks, enabling reading and management of invoices, clients, expenses, projects, and time entries via natural language.
Updated 5 days ago (2026-09-10 01:26 UTC)
1
-

Appeared in Searches

FastMCP-based servers for business operations (inventory, billing, payments, project management, or ecommerce)