Autroid

Per-branch trading figures — invoiced sales and invoice count, outstanding and overdue receivables, and delayed job count, for EACH branch separately, ranked by invoiced sales. Answers "which branch is doing better", which no other tool can: every other group read consolidates. Figures are never combined across branches and never re-derived — each one is produced by running an already-certified branch-scope read (sales.read.revenue_summary, finance.read.receivables_summary, operations.read.jobs_delayed) once per branch. Turnaround time, NPS and revenue per bay are NOT measured by this platform and are reported as absent in notMeasured rather than estimated. At BRANCH scope it honestly returns the one branch the credential can see. Examples: "compare my branches"; "which branch made the most this month"; "which outlet is owed the most money"

exec.read.branch_performance

Compares revenue, expense and net profit between a period and its baseline — month-on-month, quarter-on-quarter, or the same period last year — and reports the absolute and percentage change for each. Both figures come from finance.read.pl_summary, so they match that tool exactly. Both windows are shifted by the same calendar unit, so a part-way-through month is compared against the same days of the baseline rather than against a full one. A percentage change from a zero baseline is reported as unavailable with the reason, never as 0% or 100%. Examples: "how does this month compare to last month"; "revenue year on year"; "are we doing better than last quarter"; "compare this quarter to the same quarter last year"

exec.read.period_comparison

Per-conversion drill-down for a window: booking, customer, car, invoice amount, attribution method (auto/manual), and confidence — cursor-paginated. Row-level detail for verifying conversions; not a revenue total (use measurement_snapshot for canonical revenue). Examples: "show the conversion ledger"; "which leads converted to revenue"

marketing.read.conversion_ledger

Customers ranked by measured lifetime value, with average and median value, revenue concentration in the largest few, and value tiers derived from this branch's own distribution. Lifetime value is what a customer was BILLED (ledger debits on Accounts Receivable); outstanding balance is reported separately and never mixed into it. Customers with no ledger attribution are EXCLUDED rather than counted at zero, and the response states how many that was. No predicted or projected value is offered — only measured history. Examples: "who are our most valuable customers"; "customer lifetime value"; "which customers are worth the most"

crm.read.customer_ltv

Report leads sharing a phone number, and separately the much smaller set that look like one enquiry recorded twice (both still open, raised within a declared window). A shared phone number is NOT treated as a duplicate: a lead is an enquiry, not a person, so a returning customer legitimately has many leads on one number — the largest groups in practice are fleet and B2B accounts. READ-ONLY: never merges, deletes, or reassigns a lead. Examples: "find duplicate leads"; "leads with the same phone number"; "are we double-entering leads"

crm.read.lead_duplicates

Ranks parts by how much money was consumed in them over a period and splits them into class A, B and C by cumulative share. Value comes from the cost recorded on each stock movement at the time it happened, never from today's cost. Parts with no consumption in the period are reported as unranked rather than as class C, because "used but cheap" and "not used at all" are different findings. Only available where stock is kept on the movement ledger. Examples: "which parts matter most"; "run an ABC analysis on my stock"; "what are my class A parts this year"

inventory.read.abc_analysis

Today's attendance for the business — how many employees are marked present, absent, on leave, half day, week off, holiday or incomplete. Today only; employees with no mark today are not counted. Examples: "who is present today"; "show attendance summary"

hr.read.attendance_summary

Balance sheet summary — total assets, liabilities, equity, and whether assets equal liabilities plus equity, as of today. Examples: "show the balance sheet"; "what are our total assets and liabilities"; "does the balance sheet balance"

finance.read.balance_sheet

Current cash and bank account balances for the tenant. Examples: "what is our cash balance"; "how much money do we have in the bank"; "show cash and bank balance"

finance.read.cashbank_balance

Cash flow over a period — operating, investing and financing totals, net flow, and opening to closing balance. Supports named periods or a custom date range. Examples: "show the cash flow statement"; "what was our cash flow last quarter"; "cash flow for the last 90 days"

finance.read.cashflow_statement

Total number of customers in the tenant CRM — counts the Customer master directly, NOT converted leads. A lead marked Converted is not guaranteed to have a Customer document (a customer can also be created with no originating lead); use crm.read.lead_pipeline for lead-stage counts. A count of 0 here does not mean the CRM has no sales activity. Examples: "how many customers do we have"

crm.read.customer_count

