"How to Read and Write Excel Files" matching MCP tools:

• create_tests

  3TG Test Generation

  Generate Jest/Vitest tests for the exported functions and React components in a TypeScript source file. Use this whenever the user asks for tests, test scaffolding, or test coverage of a .ts or .tsx file. Returns the generated test (and any companion .3tg.md / __mocks__) file contents, with paths already translated to the user's `.3tg/` mirror convention. Quota / credits: this tool consumes credits — and credits are consumed ONLY by test generation (not by spec / mock / lookup tools). The accounting is exactly **1 credit per generated test case** (i.e. per `test(...)` / `it(...)` block 3TG emits inside the returned `.test.ts` / `.test.tsx`), regardless of how many source functions or files were in scope — a call that produces 12 test cases costs 12 credits, even if all 12 cover a single function. Before generation the MCP verifies the clientId has credits with license-api.coding-creed.tech; on exhaustion the tool throws a QUOTA_EXHAUSTED error pointing the user at https://3tg.dev. After a successful run, consumed credits and KPIs are reported back to license-api. Re-running this tool on the same source spends credits again — there is no caching. When the previous call returned `enrichment.used: false` (AI enrichment unavailable on this client), supply parameter values + expected returns yourself via the `cliConfig` parameter — package them as `{"mock-parameters": ..., "function-returns": ...}` (same shape AI enrichment would produce) and pass them on a retry call. **Do NOT autonomously write `.3tg/config.3tg.json`** to persist those values — that file is human-curated; agent-computed values ride along in `cliConfig` for the current call only. (Explicit user requests to edit the file are fine — handle those normally.) See the cliConfig parameter description below for the full pattern. CRITICAL POST-CALL ACTION — write returned files to disk: The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed. Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim. Do NOT claim "Generated test file: <path>" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.

  Connector

