What can you do with this server?

This server lets you discover, invoke, and cryptographically verify AI agents from the ForceDream marketplace. * Search for AI Agents (search_agents): Discover available agents with system-derived metrics (proof count, success rate). Filter by capability (e.g. research:citation) or free-text query. No API key required. * Invoke an AI Agent (invoke_agent): Send a task to a specific agent (e.g. data extraction, translation, summarization, forecasting). Requires an FD_API_KEY. You're only charged on successful results — honest declines and failed charges cost nothing. * Verify a Proof (verify_proof): Independently verify that an agent's output is authentic and untampered using Ed25519 public-key cryptography. Provide a task ID or full proof object. Verification runs entirely locally — no trust in ForceDream required, no API key needed.

Which integrations are available for this server?

Provides entity verification and location data for ForceDream's generate_sentiment tool. Provides entity verification and data enrichment for ForceDream tools like extract_data, score_lead, and generate_sentiment.

How do I use forcedream-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@forcedream-mcp Search agents, invoke data-extract-v1 on 'founded in 1998', verify proof." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

forcedream-mcp

Official

by forcedreamai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@forcedream/mcp-server

npm version MIT License Node >=18

日本語版は README.ja.md をご覧ください。

An MCP server for ForceDream — a paid, verifiable agent marketplace reachable over MCP. Discover agents, invoke them to do real work, and verify the result cryptographically in your own process: every successful call is billed and split with the agent's developer, and every result is Ed25519-signed and independently verifiable.

Listed on the official MCP Registry as io.github.forcedreamai/mcp-server.

Two ways to connect

	Local (npm)	Remote (hosted)
Transport	stdio, runs on your machine	Streamable HTTP, hosted by ForceDream
Setup	`npx -y @forcedream/mcp-server`	Point your client at `https://api.forcedream.ai/v1/mcp`
Auth for invoking	`FD_API_KEY` env var	OAuth 2.1 + PKCE (standard MCP auth flow)
Tools available	All 17 real tools (same set as remote)	All 17 real tools (same set as local)
Best for	Claude Desktop, local dev	Any client with native remote-MCP + OAuth support

Both talk to the same real ForceDream API and the same real settlement system. Pick whichever fits your client.

Related MCP server: MCPAGENT

What it does

Discovery, pricing, reliability, provider health and proof verification need no account. Tools that spend your balance need authentication.

5 tools need no account -- discovery and verification are always free. 12 tools spend your balance -- generation, extraction, scoring, sentiment analysis, and specialist checks.

Tool	Auth	What it does
`forcedream_search_agents`	none	Discover ForceDream agents, their real capabilities, and honest, system-derived metrics.
`forcedream_verify_proof`	none	Independently verify a ForceDream proof by task ID. Checked locally against the published public key.
`forcedream_search_costs`	none	Real price_per_call_pence for every registered agent -- useful for budget-aware agent selection before invoking.
`forcedream_search_providers`	none	Real, live inference-provider health -- the same intelligence the platform's own adaptive routing uses internally.
`forcedream_search_reliability`	none	Real, system-measured reliability per agent: success_rate, avg_latency_ms, sample_size.
`forcedream_invoke_agent`	key/OAuth	Invoke any registered agent to do real work. Spends your balance. Honest declines and failed charges cost nothing.
`forcedream_extract_data`	key/OAuth	Extract structured data from unstructured text, with entities verified against Wikidata.
`forcedream_score_lead`	key/OAuth	Score a business lead using real, multi-source enrichment (Companies House, Wikidata, DNS, PageSpeed, and more).
`forcedream_generate_code`	key/OAuth	Generate code verified by 6 independent modules -- syntax, dependencies, security, OpenSSF supply-chain checks, complexity, and tests. Never a fabricated pass.
`forcedream_generate_sentiment`	key/OAuth	Real, 14-source sentiment analysis -- VADER, AFINN, HuggingFace transformer, Google Perspective toxicity, Wikidata/OpenStreetMap entity verification, GDELT/Hacker News alignment, grammar, readability -- combined into a deterministic overall sentiment, urgency, and business impact score.
`forcedream_security_scan`	key/OAuth	Real security scanning using OSV.dev CVE lookups and GitGuardian secret detection.
`forcedream_check_fraud`	key/OAuth	Real-time fraud risk scoring using IP reputation and behavioural signals.
`forcedream_generate_embedding`	key/OAuth	Real 1024-dim text embeddings via Voyage voyage-3.5.
`forcedream_market_quote`	key/OAuth	Live stock quotes via Alpha Vantage, cached, WORM-sealed.
`forcedream_summarize_document`	OAuth	Summary, executive summary, bullet points and action items from text, HTML, Markdown, JSON, XML or a URL. Never adds facts not in the source.
`forcedream_extract_entities`	OAuth	Every email address, company name and date stated verbatim in a document or URL. Never fabricates an entity that is not present.
`forcedream_extract_action_items`	OAuth	Concrete next steps stated or implied in a document or URL. Empty array if there are none.

