mcpField
F
fieldscribe

fieldscribe

Local
github.com/CloudCorpRecordsMedia & Design0Updated 1w ago

About fieldscribe

fieldscribe is a local bridge to FieldTranscript for transcribing public audio and video URLs. It submits background jobs, tracks their status, and retrieves transcripts as text or SRT.

Key features

  1. 01Submit public audio or video URLs
  2. 02Run transcription jobs in the background
  3. 03Check job status and metadata
  4. 04Retrieve completed transcripts
  5. 05List or delete transcription jobs

Use cases

  1. 01Transcribe a public video or podcast
  2. 02Check progress of a transcription
  3. 03Retrieve a completed transcript as SRT
  4. 04Remove a finished job and its stored text

MCP support

Acts as a local MCP server that forwards transcription and job-management calls to FieldTranscript's hosted MCP server. MCP clients can submit jobs, check status, list jobs, retrieve transcripts, and delete finished jobs.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"cloudcorprecords-fieldscribe": {
"command": "npx",
"args": [
"-y",
"@reneturcios/fieldscribe"
]
}
}
}
Run commandnpx -y @reneturcios/fieldscribe

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
npm@reneturcios/fieldscribe0.1.0
ocighcr.io/cloudcorprecords/fieldscribe:0.1.0

Tools

4

Saved tool list · updated 1w ago

ParameterTypeRequiredDescription
urlstringYesThe public video or audio URL (YouTube etc.) to transcribe.

Details

From the project README

fieldscribe

fieldscribe is a small local bridge to FieldTranscript's hosted MCP server, a transcription service that turns public audio and video files into text. You hand it a URL — a YouTube video, a podcast episode, a lecture recording — and it runs the transcription as a job in the background: submitting returns a job id immediately, the job takes roughly one to ten minutes, and polling the job eventually yields the finished transcript as clean text or SRT, depending on what the upstream returns.

The bridge keeps no transcripts and no job state of its own. It serves the upstream server's tool list locally, exactly as captured from the live endpoint, and forwards each tool call upstream, returning the result untouched. One tool in the captured surface deletes — delete_job permanently removes a finished job and its stored text — and one creates work: submit_transcription starts a new transcription job on the caller's account. Everything else reads.

Tools

  • submit_transcription — submit a public video or audio URL (YouTube etc.) for verbatim transcription. Returns a job_id immediately. Required: url. Transcription takes about 1-10 minutes; poll get_job every 30-60 seconds until the status is done. Not for private or internal URLs.
  • get_job — check one transcription job: its status (queued, working, done or error) and metadata. Required: job_id. Optional: include_transcript (default false) — set it only once the status is done and the full text is actually needed, because transcripts of long videos are large.
  • list_jobs — list all transcription jobs on your account, newest first. No arguments.
  • delete_job — permanently delete a finished (done or errored) transcription job and its stored text. Required: job_id. Refused while the job is queued or running, and it cannot be undone.

Configuration

  • FIELDTRANSCRIPT_MCP_URL (optional) — override the upstream endpoint. Defaults to https://mcp.fieldtranscript.com/mcp. (The override hook is this rebuild's own labelled reconstruction.)
  • FIELDTRANSCRIPT_API_KEY (optional) — when set, every upstream request carries an Authorization: Bearer <key> header. When it is not set, no auth header is sent. (This forwarding is also a labelled reconstruction; the original surface was captured keyless.)
Forwarding mechanics

On the first tool call the client opens a streamable HTTP session with the upstream: a JSON-RPC initialize request (protocolVersion 2025-03-26, clientInfo name fieldscribe), then a notifications/initialized notification, then the tools/call request carrying the caller's arguments unchanged. When the upstream answers initialize with an Mcp-Session-Id header, that value rides on every later request of the session, which is reused for the life of the process. Replies may arrive as plain JSON or as server-sent events; both are read.

Successful upstream results pass through verbatim, including any isError flag the upstream sets. Failures — a JSON-RPC error, a non-2xx status, an unreadable response, or a request that cannot be completed — come back as an isError result whose text starts with fieldscribe error: (this rendering is this rebuild's own labelled reconstruction).

CLI

Each tool is also a subcommand taking one JSON argument string (omit it for tools that take none):

npx @reneturcios/fieldscribe submit_transcription '{"url":"https://www.youtube.com/watch?v=abc123"}'
npx @reneturcios/fieldscribe get_job '{"job_id":"job-7"}'
npx @reneturcios/fieldscribe get_job '{"job_id":"job-7","include_transcript":true}'
npx @reneturcios/fieldscribe list_jobs
npx @reneturcios/fieldscribe delete_job '{"job_id":"job-7"}'
npx @reneturcios/fieldscribe --version

Exit codes: 0 on success, 1 on an isError result, 2 on a usage error.

MCP server

npx -y @reneturcios/fieldscribe mcp

MCP client config:

{
  "mcpServers": {
    "fieldscribe": {
      "command": "npx",
      "args": ["-y", "@reneturcios/fieldscribe", "mcp"]
    }
  }
}

Docker

docker run -i ghcr.io/cloudcorprecords/fieldscribe
docker run --rm ghcr.io/cloudcorprecords/fieldscribe --version

The container's default command is mcp, so the first form is a stdio MCP server; any other arguments reach the CLI normally.

Development

npm install
npm run build
npm test
npm run dev

The test suite runs entirely against a stubbed JSON-RPC upstream — no live network calls.

License

MIT — see LICENSE.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.