Check Credits
/check-creditsCheck your remaining SyncGTM credit balance in one free call, then price any batch before you run it and confirm what it actually cost.
Overview
check_credits is the free SyncGTM MCP tool that returns your remaining credit balance as a single credits_remaining figure. It takes no parameters and never changes your balance, so you can call it as often as you like. This agent wraps it with the arithmetic reps actually need: forecast a batch against the published per-call costs, confirm the balance covers it, then re-check after the run to report real spend.
What it does
- 1
Takes no input. check_credits accepts no parameters, so there is no filter value to spell exactly and nothing to configure.
- 2
Returns one field, credits_remaining — the credits left on your SyncGTM account at the moment of the call.
- 3
Prices a planned batch before you run it: rows multiplied by the per-lookup cost, or the capped result count multiplied by the per-result cost, checked against your live balance.
- 4
Brackets a run with a balance check either side, then reports before, after, delta and cost per row, so a workflow's price stops being a guess.
- 5
Does not return usage history, a per-tool spend breakdown, invoices, or plan and seat details. It returns the current balance only — a breakdown has to be reconstructed from bracketed deltas.
- 6
Free. Calling it costs nothing and never moves your balance.
How to use it
- 1
Download the skill file — it saves as check-credits.zip.
- 2
In Claude, open Settings → Capabilities → Skills and upload the .zip (or unzip the check-credits/ folder into .claude/skills/ for Claude Code).
- 3
Connect the SyncGTM MCP server first if you have not already — browser sign-in, no API key. Ask 'How many SyncGTM credits do I have left?' and a number coming back confirms auth and tool routing both work.
- 4
Type /check-credits for a plain balance, or name the batch you are about to run — 'check credits, then tell me if 40 find_mobile_number lookups at 12 credits each fit' — to get the forecast before you spend.
- 5
Make bracketing the default habit: tell the agent to check the balance before and after every paid run and report the delta as the cost. The delta is the only figure that matches the invoice.
Use cases
Pre-flight a large batch
Price a 300-row enrichment against your balance before the first call. Stops a campaign dying half way down the list with no credits left.
Cost a new workflow
Bracket a 10-row test with a balance check either side to get the true per-row cost, then extrapolate to the full list before committing.
Weekly credit reporting
Log the balance at the same time each week so RevOps can see burn rate, cost per meeting, and when the next top-up is due.
Debug a silent tool call
A run that leaves the balance unchanged never fired the tool — the model answered from memory. The before and after figures prove it.
GTM workflow examples
Price a mobile-number push before you run it
- 1`check_credits` — free, no arguments. Record the opening balance, say 4,820.
- 2`find_people` with `limit` 40, `current_titles` "Head of Revenue Operations" and `current_company_headcount_ranges` "201-500". 40 results × 0.3 = 12 credits for the list.
- 3Do the arithmetic before spending: 40 lookups on `find_mobile_number` at 12 credits each is 480 credits, charged whether or not a number comes back. Confirm the remaining 4,808 covers it, or cut to the 20 highest-fit rows and re-price at 240.
- 4`find_mobile_number` on the approved rows only, then `check_credits` again to close the bracket.
Outcome: A dialing list plus a written cost line — 492 credits, 12.3 per row attempted, and a true cost per number once the empty rows are counted out — that you can put in front of a manager before the next batch is approved.
Cost a new account-research workflow on 10 rows first
- 1`check_credits` — record the opening balance before anything runs.
- 2Run the full chain on 10 accounts only: `enrich_organization` at 2 credits per domain, `find_people_within_company` at 1.5 flat per call (same price whether it returns 5 profiles or 50), `find_work_email` on one contact per account at 1 credit. That is 4.5 per account.
- 3`check_credits` again. The delta divided by 10 is the true per-account cost, including the chain steps you forgot were in there — 4.5 credits, or 45 for the test.
- 4Multiply by the full 400-account list (1,800 credits) and compare that against the `check_credits` balance from step 1 before scaling.
Outcome: A verified per-account cost and a documented go/no-go on the 400-account run, decided for 45 credits instead of discovered at 1,800.
Weekly credit burn report for RevOps
- 1`check_credits` every Monday at the same hour. Log date and balance in a sheet.
- 2Subtract last week's figure for the week's burn, then attribute it against your run log — `find_people` list builds at 0.3 per result returned, `find_work_email` enrichment at 1 per lookup, `find_mobile_number` dialing lists at 12 per lookup, misses included.
- 3Divide the week's `check_credits` delta by meetings booked that week to get credits per meeting, the number that decides next quarter's plan size.
- 4When the `check_credits` balance drops below four weeks of average burn, raise the top-up before a campaign stalls mid-run.
Outcome: A four-column burn sheet — date, balance, weekly spend, credits per meeting — that turns the credit line into a forecastable number instead of a surprise.
Prompts
Paste any of these into Claude once the skill is installed and the SyncGTM MCP is connected.
How many SyncGTM credits do I have left?Check my SyncGTM credits, then tell me whether 40 find_mobile_number lookups at 12 credits each fit in the balance.Check my credits, then run find_people with limit 25 for current_titles "Head of Revenue Operations" and current_company_headcount_ranges "201-500", find work emails for those 25, check credits again, and report total spend, cost per row and cost per email actually found.Check my credits and give me a table of how many lookups today's balance buys me with find_work_email at 1 credit, find_personal_email at 3 and find_mobile_number at 12.Check my credits, run find_work_email on these 30 LinkedIn URLs, check credits again, then report the delta, the cost per row, and how many more 30-row runs the remaining balance covers.Best practices
Call it before and after anything new. One balance tells you where you are; a pair tells you what a workflow costs.
Bracket at 10 rows, not 400. Get the per-row cost from a small run, extrapolate, then decide on the full list.
`find_people` and `find_companies` bill 0.3 credits per result, not per call. `limit` defaults to 25 (7.5 credits), tops out at 100 per call (30 credits), and every extra page fetched with `cursor` bills again — state the limit in the prompt.
`find_mobile_number` and `find_work_phone` are 12 credits per lookup, the priciest calls on the server, and they charge whether or not a number comes back. A careless 100-row phone run is 1,200 credits at any hit rate.
When a forecast is over budget, swap for a cheaper sibling before cutting the list: `enrich_linkedin_page` is 0.5 against 3 for `premium_linkedin_page_insights`, `find_company_website_traffic` is 1 against 2 for `semrush_insights`, and `find_people_within_company` is 1.5 flat per call against `find_people` at 0.3 per result once you already know the company.
A zero delta after a paid run means no tool fired — the model answered from memory. Name the tool explicitly in the prompt and retry once before you report a cost.