A paid, growing marketplace of real AI agents -- Ed25519-proven, verifiable in your own process.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: fraud check, data extraction, code generation, embeddings, agent invocation, market quotes, lead scoring, various searches, security scanning, and proof verification. No two tools appear to overlap in functionality.
All tools follow a consistent forcedream_verb_noun pattern in snake_case (e.g., check_fraud, extract_data, generate_code). The naming is predictable and uniform across the entire set.
With 13 tools covering a wide range of functionalities, the count is on the higher end but still reasonable for a platform offering diverse AI-powered services. Each tool earns its place, though the scope is broad.
The tool set covers core operations (consumption, discovery, verification) for the platform. Minor gaps exist (e.g., no agent update/delete), but the surface is largely complete for the intended use.
forcedream_check_fraudCheck IP / account fraud riskAAssess fraud risk using real AbuseIPDB IP reputation plus internal signals (velocity, account age, withdrawal patterns). Returns risk_score, signals, and an allow/review/block verdict, WORM-sealed. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | Optional IP to check against AbuseIPDB. | |
| action | Yes | Action being checked, e.g. "login", "withdrawal". | |
| user_id | Yes | The user/account identifier to assess. |
| Name | Required | Description |
|---|---|---|
| signals | No | |
| verdict | Yes | 'allow', 'review', or 'block'. |
| worm_seal | No | |
| risk_score | Yes | |
| ip_reputation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. Description adds that the tool returns a WORM-sealed verdict, implying immutability, and mentions authentication needs. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, signals, outputs, and requirements with zero wasted words. Front-loaded with action and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameters are well-described, the description provides enough context for agent selection and invocation. It explains output structure and authentication, though additional detail on when to use over siblings could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with per-parameter descriptions. The description adds context on how parameters are used together (AbuseIPDB, internal signals, output fields), enhancing meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Assess fraud risk' with concrete signals (AbuseIPDB, velocity, account age, withdrawal patterns) and outputs (risk_score, signals, verdict). It clearly distinguishes from siblings like 'forcedream_security_scan' and 'forcedream_score_lead' by focusing on fraud risk assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for fraud risk assessment but does not explicitly state when to use versus alternatives or when not to use. It mentions requiring authentication, which is a precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_extract_dataExtract structured fields from a documentAInspectStructured JSON extraction from unstructured text -- grounded in real, live verification, not just pattern-matching. Pulls requested fields, nulls anything missing, never guesses. Cross-references detected proper-noun entities (companies, people, places) against Wikidata to confirm which extracted values are independently verified vs. unconfirmed. SPENDS your balance -- requires authentication (OAuth). Returns the extracted rows, what you were charged, and a proof_id you can verify with forcedream_verify_proof.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | The field names to extract, e.g. ["company_name", "ceo_name"]. | |
| document | Yes | The unstructured document text to extract from. | |
| budget_pence | No | Optional max spend in pence for this extraction. |
| Name | Required | Description |
|---|---|---|
| output | No | |
| status | Yes | 'completed' or 'error'. |
| verify | No | |
| task_id | No | |
| proof_id | No | |
| balance_pence | No | |
| charged_pence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral context beyond annotations: it spends balance, requires authentication, cross-references Wikidata for verification, and returns a proof_id for verification. Annotations already indicate openWorldHint=true and readOnlyHint=false, but the description adds critical details about cost, authentication needs, and verification workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys key points. It is slightly marketing-heavy ('real, live verification') but every sentence adds value. It could be slightly more concise, but the structure is logical and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but mentioned), the description succinctly summarizes return values (extracted rows, charge, proof_id). It also covers authentication, cost, and verification procedure. For a tool with 3 parameters and no enums, this is complete and well-contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds meaningful semantics beyond schema: it states that nulls are returned for missing fields and that extraction is 'grounded in real, live verification', which explains 'never guesses' behavior. This adds value, though the schema already provides good descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: structured JSON extraction from unstructured text with grounding in verification. It specifies the verb (extract), resource (structured fields from a document), and scope (grounded in verification, nulls missing fields). It distinguishes itself from sibling forcedream_verify_proof by mentioning the proof_id usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that it spends the user's balance and requires OAuth authentication, giving clear context on when it's appropriate to use. It also mentions that extracted values are cross-referenced against Wikidata and that the tool never guesses. However, it does not explicitly state when not to use this tool or alternatives beyond forcedream_verify_proof.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_generate_codeGenerate verified codeAInspectGenerates real, working code with real, live verification -- not just an LLM's opinion. Every response is checked with 6 independent modules: syntax validation, dependency health, security scanning (OSV.dev + GitGuardian), complexity analysis, documentation coverage, and test detection. Returns a deterministic quality score, honest risk assessment, and deployment readiness. SPENDS your balance -- requires authentication (OAuth).
| Name | Required | Description | Default |
|---|---|---|---|
| budget_pence | No | Optional max spend in pence for this call. | |
| task_description | Yes | What code to generate, e.g. "Write a Python function to validate an email address, with tests." |
| Name | Required | Description |
|---|---|---|
| output | No | |
| status | Yes | 'completed' or 'error'. |
| verify | No | |
| task_id | No | |
| proof_id | No | |
| balance_pence | No | |
| charged_pence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: lists the six verification modules, mentions balance spending and OAuth requirement. Annotations already indicate it's not read-only, so no contradiction. Could mention side effects on state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with all key information. Could be slightly more concise, but every detail adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers verification modules, output qualities, cost, and auth. Output schema exists for return values. Missing error handling or timeouts, but strong overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context (e.g., budget relates to spending) and a task example, but doesn't specify parameter formats or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates verified code with independent checks, distinguishing it from sibling tools that might generate code without such verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong guidelines on when to use (for verified code) and mentions cost and auth requirements, but does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_generate_embeddingGenerate a text embeddingAGenerate a real 1024-dim vector embedding for text via Voyage voyage-3.5, retrieval-optimised. Returns the vector, dimensions, token count, WORM-sealed. Requires authentication (per-token charge).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to embed (max ~32000 chars). | |
| input_type | No | Optional: "query" or "document". |
| Name | Required | Description |
|---|---|---|
| tokens | No | |
| embedding | Yes | |
| worm_seal | No | |
| cost_pence | No | |
| dimensions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: returns vector, dimensions, token count, WORM-sealed, and per-token charge. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with key verb-resource and model details, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently covers purpose, parameters, behavior, cost, and immutability for a simple embedding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description essentially repeats schema info without adding new meaning beyond what's already in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Generate a real 1024-dim vector embedding for text' with specific model and optimization, distinguishing it from sibling tools that handle other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for embedding tasks and mentions authentication and per-token charge, but does not explicitly state when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_generate_sentimentAnalyze sentiment (14-source verified)AInspectReal, 14-source sentiment analysis -- not just an LLM's opinion. Combines lexicon-based sentiment (VADER, AFINN), a transformer model (HuggingFace DistilBERT), toxicity (Google Perspective), entity/location verification (Wikidata, OpenStreetMap), news and community alignment (GDELT, Hacker News), grammar, readability, and language detection into one deterministic overall_sentiment, urgency, and business_impact score. Emotion and intent are LLM-derived and explicitly labeled as such -- never presented as verified. SPENDS your balance -- requires authentication (OAuth).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The customer feedback, review, or message to analyze. | |
| budget_pence | No | Optional max spend in pence for this call. |
| Name | Required | Description |
|---|---|---|
| output | No | |
| status | Yes | 'completed' or 'error'. |
| verify | No | |
| task_id | No | |
| proof_id | No | |
| balance_pence | No | |
| charged_pence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description comprehensively explains the tool's deterministic multi-source approach, distinguishes LLM-derived emotion/intent as explicitly labeled, and mentions side effects (spends balance, requires auth). Annotations do not contradict; readOnlyHint=false aligns with the spending behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but slightly verbose, listing all 14 sources and the exact scores produced. It front-loads the core purpose well. Minor redundancy could be trimmed, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 sources, multiple outputs), the description covers all key aspects: what it returns (overall_sentiment, urgency, business_impact), how it handles emotion/intent, authentication, and costing. An output schema exists, so further details are handled there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds contextual meaning: 'text' is described as 'customer feedback, review, or message', and 'budget_pence' as 'Optional max spend in pence'. This enriches the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs sentiment analysis using 14 verified sources, distinguishing it from sibling tools which cover fraud, data extraction, code generation, etc. The verb 'analyze' and specific resource 'sentiment' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the input as 'customer feedback, review, or message' and notes it requires authentication and spends balance, providing clear context. It does not explicitly state when not to use or compare to alternatives, but given no other sentiment tools, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_invoke_agentInvoke a ForceDream agentAInspectInvoke 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
forcedream_market_quoteGet a live market quoteALive market quote for a stock symbol via Alpha Vantage: price, change %, volume, day high/low, approximate spread, liquidity score. Hard-cached. WORM-sealed. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, e.g. "AAPL", "IBM". |
| Name | Required | Description |
|---|---|---|
| price | Yes | |
| symbol | Yes | |
| volume | No | |
| day_low | No | |
| day_high | No | |
| worm_seal | No | |
| change_percent | No | |
| liquidity_score | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: hard-cached, WORM-sealed (immutable), and requires authentication. This goes beyond the annotations and helps the agent understand caching, data permanence, and auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs all essential information: purpose, data source, output fields, and key attributes (cached, sealed, auth). No filler words; every clause adds value. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and presence of an output schema, the description covers all necessary context: data source (Alpha Vantage), output fields, caching behavior, immutability (WORM-sealed), and authentication needs. It does not need to explain return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter 'symbol' well-described in the schema. The description does not add further details about the parameter (e.g., accepted formats, case sensitivity) beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get a live market quote' and description clearly state the verb (get) and resource (live market quote). It lists specific data fields: price, change %, volume, day high/low, approximate spread, liquidity score. No sibling tool has a similar purpose, so differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies use for market data but lacks explicit guidance on when not to use it (e.g., for historical data) or mention of alternative tools. The phrase 'hard-cached' hints at data freshness, but no clear usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_score_leadScore a sales leadAInspectScore sales leads hot/warm/cold with weighted signals and a recommended next action -- grounded in real, live verification, not just pattern-matching. Cross-references detected companies, domains, and locations against 8 real sources: Wikidata, UK Companies House, EU VIES VAT validation, postcodes.io, Google PageSpeed Insights, OpenStreetMap Nominatim, DNS/MX records, and live HTTP checks. Global by design -- 5 sources work for any lead worldwide; 3 regional ones (UK/EU) apply only when genuinely detected. SPENDS your balance -- requires authentication (OAuth). Returns tier, score, signals, recommended action, and honest enrichment_status.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_pence | No | Optional max spend in pence for this scoring call. | |
| lead_description | Yes | Free-text description of the lead: company, contact, context, any details you have. |
| Name | Required | Description |
|---|---|---|
| output | No | |
| status | Yes | 'completed' or 'error'. |
| verify | No | |
| task_id | No | |
| proof_id | No | |
| balance_pence | No | |
| charged_pence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds important behavioral details: it spends balance, requires OAuth, and performs live verification against 8 sources. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds value, front-loading the core purpose and then detailing sources and outputs. It could be slightly more concise but is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 sources, global/regional, multiple outputs), the description is comprehensive. It covers return fields, warns about spending, and explains source behavior, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no new semantics beyond 'free-text description' and 'optional max spend', so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Score sales leads hot/warm/cold') and clearly states the resource ('sales leads') and outputs (tier, score, signals, etc.). It distinguishes from sibling tools like forcedream_check_fraud and forcedream_extract_data by focusing on lead scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scoring any sales lead and mentions costs and authentication, but does not explicitly compare with siblings or state when not to use it. However, the global/regional sourcing note provides some usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_search_agentsSearch ForceDream agentsADiscover 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 forcedream_verify_proof.
| 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. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| agents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by mentioning no key required, the specific metrics returned (proof_count, success_rate), and the ability to verify proofs with a sibling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, no fluff, immediately states purpose and key differentiators. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two optional parameters and existing output schema, the description provides all necessary context: functionality, filtering, return metrics, and connection to verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds less burden. However, it clarifies that query is matched against slug/name/capability and gives an example for capability filter, improving clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers ForceDream agents with system-derived metrics, and mentions optional filtering. It distinguishes from siblings like forcedream_verify_proof by focusing on search/discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use (to discover agents) and mentions alternative tool forcedream_verify_proof for verification. It also notes no key is needed, but lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_search_costsSearch agent pricingAReal price_per_call_pence for every registered agent. No key needed. Useful for budget-aware agent selection before invoking.
| Name | Required | Description | Default |
|---|---|---|---|
| max_price_pence | No | Optional: only return agents at or under this price. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| agents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds behavioral context by stating 'No key needed', implying open access without authentication. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The first sentence immediately states the output, the second adds value (no key, use case). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, full schema coverage, annotations, output schema), the description is complete. It covers purpose, access requirement, and usage context without needing more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single optional parameter), so baseline is 3. The description does not add details about the parameter beyond what the schema's description ('Optional: only return agents at or under this price.') provides, but the tool's overall purpose is clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Real price_per_call_pence for every registered agent', which is a specific verb+resource. It distinguishes from siblings like forcedream_search_agents by focusing solely on pricing, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Useful for budget-aware agent selection before invoking'. This implies when to use it (pre-invocation) but does not explicitly mention when not to use it or compare to alternative tools like forcedream_search_agents. Still, the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_search_providersSearch provider healthAReal, 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| providers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by specifying the live, real-time nature, the exact metrics returned, and that no authentication key is required. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key terms and no filler. Every sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present (though unseen), the description fully covers the tool's purpose and data. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (100% coverage by default), so description does not need to explain parameters. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides 'Real, live inference-provider health' with specific metrics (health_score, breaker_state, uptime_ratio, successes/failures), and distinguishes itself from siblings by noting it mirrors the platform's internal adaptive routing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'No key needed' implying open access, but does not explicitly specify when to use this tool vs. siblings like forcedream_search_reliability or forcedream_search_costs. Usage guidance is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_search_reliabilitySearch agent reliability dataAReal, system-measured reliability per agent: success_rate, avg_latency_ms, sample_size. No key needed. Same real data as forcedream_search_agents' health field, exposed standalone for reliability-focused queries.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_slug | No | Optional: filter to one agent slug. Omit to return all. |
| Name | Required | Description |
|---|---|---|
| agent_slug | No | |
| reliability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by confirming it returns 'Real, system-measured' data and listing the specific fields. It also clarifies no key is needed, which is beyond the annotations. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. It front-loads the core information (what data is returned) and immediately provides context about its relationship to another tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one optional parameter, no required fields, output schema exists), the description is nearly complete. It mentions the key fields returned and explains the relationship to forcedream_search_agents. The only minor gap is that it doesn't explicitly state that omitting agent_slug returns all agents, but that's covered by the schema description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter agent_slug, which is described as optional and for filtering. The description does not add any extra meaning or constraints beyond the schema, so it meets the baseline expectation without providing additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool returns 'system-measured reliability per agent: success_rate, avg_latency_ms, sample_size', clearly specifying the verb (search/reliability) and resource (agent reliability data). It distinguishes itself from the sibling forcedream_search_agents by noting it exposes the same health field standalone, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Same real data as forcedream_search_agents' health field, exposed standalone for reliability-focused queries', which guides when to use this tool vs. the sibling. It also mentions 'No key needed', implying ease of access. However, it does not explicitly list when not to use it or provide other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_security_scanScan code for security vulnerabilitiesAInspectReal security review for code: OWASP Top 10, injection, secrets, and dependency risks. Cross-references imported dependencies against OSV.dev (Google's Open Source Vulnerabilities database) for real CVEs, and scans for hardcoded secrets via GitGuardian's real-time detection (400+ types). SPENDS your balance -- requires authentication (OAuth). Returns severity-graded findings, a 0-100 risk score, what you were charged, and a proof_id you can verify with forcedream_verify_proof.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to scan for vulnerabilities. | |
| budget_pence | No | Optional max spend in pence for this scan. |
| Name | Required | Description |
|---|---|---|
| output | No | |
| status | Yes | 'completed' or 'error'. |
| verify | No | |
| task_id | No | |
| proof_id | No | |
| balance_pence | No | |
| charged_pence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states it spends balance, requires OAuth, and returns a proof_id for verification. Annotations indicate openWorldHint and destructiveHint false, which align with external dependencies and non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured paragraph with front-loaded purpose. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers return values (findings, risk score, charge, proof_id) and explains authentication and cost. Complete for a scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100% coverage). Description adds minimal beyond schema; mentions 'code' and 'budget' but does not elaborate on formats, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans code for security vulnerabilities including OWASP Top 10, injections, secrets, and dependencies. Distinct from sibling tools like forcedream_check_fraud or forcedream_extract_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for security scanning of code, mentions external databases and authentication. Does not explicitly state when not to use or contrast with siblings, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forcedream_verify_proofVerify a ForceDream proofAIndependently 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.
| 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_...). |
| Name | Required | Description |
|---|---|---|
| error | No | Present only when verified is false, e.g. a fetch failure. |
| key_id | No | |
| message | No | |
| task_id | No | |
| verified | Yes | |
| algorithm | No | |
| trustless | No | |
| fields_signed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: verification runs locally, uses Ed25519 math, does not require account or key, and never asks ForceDream. No contradiction with readOnlyHint or openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, purpose stated upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and all key aspects are covered, the description is complete and sufficient for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions (100% coverage). The description adds that task_id fetches from a public endpoint and proof skips the fetch, adding meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool verifies a ForceDream proof using public-key cryptography, clearly distinguishing it from siblings which perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains two modes (task_id or proof object) and notes verification is local, but does not explicitly state when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.