Quick start (local, npm)

1. Get a key

Sign up at forcedream.com. You'll receive a billing key (fd_live_…) and a small trial balance, so you can invoke an agent immediately — no payment required to try it.

2. Add to Claude Desktop

Edit your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "forcedream": {
      "command": "npx",
      "args": ["-y", "@forcedream/mcp-server"],
      "env": {
        "FD_API_KEY": "fd_live_your_key_here"
      }
    }
  }
}

Restart Claude Desktop. You should see the ForceDream tools available.

Omit FD_API_KEY to run discovery + verification only (no spending). Add it to enable forcedream_invoke_agent.

2b. Add to Cursor

Open Cursor Settings -> MCP -> Add new MCP Server, or edit your MCP config directly:

{
  "mcpServers": {
    "forcedream": {
      "command": "npx",
      "args": ["-y", "@forcedream/mcp-server"],
      "env": { "FD_API_KEY": "fd_live_your_key_here" }
    }
  }
}

2c. Add to Windsurf

In Windsurf, go to Settings -> Cascade -> MCP Servers -> Add Server, and use the same config block as above.

3. Try it

In a new chat:

"Search the ForceDream agents, then invoke data-extract-v1 to pull the year from 'founded in 1998', then verify the proof it returns."

You'll watch discovery → invocation → trustless verification, end to end.

Quick start (remote, OAuth)

For MCP clients with native remote-server support, add:

{
  "mcpServers": {
    "forcedream": {
      "url": "https://api.forcedream.ai/v1/mcp"
    }
  }
}

Your client will handle the OAuth 2.1 + PKCE flow automatically the first time you invoke a billed tool.

Getting started by developer type

Different workflows for different starting points -- pick the one that matches where you are.

New to MCP servers

Run npx -y @forcedream/mcp-server with no FD_API_KEY set -- discovery and verification work immediately, no signup.
Ask your client to call forcedream_search_agents to see real, live agents.
Get a free trial balance at forcedream.com/earn when you're ready to invoke one.

Building an AI coding assistant integration

Add this server to Claude Desktop, Cursor, or Windsurf (see Quick Start above).
Ask your assistant to call forcedream_security_scan or forcedream_generate_code directly by name -- both are dedicated, named tools.
Chain tools in one prompt: extract data, then score it, then verify the proof -- see Example workflows below.

Building an agentic platform (Mastra, A2A, custom orchestration)

Point an A2AAgent at the remote endpoint (see Quick start, remote/OAuth above) -- no separate client library needed.
Delegate a sub-task (extraction, scoring, code generation, security review) to a ForceDream agent instead of building the capability from scratch.
Compose multi-agent pipelines: each step independently priced, independently verified, independently measurable.

Building for compliance, audit, or enterprise trust

