Skip to main content
Glama
Hy1ander

NeuroDynamic Audio and LLM APIs

by Hy1ander
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

NeuroDynamic MCP client — 1.0.0

Connect an MCP-compatible agent to NeuroDynamic audio and LLM APIs.

Free by default. Discover services, compare seven voices and inspect prices without a wallet. Purchases are optional and explicitly enabled by the wallet owner.

What this release supports

Tool

What it does

Charge

catalogue

Read services, voices, schema or private-cloning requirements

Free

quote

Check the live price and payment details

Free

purchase_json

Generate catalogue narration or either LLM's text

Explicit purchase

transcribe_file

Upload and transcribe your audio

Explicit purchase

payment_status

Inspect an existing purchase; query LLM payment recovery

Free

budget_status

See the cumulative client spending cap

Free

Current purchases use native USDC on Base, x402 v2 exact, an EOA wallet. A future merchant network option will not silently change which network this client signs for. SOL-token payments, other chains, smart accounts and automatic bridging are not supported by this client release.

Private cloning is discoverable here; purchase/enrolment stays in the approved-account workflow. This adapter does not enrol voices, bypass consent review or hold cloning bearer credentials. The audio starter includes the separate workflow.

This runs locally on the requesting machine using stdio. It is not a hosted /mcp URL, and it does not open a port. No NeuroDynamic account is needed for catalogue narration, transcription or LLM purchases.

Related MCP server: solanaprox-mcp

Install

Python 3.10+ on Linux or macOS. Windows users can use WSL. The budget lock uses POSIX file locking.

Install the published package in a virtual environment:

python3 -m venv .venv
.venv/bin/pip install neurodynamic-mcp==1.0.0

Alternatively, from a checkout of this repository, use .venv/bin/pip install .. The included requirements.lock records the dependency versions tested for the original release; the package pins its direct dependencies in pyproject.toml.

Add this entry to your MCP application and replace the Python path:

{
  "mcpServers": {
    "neurodynamic": {
      "command": "/absolute/path/to/.venv/bin/python",
      "args": ["-m", "neurodynamic_mcp"]
    }
  }
}

Package: https://pypi.org/project/neurodynamic-mcp/1.0.0/

Official registry name: tech.neurodynamic/audio-llm.

Ask the agent: “List NeuroDynamic services and voices, then get a narration quote. Do not purchase anything.”

The adapter checks the live quote against reviewed merchant, native USDC token, network, amount and signing-domain values. Prices are introductory; if they change, the adapter stops for an update rather than accepting a higher price automatically.

Optional purchases

Use a dedicated low-balance Base wallet. Keep its raw hexadecimal private key in a file owned by the user running the client, with mode 0600; never paste it into an agent prompt or tool call. Wallet keys stay on your requesting machine.

Create a private state directory and, for transcription, a separate input directory. Both should be owned by that user. Audio input files must be mode 0600. Only place files intended for upload in the input directory.

Add owner-controlled env settings to the server configuration:

{
  "NEURODYNAMIC_BUYER_KEY_FILE": "/private/path/buyer.key",
  "NEURODYNAMIC_STATE": "/private/path/neurodynamic-purchases",
  "NEURODYNAMIC_INPUT_DIR": "/private/path/audio-to-upload",
  "NEURODYNAMIC_TOTAL_CAP_ATOMIC": "50000"
}

50000 is 0.05 USDC total, not per call or per day. The cap persists across restarts through the state ledger. This initial client limits its configured cap to at most 1 USDC. State files are the budget history: do not delete or replace them to resolve errors. A host with shell access can alter local files, so this is not a sandbox against a malicious local user or agent.

Each purchase also requires confirm_purchase: true in its tool arguments. The owner must authorise spending; a quote is not permission to spend.

Narration example:

{
  "service": "narration",
  "body": {"input": "Hello from NeuroDynamic.", "voice": "bf_emma"},
  "purchase_id": "my-first-narration",
  "confirm_purchase": true
}

One MP3, up to 1,000 characters: 0.005 USDC. Available voice IDs: Hazel af_heart, Bella af_bella, Emma bf_emma, Alice bf_alice, George bm_george, Michael am_michael, Ben am_fenrir.

Transcription: use transcribe_file with a filename inside your input directory, a new purchase ID, language: "en" and explicit confirmation. Up to 60 seconds/12 MiB, 0.01 USDC. An unpaid quote never reads or uploads audio.