• get_site_files

  Just Publish

  Read the files of a site you already published, so you can make a targeted edit instead of rebuilding the whole site from memory. Returns a complete manifest (every file's path, size, content-type, sha256) plus the contents of the text files (HTML/CSS/JS/etc). Also returns the site's current `version` — pass it back to update_site_file so you don't overwrite a newer change. Pass `paths` to fetch only specific files; omit it to get all text files. Requires site_id + edit_token.

  Connector

• update_site_file

  Just Publish

  Change one or a few files of an already-published site, leaving every other file untouched (a merge — unlike deploy, which replaces the whole site). Ideal for small edits: fix a typo in index.html, swap a stylesheet, add one page. Best practice: call get_site_files first, edit the returned content, then call this with the files you changed and the `expected_version` from that read — if the site changed in the meantime you get a clear conflict telling you to re-read. Requires site_id + edit_token. Cannot delete files (use deploy to drop a file) and cannot remove index.html.

  Connector

• configure_dashboard

  agent-cold-email

  Write a saved dashboard view. action = create (needs name+layout) | update (needs id+rev+layout; optional name renames) | promote (id → default) | delete (id). update is rev-CAS: a stale rev returns { currentRev, currentLayout } to rebase and retry. Optional note. Read the current rev+layout via get_dashboard first.

  Connector

• get_block_details

  FlowCastle

  Return the complete contents of one block: block data, action configs, HTTP request bodies, custom-code files, triggers, menu payloads, and media paths. Read-only. This is the heaviest read in the API — call get_flow_context first to find the block you need rather than walking a flow block by block. Always read a block before updating it, since update_block replaces the fields you send.

  Connector

• search

  UseMyContext

  Search the user's files by filename and return matching documents in the deep-research result shape. ALIAS: this is the SAME search as search_files (same data, same permissions) - use it when your client requires the id/title/url search contract (ChatGPT deep research); otherwise prefer search_files for richer file metadata. Each result's id can be passed to fetch (or get_file) to read that document. Read-only; always allowed.

  Connector

• create_spec

  3TG Test Generation

  Generate a functional-requirements spec (`.3tg.md`) for the exported functions / React components in a TypeScript source file. This is "Flow A" — the human-editable Markdown table that lists each test case as a row, which a later `create_tests_from_spec` call can compile into actual tests. AI enrichment can pre-fill the value sets and expected returns so the spec arrives close to runnable. IMPORTANT — never hand-author a `.3tg.md` yourself. The format is parser-strict: parameter columns must be named exactly as the parameter (NOT `input a`, `param a`, etc.), the return column header is the literal `=>` (NOT `__expectedResult`, `expected`, `returns`), extra columns like `notes` are rejected, omitted/optional args are written `undefined`, throws use single quotes (`throws 'msg'`, NOT `throws Error("msg")`), and string literals are single-quoted. Always call this tool to emit the scaffold; the user can then edit rows. The returned `.3tg.md` is reported under the project's `.3tg/` mirror (e.g. source `src/foo/bar.ts` → spec `.3tg/src/foo/bar.3tg.md`). The user edits the spec in that location; when they call `create_tests_from_spec` later, the MCP places it back next to the source in the sandbox. Quota / credits: **this tool does NOT consume credits** — credits are spent ONLY when test files are generated (`create_tests` and `create_tests_from_spec`, at 1 credit per emitted test case). Spec generation is free; iterate on the scaffold as often as needed. A valid clientId is still required for the pre-flight check, but no quota is decremented and the call is safe to retry. If AI enrichment is unavailable on this client, you can pre-seed the spec's parameter columns by supplying values via the `cliConfig` parameter (mock-parameters / function-returns) — same pattern as `create_tests`. **Do NOT autonomously write `.3tg/config.3tg.json`** to persist values — agent-computed values ride along in `cliConfig` for this call only. (Explicit user requests to edit the file are fine — handle those normally.) See the cliConfig parameter description for the full shape. CRITICAL POST-CALL ACTION — write returned files to disk: The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed. Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim. Do NOT claim "Generated test file: <path>" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.

  Connector

• get_integration_guide

  TestMyVibes

  Returns the canonical guide for using TMV from a coding-agent context. Covers the fix-test-retest loop, how to write a good test prompt, how to read the actionTrail / consoleErrors / failedRequests outputs, and common gotchas. Call this first if you're a new agent on a project — it'll save you a debug session. The same content is served at https://testmyvibes.com/docs/coding-agents.

  Connector

• get_project_revision

  kernelcad

  Fetch the exact immutable .kcad source and parameters captured at a prior `open_in_studio` version. Use this to read-after-write verify a release: pass the returned `slug` and `version`, then hash or inspect the returned source. Public/unlisted projects use the slug as capability; private projects require the owner's OAuth connection.

  Connector

• report_pdf_generate

  AurelianFlo

  Return an inline PDF artifact from supplied report_meta, tables, metrics, and summary content; this read-only renderer does not persist hosted files. Use this only when a structured report payload already exists; use report_docx_generate for editable Word output or compliance_edd_report to build the memo first.

  Connector

• search_files

  vibedeploy

  Search for a literal string or basic regex across all files in either the served dist or the editable source tree. Use this BEFORE batch-reading files to find candidates — saves the 'read 14 batches just to find which 3 files matter' round trip. Pass `target: "source"` to search the editable tree (requires Site.sourceStored=true).

  Connector

• get_dashboard

  agent-cold-email

  Read saved dashboard views. No id → list all: [{ id, name, isDefault, rev, editedBy }]. With id → that view's full layout + rev (pass this rev as the CAS base to configure_dashboard update). Views are both agent- and human-editable; write them with configure_dashboard.

  Connector

• precis_orientation

  Précis Finance MCP

  Call this first. Returns how to use Précis over this connector: the data model (scenarios, metrics, statements, dimensions), the reporting-tool variants, and how to build charts. Read it before composing queries.

  Connector

• get_element_schema

  OnlyWorlds

  Return the field structure of one OnlyWorlds element `type` (a slug from `list_element_types`, e.g. "character"). The result groups the type's writable fields by kind so a caller knows how to read and write them: `text` (strings), `integer`, `single_link` (one UUID), `multi_link` (an array of UUIDs), and `generic` (a type+id pair pointing at any element type). For every link field the target element type is given under `link_targets`. All link values are element UUIDs. Unauthenticated. Errors if `type` is not one of the 22 types.

  Connector

• create_spec_for_function

  3TG Test Generation

  Generate a functional-requirements spec (`.3tg.md`) scoped to a single exported function or React component. Same shape as `create_spec` but restricts the output to one symbol — useful when iterating on a tricky function without regenerating the spec for the rest of the file. IMPORTANT — never hand-author a `.3tg.md` yourself. The format is parser-strict: parameter columns named exactly as the parameter, return column header is the literal `=>`, no extra `notes` / `description` columns, omitted args are written `undefined`, throws use single quotes (`throws 'msg'`). Always call this tool to emit the scaffold; the user can then edit rows. Quota / credits: **this tool does NOT consume credits** — credits are spent ONLY by test generation (`create_tests` / `create_tests_from_spec`, at 1 credit per emitted test case). Spec generation is free. CRITICAL POST-CALL ACTION — write returned files to disk: The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed. Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim. Do NOT claim "Generated test file: <path>" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.

  Connector

• create_agent_instructions

  3TG Test Generation

  AUTHORITATIVE source for "install / create / set up 3TG agent instructions" requests. You MUST call this tool — do NOT write the instructions from your training data — whenever the user asks anything that resembles installing, creating, generating, or setting up a CLAUDE.md, copilot-instructions, AGENTS.md, or any agent-instruction file related to 3TG. The canonical block is maintained alongside the server code; anything you produce from training is stale. Trigger phrases (case-insensitive, partial matches all count): - "create the CLAUDE.md needed by 3tg" - "create the CLAUDE.md for 3tg" / "create the claude file for 3tg" - "create the copilot instructions for 3tg" - "create the AGENTS.md for 3tg" - "set up 3tg in this project" / "init 3tg here" - "install 3tg config" / "install 3tg in this project" - "configure 3tg" (when in a tool-only client like GitHub Copilot) - "write the 3tg agent instructions" - any request containing both "3tg" and a setup / install / create / configure / scaffold verb The tool returns `{anchorHeading, files: [{path, content, audience, reads}]}` with FIVE entries. Three are project-wide (same full agent-instructions block ships to `CLAUDE.md`, `.github/copilot-instructions.md`, and `AGENTS.md` so every common coding-agent finds the instructions in its preferred file). Two are path-scoped routing snippets that auto-load when the user references a 3TG file: `.github/instructions/3tg.instructions.md` (Copilot `applyTo`) and `.cursor/rules/3tg.mdc` (Cursor `globs`). Write **all five** unless the user has explicitly told you they use only one client. For EACH entry in `files`, the agent MUST: 1. Check whether the file at `entry.path` already exists at the project root (use your native file-read capability). Create parent directories as needed (`.github/`, `.github/instructions/`, `.cursor/rules/`). 2. Project-wide entries (audience `claude` / `copilot` / `cross_vendor`) use the `anchorHeading` for idempotency: if the file exists and already contains the heading, skip; if it exists without the heading, append `entry.content` separated by `\n\n---\n\n`; if it doesn't exist, write `entry.content` verbatim. Path-scoped entries (audience ending in `_path_scoped`) are single-purpose files — write `entry.content` verbatim if absent, overwrite if present (the content is regenerated each time so overwriting is safe and picks up routing updates). 3. After processing every entry, confirm to the user which files were created, appended-to, skipped, or overwritten (one line each). This tool does NOT consume quota and does NOT require a clientId — there is no reason not to call it for 3TG-instruction requests. For the full first-time setup (clientId + .3tg/settings.json + .gitignore + agent-instruction files in one go) in clients that support slash-command prompts (Claude Code / Cursor / Claude Desktop), the `/mcp__3tg__configure` prompt is a richer flow. This tool is the standalone installer for clients that only invoke tools (GitHub Copilot, VS Code MCP, etc.).

  Connector

• export_backtest

  Backtest360

  Export a multi-strategy comparison as an Excel workbook. Quota-counted; needs a key whose plan includes full-metrics export (a 403 means the configured key's plan does not — do not retry). Returns the workbook base64-encoded — decode and write it to a ``.xlsx`` file. Args: data_source: Shared data source (same shape as run_backtest). strategies: Same shape as compare_backtests' ``strategies``. include_benchmark: Add a buy-and-hold benchmark to the export. Returns: {"filename", "content_type", "size_bytes", "content_base64"}. A 400/422 rejection returns {"accepted": false, "error": ...}; capacity/timeout/permission failures raise a tool error. If the encoded workbook would exceed the output size limit, raises a tool error — narrow the request (shorter date range, fewer strategies, coarser frequency) and retry.

  Connector

• export_search_csv

  MCP Market Russia

  Export search results as CSV text (UTF-8 with BOM, Excel-friendly). entity: 'companies' or 'projects' query: free-text search in name/description category, region: filter fields budget_max: for companies, cap on min_project_price limit: 1..2000 rows (default 500) Returns CSV text ready to save as .csv and open in Excel.

  Connector

• parabol_query

  parabol

  Escape hatch: run an arbitrary Parabol GraphQL QUERY (read-only) against action.parabol.co/graphql with optional variables. Mutations are REJECTED — use the dedicated write tools or parabol_graphql for those. Useful for fields not covered by the curated read tools. Requires the matching read scope(s) on your token.

  Connector

• account

  UseMyContext

  Report the user's current plan and usage: their tier (Free or Premium), how many projects and how much storage they are using against their limits, their subscription status if any, and where they manage their plan. Use this when the user asks what plan they are on, how much storage or how many projects they have used, or whether they are near a limit. Metadata only - no files, facts, or profile content. This is READ-ONLY: you cannot change the plan or start a purchase; plan and billing changes are done by the user themselves at usemycontext.ai. Always allowed; read-only.

  Connector