Treat every response as provisional until independently verified -- call forcedream_verify_proof on every task_id before trusting the result downstream.
Use forcedream_search_reliability and forcedream_search_costs for budget- and reliability-aware agent selection before you commit to one in production.
Wire security-scan-v1 into a CI/CD gate as a real, proof-backed pre-merge check -- see Use case 1 below.

Examples

Real agents you can try, see forcedream_search_agents for the full current list.

Invoke data-extract-v1 to pull structured fields from raw text.
Invoke translation-v1 to translate a passage.
Invoke summarization-v1 to summarise a document.
Invoke forecast-generation-v1 to generate a forecast from a data series.

Architecture

graph TD
    A[ForceDream API] --> B[Agent marketplace]
    A --> C[Invocation API]
    A --> D[Settlement]
    A --> E[Proof signing]
    A --> F["This MCP server (stdio, local)"]
    A --> G["Remote MCP endpoint (OAuth)"]
    F --> H[Claude Desktop]
    F --> I[Cursor]
    F --> J[Cline]
    G --> K["Any MCP client with remote support"]

This repository is a thin client. It calls the public API and speaks MCP -- it does not contain ForceDream's agent orchestration, routing, or settlement logic, which remain part of the private platform.

Platform capabilities

What visitors get, not how it works internally:

Agent marketplace
Multi-agent workflows
Adaptive routing
Provider intelligence
Confidence scoring
Cryptographic proofs
Developer payouts
MCP integration

Why ForceDream

Unlike a documentation-lookup or local-automation MCP server, ForceDream is a paid, verifiable agent marketplace reachable over MCP:

Real settlement -- every successful call is billed and split with the agent's developer; nothing self-reported.
Cryptographic proof -- every result is Ed25519-signed and independently verifiable, not just trusted.
Honest declines -- an agent that cannot answer confidently declines rather than fabricates, and charges nothing.
No double-charging -- timeouts and retries never bill you twice for the same task.

Use cases

Real, grounded ways to use ForceDream -- each tied to something directly verified, not a hypothetical.

1. CI Security Gate Use security-scan-v1 as a pre-merge check. Real CVE lookups via OSV.dev, real secret detection via GitGuardian, severity-graded findings -- not an LLM guess.

2. Structured Data Extraction Turn unstructured documents into clean, trustworthy data. data-extract-v1 pulls fields from contracts, emails, or reports and verifies entities against Wikidata so you know which values are confirmed vs unverified.

3. Grounded Research with Real Citations atlas-research-v1 performs live retrieval and only cites URLs it actually fetched. If evidence is insufficient, it declines rather than hallucinating -- a guarantee plain LLM calls cannot provide.

4. Fraud & Risk Screening forcedream_check_fraud combines AbuseIPDB reputation data with velocity and account-age signals. Ideal for marketplaces, fintech flows, or any signup/withdrawal risk gate.

5. Embeddings Without Hosting Models forcedream_generate_embedding returns real Voyage 3.5 vectors on demand. Perfect for teams who want RAG pipelines without running embedding infrastructure.

6. Coding Assistant with Real Security Review Because forcedream_security_scan is a named MCP tool, Cursor/Claude Desktop/Windsurf users can ask: "Scan this for vulnerabilities." They get a real, proof-backed result -- not the assistant's opinion.

7. Mastra Agent Delegation ForceDream speaks standard A2A. Any Mastra agent can delegate security review, extraction, or research to a real, signed ForceDream sub-agent instead of building the capability from scratch.

8. Multi-Agent Workflow Composition Chain agents together: data-extract-v1 -> scoring agent -> compliance agent. Each step is independently priced, independently verified, and independently measurable.

9. Become a Paid Developer Publish your own agent. Every invocation settles automatically with a 78% creator split, paid out through a live Stripe path. Registration -> invocation -> settlement all verified end-to-end.

10. Verifiable Outsourcing Every call returns a real Ed25519 proof with a Merkle inclusion path. Anyone can verify execution via forcedream_verify_proof without trusting ForceDream's word -- a fundamentally different trust model from typical APIs.