Customer segmentation by Recency and Frequency of bookings: how many customers are VIP (repeat + booked recently), new/recent, at-risk (no booking in 181–730 days), or lost (no booking in over 2 years) — plus the repeat-customer rate and a combined churn-risk count/percentage. Monetary value (net ledger amount per segment) is included when the finance ledger composition is available, with an honest coverage percentage (thin today — real per-customer ledger attribution only began 2026-04-30); it declares monetaryBasis: null + a reason instead of a number when that composition is unavailable, rather than ever fabricating a figure. Examples: "how many of our customers are at risk of churning"; "who are our VIP customers"; "what is our repeat customer rate"; "show me customer segments"

crm.read.customer_intelligence

The day book — journal entries in chronological order over a period, each with its totals and a line preview. Paginated. Per-branch register. Examples: "show the day book"; "list journal entries this month"; "show the daybook for last quarter"

finance.read.day_book

Parts sitting in stock that have not moved for a long time, with how much money is tied up in them, largest first. Stock that has never moved at all is included. A line whose cost cannot be established counts as zero and is reported separately, so the total is a floor rather than a valuation. Branches whose stock records carry no last-movement date are reported as unmeasurable rather than as having no dead stock. Examples: "what stock is not moving"; "how much money is stuck in dead stock"; "show parts that have not sold in a year"

inventory.read.dead_stock

How many jobs/bookings are delayed — in an active stage but past their delivery date — for the tenant, plus the most-late job cards (booking number, customer, promised date, days late, status), most late first. Examples: "how many jobs are delayed"; "count of overdue jobs"

operations.read.jobs_delayed

Follow-ups due today and overdue for the business — counts, and optionally a list of each lead, its owner and when it is due. Filter by today, overdue or all; there is no date-range filter. Examples: "what follow-ups are due"; "show overdue follow-ups"

crm.read.followup_due

A composed executive snapshot: this month's revenue/expense/net-profit (with margin reliability), total lead count, customer churn-risk count, follow-up coverage percentage, and delayed job count. Every figure is pulled from an already-certified individual tool (finance.read.pl_summary, crm.read.lead_pipeline, crm.read.customer_intelligence, crm.read.followup_sla, operations.read.jobs_delayed) — nothing is re-derived. A section that could not be computed is reported as unavailable with a reason, never silently dropped. Examples: "give me an executive summary"; "show me the business dashboard"; "how are we doing overall this month"

exec.read.kpi_dashboard

Total and count of EXPENSE VOUCHERS for the tenant over a period, with a per-category split. This is NOT the tenant's total spend: costs posted as journal entries or purchase bills never pass through the voucher module, and many tenants record every cost that way. Each response declares its sourceBasis and reconciles against the general ledger, so a voucher total of zero is reported as "no vouchers" alongside the ledger figure — never as "no expenses". For total cost of doing business, use finance.read.pl_summary. Examples: "how much did we spend this month"; "show total expenses this quarter"; "expense summary for the year"

finance.read.expense_summary

Follow-up SLA COVERAGE across the live lead pipeline — how many live leads have any next action scheduled, how many have none, the coverage percentage, how much of what IS scheduled is overdue or due today, which statuses the untracked leads sit in, and how long the oldest untracked lead has been open. Use this to interpret crm.read.followup_due: that tool counts follow-ups that EXIST, so when coverage is low its "0 due today" reports what is tracked, not what needs doing. A live lead is one whose status is not in the tenant's terminal-status catalogue (the same authority that governs closing a lead); leads with no status recorded count as live. Examples: "how many leads have no follow-up scheduled"; "what is our follow-up coverage"; "are we actually working the pipeline"

crm.read.followup_sla

GST position over a period — output tax collected, input tax credit, and the net GST liability (payable or refund). Supports named periods or a custom date range. Examples: "show GST payable this month"; "how much GST do we owe"; "what is our net GST liability this quarter"

finance.read.gst_summary

Insurance claim book — open claims, what each is worth, and how much insurers still owe. A claim is a job card flagged as an insurance claim; cancelled and rejected jobs are excluded. Each claim is NOT BILLED until an Insurance invoice exists, AWAITING PAYOUT while that invoice carries a balance, and SETTLED when it does not — the same ledger the receivables position is read from, so the two can never disagree about the same rupee. A claim with no invoice yet carries NO amount rather than an estimate. Filter by state or insurer. At GROUP scope claim counts are additive but every branch is listed, because "14 open" is not actionable until you know where. Examples: "show insurance claims"; "how much do insurers owe us"; "which claims are still awaiting payout"

operations.read.insurance_claims

Count of leads in the tenant CRM, optionally filtered by status or source. With no filter it returns the total number of leads in scope. Examples: "how many lost leads"; "how many leads from JustDial"; "count of converted leads"

crm.read.lead_count