LLM examples use service: "abliterated" (0.020 USDC) or "abliterated-large" (0.035 USDC). The body needs input, optionally max_tokens (16–512), and explicit adult: true, third_party_processing: true, terms_version: "2026-09-11-llm-v1". Only acknowledge these with the user's authority after reading https://api.neurodynamic.tech/llm. Input is limited to 2,000 UTF-8 bytes. Adults 18+, lawful use; generated content can be wrong.

Recovery and privacy

The adapter reserves budget and saves the signed proof before sending a paid request. It saves returned output locally with mode 0600 and records the receipt. It does not log prompts or private keys.

  • Repeating the same purchase ID returns its saved state; it does not sign or submit another payment.

  • The same ID with different input is rejected.

  • Failed or uncertain purchases keep their budget reservation. They are not automatically refunded or retried.

  • Use payment_status after uncertainty. Contact support with the request ID or transaction hash if needed. Do not send private keys, signed proofs or your state database to support.

  • LLM outputs are not retained by NeuroDynamic after processing. A lost LLM response cannot be recovered by paying again safely; payment status is available without another charge.

  • Transcription/narration recovery follows each API guide. This initial adapter does not automatically resend an uncertain paid request; preserve the state and original input for support-assisted recovery.

Your local state directory contains signed payment proofs, purchase metadata and returned files. Protect it like wallet material. Requests contain your chosen text/audio. Merchant operational metadata and service-specific retention are explained in the API guides. LLM requests go to third-party providers with separate retention policies; local server content-retention statements do not cover those providers or your client files.

Verification

.venv/bin/python -m unittest discover -s tests -v
.venv/bin/python tests/stdio_smoke.py

Unit tests use synthetic HTTP responses and an unfunded temporary signing key. The stdio smoke test performs only free live discovery/quotes and confirms purchases are disabled.

Release validation also completed three separately authorised operator purchases (narration, transcription and LLM), total 0.035 USDC, followed by no-charge duplicate and status checks. These are test activity, not customer sales.

Licence and scope

The connector code, tests, documentation and example client configuration in this repository are available under the MIT licence. You may use, modify and redistribute them, including commercially, while retaining the copyright and licence notice. Third-party dependencies retain their own licences.

This repository does not contain our private service deployment configuration, credentials, model weights, voice samples or customer data. The MIT licence does not grant free API access or rights to those separate assets. Use of the hosted APIs remains subject to their published prices, terms and privacy information.

Available Tools

6 tools
budget_statusA
Read-onlyIdempotent

Read the cumulative client budget. Uncertain purchases remain reserved across restarts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond that by noting that uncertain purchases remain reserved across restarts, which is a meaningful persistence behavior an agent should know. No contradiction with annotations.

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?

The description is two short sentences with no filler. The primary action and resource are front-loaded, and the additional behavioral note earns its place.

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?

For a zero-parameter, read-only tool with a rich annotation set and an output schema, the description is complete. It explains the core purpose and the one non-obvious persistence behavior, leaving no gaps for an agent to call it correctly.

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

Parameters4/5

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

The tool has zero parameters, so there is nothing for the description to explain about invocation arguments. The baseline score of 4 applies because no parameter documentation burden exists.

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?

The description states a specific verb ('Read'), a clear resource ('the cumulative client budget'), and the scope ('cumulative'). This distinguishes it from sibling tools like payment_status and quote by focusing on the budget rather than payments or item pricing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for checking the client's current budget state, but it does not explicitly say when to choose this over siblings like payment_status or quote. The usage context is reasonably clear, but no alternatives or exclusions are mentioned.

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

catalogueA
Read-onlyIdempotent

Read free services, voices, schema or cloning requirements. No wallet or payment needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNoservices

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

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

The description aligns with the readOnlyHint, idempotentHint, and destructiveHint=false annotations, and adds the useful behavioral detail that no wallet or payment is required. It does not disclose any further behavioral traits such as output shape or potential external dependencies, but annotations already cover the main safety profile.

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?