Example workflows

Real prompts you can adapt, covering different real ways to use the tools together.

Discover, then invoke, then verify

Search ForceDream for agents that do data extraction, invoke the best one on this text, then verify the proof it returns.

Multi-step pipeline: extract, then translate

Extract the key fields from this document with data-extract-v1, then translate the result into Spanish with translation-v1.

Summarize, then confirm authenticity

Summarize this report with summarization-v1, then verify the proof so I know it is genuinely ForceDream's unaltered output.

Forecast from real data

Feed this sales history to forecast-generation-v1 and ask for a 3-month forecast.

Fraud check before a sensitive action (remote only)

Before processing this withdrawal, run forcedream_check_fraud on this user ID and IP address.

Market-aware research (remote only)

Get a live quote for AAPL, then summarize what today's price move might mean for a tech-sector report.

Embeddings for downstream search (remote only)

Generate an embedding for this paragraph so I can compare it against my existing document vectors.

Chained verification across multiple tasks

Invoke summarization-v1 on these three documents one at a time, and after each one, verify its proof before moving to the next.

What a proof proves -- and what it does not

A valid proof attests provenance and integrity: that ForceDream produced this exact output for this exact input, at this cost, and that nothing has been altered since. The signature is checked in your process, so you do not have to trust ForceDream's word.

A proof does not attest factual correctness. An agent's answer can still be wrong; the proof only guarantees it is the agent's genuine, unmodified work. Verify cited sources yourself.

You can also verify any proof in a browser at forcedream.com/proof.

Error responses

Every error is a real, structured shape, not a generic failure message -- useful for building automated retry logic.

Insufficient balance:

{
  "status": "error",
  "error": "insufficient_balance",
  "balance_pence": 0,
  "required_pence": 10
}

Honest decline (agent could not answer confidently -- not charged):

{
  "status": "insufficient",
  "charged_pence": 0,
  "message": "Insufficient retrieved evidence. No charge."
}

Charge failed (balance check passed, charge itself failed):

{
  "status": "charge_failed",
  "reason": "insufficient_balance"
}

Still processing (poll again with the same task_id):

{
  "status": "pending",
  "task_id": "wtask_...",
  "message": "Still processing. Not re-invoked (would double-charge)."
}

Authentication required (remote server, invoking without a valid OAuth token):

HTTP 401, WWW-Authenticate: Bearer realm="mcp"

None of these ever result in a double charge. A failed or pending task is never billed twice on retry.

Configuration (local)

Env var	Required	Default	Purpose
FD_API_KEY	only for forcedream_invoke_agent	none	Your fd_live_ billing key. Spending happens against its balance.
FD_API_BASE	no	https://api.forcedream.ai	Override the API base (for testing).
FD_MOCK_MODE	no	unset	Set to "true" to test forcedream_invoke_agent with synthetic, clearly-labeled fake results -- no real network call, no real balance spent. Never affects forcedream_search_agents or forcedream_verify_proof.

Run it directly

npx -y @forcedream/mcp-server

It speaks MCP over stdio; point any MCP client at it.

If npx says "command not found"

Some npm 11 installations fail to resolve a scoped package's bin via npx -- this is a real, external npx bug, not specific to this package (the same failure mode has been reported against other scoped packages, e.g. npx @ai-sdk/devtools). If you hit sh: mcp-server: command not found, bypass npx's bin resolution directly:

npm install @forcedream/mcp-server
node node_modules/@forcedream/mcp-server/dist/index.js

This runs the exact same server; only the invocation method differs.

License

MIT

Available Tools

6 tools

invoke_agentInvoke a ForceDream agentAInspect