Why leads are being lost: the distribution of loss reasons across leads closed as lost or duplicate, canonicalized into a fixed set (price, bought_elsewhere, not_reachable, not_interested, duplicate, wrong_number, service_unavailable, other, unspecified). IMPORTANT: loss reasons are captured inconsistently — `coveragePercent` states what share of terminated leads resolve to a known reason, and the shares are of ALL terminated leads, not only those with a reason. Do NOT present this distribution as the reason the business loses leads without also reporting coveragePercent. Some reasons are derived from the lead's own status label rather than a recorded reason; `reasonBasis` on each row says which. Examples: "why are we losing leads"; "lead loss reasons"; "why do leads drop off"; "reasons leads are lost"

crm.read.lead_loss_reasons

Lead pipeline overview for the tenant — COUNT by stage only (New, Follow-Up, Won, etc), each stage declared OPEN / WON / CLOSED / UNCLASSIFIED so a caller never has to decide for itself which stages still mean work. Does not include deal/opportunity value — Autroid does not currently capture an estimated value on a lead. Supports optional period filter. Examples: "show the lead pipeline"; "how many leads this quarter"; "lead status breakdown"

crm.read.lead_pipeline

Enumerate the distinct lead source labels that actually exist in this tenant's CRM data, with a count and percentage share for each. Use this BEFORE crm.read.lead_count(source=...) to discover the real source strings — a guessed source string that doesn't exist returns a confident 0, not an error. Examples: "lead sources"; "where do our leads come from"; "source breakdown"; "lead channels"

crm.read.lead_sources

How many leave requests are pending approval for the tenant (the approval backlog). Does NOT report who is on leave today — that is attendance-derived. Examples: "how many leave requests are pending"; "pending leave approvals"; "leave approval backlog"

hr.read.leaves_summary

Reports how many of the platform's registered tools are visible to this credential, and — for every tool that is NOT visible — which stage dropped it (not exposed to MCP, plan/entitlement, RBAC, or GROUP/BRANCH scope) and why. Answers "what can you do?" honestly instead of a silently short tools/list. Examples: "what tools can you use"; "what can you do"; "why can't you see the Google Ads tools"

mcp.read.capabilities

What to do next, from one ladder: add a customer, create a lead, clear delayed jobs, review follow-ups due, give open leads a next step, else keep going. Returns the first step that applies plus the counts behind it (customers, leads, delayed jobs, follow-ups due, leads with no next action). At group scope each branch gets its own step. Examples: "what should I do next"; "show my next action"

operations.read.guidance_next

Profit and loss summary for the tenant. Supports optional period filter. Examples: "show this month's profit and loss"; "what was our net profit last quarter"; "revenue vs expenses this year"

finance.read.pl_summary

Ledger statement for a specific party (customer or vendor). Shows transactions and running balance. Examples: "show the ledger for Rahul Motors"; "what is the balance of 9876543210"; "statement for vendor Acme"

finance.read.party_statement

Outstanding vendor payables broken down BY VENDOR — who is owed, how much, how many bills, how much is overdue, and how much has no due date on record. Ranked by outstanding balance and TRUNCATED to the requested limit: the response publishes vendorCount and totalOutstanding for the whole ledger alongside listedOutstanding for the returned rows, so a ranking is never mistaken for the full payables list. Bills with no vendor recorded are reported separately as unattributedOutstanding, not silently dropped. Uses the same AP definition as finance.read.payables_summary, so the two always reconcile. Examples: "which vendors do we owe the most"; "show payables by vendor"; "who are our biggest suppliers by outstanding balance"

finance.read.vendor_payables

Summary of outstanding payables for the tenant — total amount due, overdue amount, and open-bill count. Aggregate totals only (no per-vendor breakdown). IMPORTANT: `overdueCount` structurally excludes bills with no due date on record (dueDate < today can never match null) — those bills are UNKNOWN, not confirmed current. `billsWithNoDueDateCount`/`overdueBasis` disclose that population; a low overdueCount alongside a nonzero billsWithNoDueDateCount does NOT mean the payables are healthy. ALSO IMPORTANT: for a tenant that migrated its books from another system, part of the outstanding total can be bills that were settled in that previous system without the payment being carried across. `cutoverBasis`/`preCutoverAmount` disclose that portion when a migration cutover has been declared; `cutoverBasis: NOT_DECLARED` means the portion is UNKNOWN, not zero. Examples: "how much do we owe vendors"; "show outstanding payables"; "what bills are overdue"

finance.read.payables_summary

Summary of payments received by the tenant. Supports optional period filter. Examples: "how much did we collect this month"; "payments received this quarter"

sales.read.payment_summary

Totals of the most recent finalized or paid payroll run — period, net payable, gross pay, deductions and number of employees. Says so when no payroll has been finalized yet; runs still in draft are not included. Examples: "show payroll summary"; "what was the salary cost in the last payroll"