The description is two short sentences with no filler. The main capability is front-loaded in the first sentence, and the payment clarification in the second sentence is immediately useful without adding unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, an output schema, and strong annotations, the description covers the essential purpose and usage context. It could be more explicit about the 'kind' parameter values and the default, but nothing critical appears missing for an agent to invoke the tool correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the burden of explaining the 'kind' parameter. The phrase 'free services, voices, schema or cloning requirements' enumerates likely values for 'kind', providing meaningful semantics beyond the bare schema. It does not explicitly mention the default 'services' value or confirm exact accepted strings, but it is still clearly helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Read' and names concrete resources: 'free services, voices, schema or cloning requirements.' It clearly positions the tool as a read-only catalog, and the phrase 'No wallet or payment needed' helps distinguish it from the purchase and payment siblings, though it does not explicitly name 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 gives clear context for when to use the tool: to read free offerings without needing a wallet or payment. It does not explicitly state when not to use it or name alternative sibling tools, but the no-payment guidance implies it is the appropriate choice for browsing free resources.

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

payment_statusB
Read-onlyIdempotent

Read saved purchase metadata and, for LLMs, query payment recovery for free. Never signs or pays; cannot restore LLM output the merchant does not retain.

ParametersJSON Schema
NameRequiredDescriptionDefault
purchase_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already mark it read-only, open-world, idempotent, and non-destructive. The description adds useful non-obvious caveats: it never signs or pays, and it cannot restore LLM output the merchant does not retain. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the core action front-loaded and constraints following. The phrasing is a little dense, but there is no wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read-only tool with an output schema and strong annotations, the caveats cover the main behavioral concerns. However, the description omits when to use this instead of sibling status/JSON tools and does not define purchase_id, so it is not fully self-contained.

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

Parameters2/5

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

The schema has 0% description coverage for the single required purchase_id. The description does not explain the parameter format, provenance, or expected values beyond implying the tool reads saved purchase data, so it does not compensate for the missing schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: reading saved purchase metadata, with an additional LLM-specific payment recovery query. It is reasonably clear and distinct from siblings like purchase_json or budget_status, though it never explicitly names a sibling or says 'payment status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to select payment_status over siblings such as purchase_json, quote, or budget_status. The phrase 'for LLMs' hints at an audience, but it does not state conditions, prerequisites, or alternatives.

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

purchase_jsonA

Buy narration or LLM text using an owner-funded local wallet. Read schema and quote first. Supply a unique purchase_id once; reuse it after uncertainty, never invent a replacement. Saves output to the caller's private state directory. Narration body: input, voice. LLM body requires input, adult=true, third_party_processing=true, terms_version=2026-09-11-llm-v1 and optional max_tokens. Only assert these acknowledgements with the user's authority.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYes
serviceYes
purchase_idYes
confirm_purchaseNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable behavioral context: the purchase is owner-funded, output is saved to the caller's private state directory, and acknowledgements must only be asserted with the user's authority. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-organized, front-loading the core action and then detailing requirements. Every sentence adds value, though the final sentence about acknowledgements could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested body object, multiple service types, idempotency concerns) and the presence of an output schema, the description covers the critical usage context well. It could mention confirm_purchase's role, but the overall guidance is strong.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It explains the body structure for both narration and LLM services, and clarifies the purchase_id uniqueness requirement. It does not explain confirm_purchase, but the schema's default false and the description's emphasis on purchase_id reuse partially cover the semantics.

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?

The description clearly states the tool's purpose: buying narration or LLM text using an owner-funded local wallet. It distinguishes the two service types (narration vs LLM) and names the required body fields for each, which differentiates it from siblings like quote and catalogue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs the agent to read the schema and quote first, and to supply a unique purchase_id once, reusing it after uncertainty rather than inventing a replacement. It also specifies the exact required fields for LLM body, which is strong usage guidance.

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

quoteA
Read-onlyIdempotent

Get a free verified USDC/Base quote: narration, transcription, abliterated or abliterated-large. No input uploaded or funds spent.

ParametersJSON Schema
NameRequiredDescriptionDefault
serviceYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat those. It adds value by explicitly confirming that no input is uploaded and no funds are spent, which is beyond the annotations. It also mentions the return of a 'free verified' quote, providing some behavioral context.

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?

The description is extremely concise: one sentence with no filler. It front-loads the key action ('Get a free verified USDC/Base quote') and specifies the services. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (though not shown), which covers return values, and annotations handle safety. The description covers the core purpose and the service options. However, it lacks details on the exact format of the 'service' parameter and what happens after the quote (e.g., payment flow), but these are minor given the simple nature of the tool.

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

Parameters1/5

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