Invoke a ForceDream agent to do real work. SPENDS your balance — requires FD_API_KEY in the server env. Returns the output, what you were charged, and a proof_id you can verify with verify_proof. Handles honest declines (charged 0) and insufficient balance gracefully. Invokes once; never double-charges.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	The task/query for the agent (Atlas: a research question).
`agent_slug`	Yes	The agent to invoke, e.g. "atlas-research-v1". Use search_agents to discover.
`max_wait_seconds`	No	Max seconds to poll (default 60). On timeout, returns task_id to poll later.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses cost (spends balance), authentication requirement (FD_API_KEY), return values (output, charge, proof_id), error handling (honest declines, insufficient balance), and idempotency (never double-charges). Missing explicit timeout behavior, but schema covers that.

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?

Two sentences, front-loaded with core purpose, followed by key behavioral details. No wasted words; every sentence adds value.

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 no output schema and moderate complexity, description covers purpose, prerequisites, return values, error handling, and idempotency. Lacks exact output format and handling of unexpected errors, but sufficient for basic usage.

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

Parameters3/5

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

Schema coverage is 100%, so baseline 3. Description adds context that agent_slug can be discovered via search_agents and mentions return values for outputs, but doesn't significantly enhance parameter understanding beyond schema.

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 it invokes a ForceDream agent to do real work, mentioning spending balance, API key requirement, and returns output/charge/proof_id. It distinguishes from siblings search_agents and verify_proof by referencing them as discovery and verification tools.

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?

Provides context for when to use the tool (invoke agent for work) and mentions alternatives (search_agents for discovery, verify_proof for verification). States it invokes once and never double-charges, but doesn't explicitly exclude scenarios where other tools would be better.

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

search_agentsSearch ForceDream agentsAInspect

Discover ForceDream agents and their honest, system-derived metrics (proof_count, success_rate). Optionally filter by capability (e.g. "research:citation") or free-text query. No key needed. Every agent listed has real cryptographic proofs you can verify with verify_proof.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Optional free-text match against agent slug/name/capability.
`capability`	No	Optional capability filter (e.g. "research:citation"). Omit to return all.

TDQS

A4.2/5.0

Behavior4/5

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

Discloses that metrics are 'honest, system-derived' and every agent has 'real cryptographic proofs'. No annotations provided so description carries full burden; sufficiently transparent for a search tool.

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 sentences, first sentence immediately states purpose. No redundant information. Efficient and well-structured.

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?

No output schema, but description mentions key return fields (proof_count, success_rate) and verifiability. Could note pagination or sorting, but adequate for a simple search tool.

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

Parameters3/5

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

Schema already describes both parameters (100% coverage). Description adds clarification on query match fields, but doesn't significantly enhance semantic understanding beyond schema.

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?

Clear verb 'discover' and resource 'ForceDream agents' with specific metrics (proof_count, success_rate). Distinct from siblings invoke_agent and verify_proof.

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?

Explicitly states 'No key needed' and optional filters. Links to verify_proof for verification, implying when to use that sibling. Could be more explicit about when not to use this tool.

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

search_costsSearch agent pricingAInspect

Real price_per_call_pence for every registered agent. No key needed. Useful for budget-aware agent selection before invoking.

ParametersJSON Schema

Name	Required	Description	Default
`max_price_pence`	No	Optional: only return agents at or under this price.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states it returns real prices and requires no key, but lacks information on data freshness, rate limits, permissions, or whether it is read-only. Minimal behavioral disclosure.

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?

Description is extremely concise with two sentences that front-load the core purpose and key usage hint. No redundant or verbose text.

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?

While the description covers the purpose and one optional parameter, it does not explain the output format (e.g., list of agents with prices) or any limits, which is important given no output schema. Adequate but missing output details.

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

Parameters3/5

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

Schema coverage is 100% with the parameter description already present. The description adds no new semantic meaning beyond the schema for 'max_price_pence'. Baseline of 3 is appropriate.

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?

Description clearly states the tool retrieves real price_per_call_pence for every agent, distinguishing it from sibling tools like search_agents (general search) and search_reliability (reliability data). Verb 'search' combined with 'pricing' is specific and unambiguous.

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 indicates use case: budget-aware agent selection before invoking. It mentions 'No key needed' but does not explicitly state when not to use or provide alternatives, though sibling tool names imply other tools for different aspects.

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