hr.read.payroll_summary

Summary of outstanding receivables for the tenant — total due, overdue, and aging breakdown. Each bill is counted once: a counter sale's tax-invoice copy is not counted beside the sale that carries its payments. Older counter-sale bill copies whose sale is not in the current books are included but named separately (unresolvedHistoricalExposure), never certified as owed. Examples: "how much money do customers owe us"; "show outstanding receivables"; "what is overdue from customers"

finance.read.receivables_summary

Parts that have fallen to or below the reorder level someone set for them, most urgent first, with how many units short they are. Always reports how many in-stock products have no reorder level at all, because a part with no level cannot raise an alert and its silence must never read as sufficiency. Separately and clearly labelled as advisory, also lists parts with no level whose measured demand exhausts them within the tenant's own configured cover threshold. Examples: "what parts need reordering"; "which parts are below their reorder level"; "what am I about to run out of"

inventory.read.reorder_alerts

Customer concentration of billed sales for a period — the largest customer's share, the top-N share, the Herfindahl-Hirschman Index over customer shares, and how few customers account for half the revenue. Answers customer-dependency risk, which a revenue total cannot express. Revenue = issued job-card invoices + issued counter-sale invoices, each bill counted once; amounts (`total`) are gross INCLUDING GST and `taxable` is before GST (by the same tax rule the books use; bills with no tax detail are reported separately by sales.read.revenue_summary). Shares are computed against ATTRIBUTED revenue only: bills with no customer on record are reported separately as unattributedRevenue rather than dropped (which would inflate every share) or pooled into one synthetic customer (which would invent a concentration risk). The HHI here is over one tenant's customer shares in one window — it is NOT a market-concentration figure and must not be compared to industry HHI thresholds. Same basis as sales.read.revenue_summary (ISSUED_INVOICES), which also shows the books' recognised revenue (`ledgerRevenue`) with a bill-by-bill `ledgerBridge`; for recognised revenue alone use finance.read.pl_summary. Examples: "how dependent are we on our biggest customer"; "what share of revenue comes from the top 5 customers"; "customer concentration risk this year"

sales.read.revenue_concentration

Org-scoped BILLED SALES headline for a period (default month; any preset finance.read.pl_summary accepts, or a custom start/end). Revenue = issued job-card invoices + issued counter-sale invoices, each bill counted once. `total` is gross INCLUDING GST; `taxable` is before GST (by the same tax rule the books use); bills with no tax detail are reported separately. Split into job cards and counter sales. The books' recognised revenue (`ledgerRevenue`) is shown beside it with a bill-by-bill `ledgerBridge` (summary only); for recognised revenue alone use finance.read.pl_summary. Every response declares sourceBasis (ISSUED_INVOICES). Examples: "show revenue this month"; "what were today's sales"

sales.read.revenue_summary

Billed sales as a time series — per day, week, or month — with invoice count and AVERAGE TICKET SIZE for each bucket and for the period overall. Revenue = issued job-card invoices + issued counter-sale invoices, each bill counted once. `total` (and each bucket's `total`) is gross INCLUDING GST; `taxable` is before GST (by the same tax rule the books use); bills with no tax detail are reported separately. Answers whether revenue is rising or falling and whether a change came from volume or from ticket size, neither of which a single-figure summary can distinguish. Same basis as sales.read.revenue_summary (ISSUED_INVOICES), which also shows the books' recognised revenue (`ledgerRevenue`) with a bill-by-bill `ledgerBridge`; for recognised revenue alone use finance.read.pl_summary. Average ticket is always derived from a bucket's own total and count, never averaged across buckets. Bucket count is bounded; the response declares `truncated` rather than returning a partial series that looks complete. Examples: "show revenue by month this year"; "is revenue growing"; "what is our average ticket size this quarter"; "daily sales for last month"

sales.read.revenue_trend

Parts catalogue by category — how many SKUs and how much stock value sit in each category, ranked by value or by SKU count. Answers "how is the catalogue organised and where is the money sitting", which neither the stock list nor the inventory KPI summary can. Lines carrying NO category are reported separately as uncategorised rather than excluded, so the SKU count and value always add up to the whole catalogue; on most books the uncategorised share is the majority. TRUNCATED to the requested limit: categoryCount and totalValue describe the whole catalogue while listedValue covers only the returned categories. Unit cost falls back moving-average → purchase price → sell price, and the response declares that basis. At GROUP scope categories are NOT combined — stock is physically held by one branch. Examples: "show stock by category"; "which parts category holds the most money"; "how many categories do we stock"

inventory.read.category_summary