The schema has only one parameter 'service' with 0% description coverage and no enums. The description lists the possible service values (narration, transcription, abliterated, abliterated-large) in natural language, which adds some meaning. However, it does not specify the exact string format for 'service', leaving ambiguity for an agent. This is a significant gap because the parameter is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: obtaining a free USDC/Base quote for specific services (narration, transcription, abliterated, abliterated-large). It also distinguishes the quote from actual processing by noting no upload or funds spent. However, it does not explicitly compare to sibling tools, so a 4 is appropriate.

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 implies this is a preliminary step before committing to a purchase, as it mentions 'free' and 'no funds spent.' It does not explicitly state when NOT to use this tool or mention alternatives like catalogue or purchase_json, but the context of 'quote' versus 'purchase' is clear. A score of 4 reflects clear context without explicit exclusions.

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

transcribe_fileA

Buy transcription of a caller-provided audio file (60 seconds/12 MiB maximum). Filename must be a basename within owner-configured NEURODYNAMIC_INPUT_DIR; file must be mode 0600. It is uploaded only for an explicit purchase. Never provide a path outside that directory.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
languageNoen
purchase_idYes
confirm_purchaseNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Goes beyond annotations by disclosing that this operation triggers a purchase/upload, requires a specific file mode and directory, and must not be used with paths outside that directory. It is consistent with readOnlyHint=false and does not contradict any annotation.

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 dense sentences with no filler. Purpose, limits, security constraints, and the path warning are all front-loaded and each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, file constraints, and purchase trigger well, and the output schema likely covers return values. However, the purchase workflow parameters are poorly explained, leaving an agent uncertain how to properly supply purchase_id and confirm_purchase.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It richly documents filename constraints, but says nothing about how purchase_id originates or that confirm_purchase must be true to execute the purchase; language is also undocumented. The 'explicit purchase' line only weakly covers confirm_purchase.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the exact action ('Buy transcription') and resource ('caller-provided audio file') with size/duration limits. It does not explicitly name sibling alternatives, but the buy-transcription scope is clearly distinct from catalogue, quote, payment_status, and budget_status.

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?

Gives clear operating conditions: the file must be within an owner-configured directory, mode 0600, and uploaded only for an explicit purchase. It does not explicitly route to alternatives or describe the purchase workflow, but the context is sufficient for basic selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedbudget_status
    • First observedcatalogue
    • First observedpayment_status
    • First observedpurchase_json
    • First observedquote
    • First observedtranscribe_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 6 tools

Disambiguation5/5

Each tool maps to a distinct step in the purchase lifecycle: catalogue browsing, quoting, buying JSON-based services, buying file transcription, payment status, and budget status. There is no meaningful overlap between them, and the descriptions clarify the boundaries.

Naming Consistency3/5

Names are readable but mix conventions: read-style tools are bare nouns or noun_noun (catalogue, quote, payment_status, budget_status), while purchase actions use verb_noun (purchase_json, transcribe_file). A uniform get_/list_ or verb_noun pattern would improve consistency.

Tool Count5/5

Six tools is well-scoped for a paid audio/LLM API. Each tool earns its place in the browse-quote-purchase-status workflow without bloat.

Completeness4/5

The core purchase lifecycle is covered: discover services, price them, buy narration/LLM text or transcription, and check payment/budget status. Minor gaps exist, such as no explicit output-retrieval or voice-cloning purchase tool, though output is saved to private state and cloning may be out of scope.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP-Transcribe

    transcribe-app
    A
    license
    Not graded
    quality
    C
    maintenance
    This service provides fast and reliable transcriptions for audio/video files and voice memos. It allows LLMs to interact with the text content of audio/video file.
    8
    MIT

  • solanaprox-mcp

    solanaprox
    A
    license
    A
    quality
    D
    maintenance
    Description: Pay-per-request access to Claude and GPT models via Solana USDC using a Phantom wallet address. No accounts, no API keys — wallet-native authentication.
    4
    11 npm
    MIT

  • omnicall-mcp

    ColinHughes2121
    F
    license
    Not graded
    quality
    C
    maintenance
    Keyless, pay-per-call AI gateway: 248 LLMs plus image/video/voice/music generation and live crypto, DeFi, markets, web-search and research tools through one MCP server. Pay per call in USDC via x402 on Base/Solana — no API key, no signup, free tier.
    -