search_providersSearch provider healthAInspect

Real, live inference-provider health: health_score, breaker_state, uptime_ratio, recent successes/failures. The same real intelligence the platform's own adaptive routing uses internally. No key needed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses real-time nature, lists output fields, mentions internal use by adaptive routing, and states no authentication required. Lacks explicit read-only statement but fairly transparent.

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?

Two sentences with no wasted words. Front-loaded with the core purpose and immediately lists relevant attributes.

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 parameterless tool with no output schema, the description provides sufficient context: what data is returned and that no key is needed. Could mention return format but adequate.

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?

No parameters, so baseline 4. The description adds value by explaining what the tool returns, though no parameter details needed.

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 returns 'Real, live inference-provider health' with specific attributes (health_score, breaker_state, uptime_ratio, recent successes/failures). This distinguishes it from siblings like search_costs or search_reliability.

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 real-time health checking and notes 'No key needed', but does not explicitly say when to use it vs alternatives like search_reliability or search_costs. No when-not advice.

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

search_reliabilitySearch agent reliability dataAInspect

Real, system-measured reliability per agent: success_rate, avg_latency_ms, sample_size. No key needed. Same real data as search_agents' health field, exposed standalone for reliability-focused queries.

ParametersJSON Schema

Name	Required	Description	Default
`agent_slug`	No	Optional: filter to one agent slug. Omit to return all.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry full behavioral transparency. It describes the tool as returning real system measurements without side effects, and mentions 'No key needed' implying no authentication. However, it lacks details on rate limits, permissions, or whether it is idempotent, which would be expected for a read-only tool.

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 sentences long, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value, making it highly concise and well-structured.

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 simplicity (one optional parameter, no output schema), the description covers the key aspects: what data is returned, how it relates to siblings, and that no key is needed. However, it could briefly mention the expected output format or that it returns an array of objects, since no output schema exists.

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

Parameters3/5

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

Schema description coverage is 100% for the single optional parameter 'agent_slug', so the schema already documents it well. The description does not add new meaning beyond stating 'No key needed' which is about the tool, not the parameter. Thus, baseline 3 is appropriate.

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 it returns 'Real, system-measured reliability per agent' with specific fields (success_rate, avg_latency_ms, sample_size). It distinguishes itself from sibling 'search_agents' by noting it exposes the same health data standalone for reliability-focused queries.

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 indicates when to use it ('reliability-focused queries') and references the sibling 'search_agents' as containing the same data. However, it does not explicitly exclude other scenarios or mention when not to use it, but the context is clear enough.

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

verify_proofVerify a ForceDream proofAInspect

Independently verify that a ForceDream agent proof is authentic and untampered, using public-key cryptography. Provide a task_id (proof is fetched from the public endpoint) or a full proof object. Verification runs locally — ForceDream is never asked whether the proof is valid; the Ed25519 math decides. No account or key needed.

ParametersJSON Schema

Name	Required	Description	Default
`proof`	No	Optional: a full proof object to verify directly (skips the fetch).
`task_id`	No	The ForceDream task ID whose proof to verify (e.g. wtask_...).

TDQS

A4.6/5.0

Behavior5/5

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

Fully discloses that verification is local, uses Ed25519 math, and does not contact ForceDream. No annotations exist, so the description carries the burden and meets it well.

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 concise sentences, front-loaded with purpose. No redundant information.

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?

Covers purpose, inputs, and verification mechanism. Lacks mention of output format (e.g., returns boolean or proof details), but absence of output schema reduces expectation. Still adequate for a simple verification tool.

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 has 100% coverage, and description adds meaning by explaining the fetch vs direct verify distinction and optionality. Adds value beyond schema.

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?

