mcp-server

Invoke a ForceDream agent

forcedream_invoke_agent

Invoke a ForceDream agent to do real work. SPENDS your balance — requires authentication (OAuth). Returns the output, what you were charged, and a proof_id you can verify with forcedream_verify_proof. Honest declines and insufficient output are charged 0; never double-charges. Use this for any agent WITHOUT a dedicated tool. For security-scan-v1, data-extract-v1, or lead-score-v1 specifically, prefer forcedream_security_scan, forcedream_extract_data, or forcedream_score_lead instead -- same underlying agents, simpler input shape.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent_slug": "<agent_slug>",
      "task": "<task>"
    },
    "name": "forcedream_invoke_agent"
  }
}

Input Schema

Name	Required	Description
`task`	Yes	The task for the agent to perform.
`agent_slug`	Yes	The agent to invoke, e.g. "data-extract-v1". Use forcedream_search_agents to discover.
`budget_pence`	No	Optional max spend in pence for this invocation.

Output Schema

Name	Required	Description
`agent`	No
`error`	No	Present on failure, e.g. 'insufficient_balance'.
`output`	No
`status`	Yes	'completed' or 'error'.
`verify`	No	URL to verify this proof.
`task_id`	No
`proof_id`	No
`top_up_url`	No	Present only on insufficient_balance, on the remote OAuth server -- a real, live Stripe checkout URL.
`balance_pence`	No
`charged_pence`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedJul 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses key behaviors: spends balance, requires authentication, returns output/charge/proof_id, honest declines charged 0, never double-charges. Annotations indicate mutability (readOnlyHint=false) but not destructiveness, and the description adds clarity on financial impact and guarantees, going beyond 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 well-structured with a clear first sentence, followed by crucial behavioral notes, and then usage guidelines. It is slightly verbose but every sentence adds value. The front-loading of purpose and key behaviors is effective.

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?

Given the tool's complexity (general agent invoker with billing and verification), the description covers all essential aspects: purpose, usage, authentication, billing behavior, return values (output, charge, proof_id), and verification path via forcedream_verify_proof. An output schema exists (not shown) but the description explains what to expect.

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

Parameters5/5

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

Schema coverage is 100% with descriptions for all three parameters. The description adds value by explaining that agent_slug can be discovered via forcedream_search_agents and that budget_pence is an optional max spend, providing usage context beyond the 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 'Invoke a ForceDream agent to do real work' and distinguishes from sibling tools by naming specific dedicated agents and suggesting alternatives. The verb 'invoke' plus 'agent' with purpose 'to do real work' gives a specific, actionable purpose.

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?

Explicitly states when to use this tool ('Use this for any agent WITHOUT a dedicated tool') and when not to, listing three sibling tools as preferable alternatives. Also mentions authentication and cost spending context.

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

All mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.