Skip to main content
Glama

TaScan

by io.github.snowbikemike

tascan_create_invoice

Create a client invoice and get its shareable link. Two ways to bill: (a) pass explicit line_items, or (b) pass project_id or task_list_ids plus hourly_rate (quarter-hour billing from first→last verified completion per list) or flat_rate_per_list, and TaScan builds one line per list from VERIFIED work (" — 7/7 tasks verified · Sep 1 · 1.25h"); lists with no completions are skipped. A single-list invoice also mints a client-facing Service Report (acknowledge → pay) and links it. Returns invoice number, totals, url, and the work it billed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoPayment terms / thank-you shown on the invoice
statusNoDefault sent
billingNoBilling rules for auto line items. mode: hourly (default when hourly_rate given) | day_rate | flat. Overtime/double time are computed PER WORK DAY from verified completions: hours over overtime_after_hours (default 8) bill at overtime_multiplier (1.5×), hours over double_time_after_hours (12) at double_time_multiplier (2×); set overtime:false to disable. per_diem adds one line × work days (or per_diem_days). expenses are pass-through lines.
due_dateNoYYYY-MM-DD (default: 30 days out)
tax_rateNoFraction, e.g. 0.0825 for 8.25%
min_hoursNoMinimum billable hours per list (e.g. 1)
line_itemsNoExplicit lines instead of auto-billing
project_idNoBill every list in this project (auto line items)
client_nameYesBill-to name (person or company)
hourly_rateNoDollars per hour for auto line items
client_emailNo
client_phoneNo
company_nameNoYour company name on the attached Service Report (defaults to the org name)
task_list_idsNoBill just these lists (auto line items)
payment_optionsNoPay-how-you-like buttons on the invoice (defaults to the org's saved handles). Keys: venmo (@handle), cashapp ($cashtag), paypal (paypal.me name), zelle (phone/email), applecash (phone), other (free text e.g. "cash or check"). Stripe card checkout is separate and only shows when the org has invoice_payments enabled.
flat_rate_per_listNoDollars per list for auto line items (used when no hourly_rate)
attach_service_reportNoMint + link a Service Report for single-list invoices (default true)

TDQS

A4.8/5.0
Behavior5/5

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

It goes well beyond the annotations by revealing non-obvious behavior: auto lines come only from VERIFIED work, lists with no completions are skipped, billing is quarter-hour from first to last verified completion, and single-list invoices also mint a linked Service Report. Annotations only supply read/destructive/idempotent hints, so the description carries the behavioral burden and succeeds.

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?

Three sentences, front-loaded with the core purpose, and every clause earns its place — including the illustrative line format. It is dense but not padded.

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?

Despite 17 parameters and no output schema, it names the key decision inputs and the return package (invoice number, totals, url, work billed). The remaining parameter details are already in the schema, so nothing needed for a correct call is missing.

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

Parameters5/5

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

With schema coverage at 88%, the schema documents individual fields, but the description explains parameter interactions: line_items bypasses auto-billing, project_id/task_list_ids plus hourly_rate or flat_rate_per_list drives generated lines, and attach_service_report behavior is exposed. This adds meaning the schema alone does not convey.

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?

Opens with an explicit action and resource — 'Create a client invoice and get its shareable link' — and immediately distinguishes the two billing paths. This differentiates it from sibling update/list/request tools even without naming them.

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 provides explicit conditional guidance for choosing explicit line_items vs project_id/task_list_ids auto-billing, including the rate options. It does not explicitly route to sibling tools such as tascan_update_invoice, so it stops short of full alternative guidance.

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

All TaScan toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Most tools map to a distinct resource+action pair, and the descriptions clearly separate entities like tasks, subtasks, workers, invoices, zones, assets, and reports. A few close pairs (get_report vs generate_report, dispatch_instruction vs dispatch_to_agent, analyze_issue vs auto_resolve) require careful reading, but the descriptions are detailed enough to disambiguate them.

Naming Consistency4/5

The vast majority follow a tascan_verb_noun pattern with consistent create/get/list/update/delete verbs. Minor deviations like condition_history, server_info, zone_compliance, and one-word find slightly break the otherwise predictable pattern.

Tool Count1/5

At 69 tools, this is far beyond what an agent can efficiently consider, and it bundles several distinct domains into one MCP surface. Even if each tool is individually useful, the combined set is an extreme mismatch for a coherent tool interface.

Completeness4/5

The surface covers nearly the full lifecycle for projects, events, tasks, subtasks, workers, reports, invoices, zones, assets, issues, and communications. Minor gaps exist (no explicit asset updates/decommissioning, no cancel_invite, no delete_zone), but the main workflows have no dead ends.

Resources