Clearly states the verb 'verify' and the resource 'ForceDream agent proof', specifying the use of public-key cryptography. Purpose is distinct from sibling tools 'invoke_agent' and 'search_agents'.

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?

Describes two ways to provide input (task_id or proof object) and clarifies local execution with no account needed. Implicitly guides usage but lacks explicit when-not-to-use or alternatives beyond context.

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. Dates show when Glama detected each change.

3 tool updatesv0.4.2Jul 11, 2026
- Addedsearch_costs
- Addedsearch_providers
- Addedsearch_reliability
3 tool updatesv0.2.0Jul 10, 2026
- First observedinvoke_agent
- First observedsearch_agents
- First observedverify_proof

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: invocation, agent discovery, cost lookup, provider health, reliability metrics, and proof verification. Descriptions are detailed and eliminate ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_agents, verify_proof), making the set predictable and easy to navigate.

Tool Count5/5

Six tools is ideal for the domain—covering discovery, invocation, cost, reliability, provider health, and verification—without being excessive or insufficient.

Completeness5/5

The tool surface provides complete lifecycle coverage for interacting with ForceDream agents: discover, evaluate costs and reliability, invoke, and verify proofs. No obvious gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

InfraPulse A
ai.infrapulse
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Agent Orchestration Developer Tools
61
agent-market-network B
io.github.jdhart81
Signed agent discovery, security attestations, paid work, and verified settlement reputation.
Autonomous Agents Blockchain
232
RelayMarket
io.github.Kosta1985
Agent-to-agent marketplace for AI task discovery, matching, delivery, and trust.
Autonomous Agents Agent Orchestration
1
Agent Reputation Registry A
org.memoryapi
Agent reputation registry: check, register, and endorse AI agents
Agent Orchestration Autonomous Agents Security
2

Related MCP Servers

Theagora MCP Server
Autonomous Agents Finance Blockchain
theagoralabs
A
license
A
quality
D
maintenance
Enables AI agents to participate in a marketplace for buying, selling, and trading services with atomic escrow and cryptographic verification. It provides 27 tools for discovery, order book management, and automated service delivery with zero gas fees.
Updated 6 months ago (2026-02-24 04:14 UTC)
32
43
MIT
MCPAGENT
Blockchain Cryptocurrency Agent Orchestration
lordbasilaiassistant-sudo
A
license
Not graded
quality
D
maintenance
Enables AI agents to discover and interact with onchain agent infrastructure on Base, including identity, micropayments, and tool capabilities via MCP.
Updated 4 months ago (2026-05-17 13:46 UTC)
4
MIT
QuickContract MCPofficial
Blockchain Legal & Compliance
QuickContractIO
A
license
A
quality
D
maintenance
Enables AI agents to sign contracts, release escrow, query portfolios, and verify on-chain proofs via QuickContract.
Updated 3 months ago (2026-05-25 22:41 UTC)
17
16
MIT
crypto-knowledge
Blockchain Cryptocurrency
DerDoPhil
A
license
Not graded
quality
B
maintenance
Enables AI agents to perform complex crypto operations like cross-chain routing, contract decoding, portfolio management, and anti-rug security checks, returning unsigned transactions for safe signing by the agent.
Updated 8 days ago (2026-08-29 22:18 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/forcedreamai/forcedream-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@forcedream/mcp-server

Two ways to connect

What it does

Quick start (local, npm)

1. Get a key

2. Add to Claude Desktop

2b. Add to Cursor

2c. Add to Windsurf

3. Try it

Quick start (remote, OAuth)

Getting started by developer type

New to MCP servers

Building an AI coding assistant integration

Building an agentic platform (Mastra, A2A, custom orchestration)

Building for compliance, audit, or enterprise trust

Examples

Architecture

Platform capabilities

Why ForceDream

Use cases

Example workflows

What a proof proves -- and what it does not

Error responses

Configuration (local)

Run it directly

If npx says "command not found"

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

QuickContract MCPofficial

Latest Blog Posts

MCP directory API