Forecall Failure KB

by dev.forecall

Overview Discussions Admin

Server Details

Known MCP tool-call failures and workarounds verified by reproduction.

Ownership verified

Status: Healthy
Uptime: 99.9% over 21 days
Last Tested: 2026-10-27 16:20
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored 2026-10-17 02:20 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: kb_lookup reads records, kb_report creates new ones, kb_confirm verifies an existing workaround, and kb_dispute flags a wrong record. Descriptions explicitly disambiguate with cross-references like 'Do not use it for X: use Y instead,' leaving no overlap in purpose.

Naming Consistency5/5

All four tools follow a uniform kb_<verb> snake_case pattern (kb_confirm, kb_dispute, kb_lookup, kb_report). The prefix and verb style are perfectly consistent.

Tool Count5/5

Four tools cleanly cover the read/write/verify/flag lifecycle of a failure knowledge base without redundancy. Each tool earns its place and none feels extraneous.

Completeness4/5

The core lifecycle (lookup, report, confirm, dispute) is well covered, including preflight and server-level lookups. Minor gaps remain, such as listing or retrieving one's own submitted records or retracting/editing a report, but agents can work around these.

Available Tools

4 tools

kb_confirmConfirm a workaround's outcomeAInspect

Report the outcome of applying a workaround you obtained from kb_lookup: success, failure or inapplicable (e.g. inapplicable when your call never hit that failure). This is how records get verified. Call it once per record you tried. Do not use it for a failure you fixed another way: report that with kb_report. It takes no units; only the key's per-minute rate limit applies. Returns the record's new state.

Name	Required	Description
`env`	Yes	Where the call ran.
`outcome`	Yes	success: the workaround fixed it; failure: it did not; inapplicable: it did not apply.
`evidence`	No	What you saw, in a sentence or two (no payloads).
`lookup_id`	No	The lookup_id of the kb_lookup that gave you the record, if any.
`record_id`	Yes	A record's id from kb_lookup or kb_report.

Output Schema

Name	Required	Description
`state`	Yes
`record_id`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, idempotentHint=false and openWorldHint=false; the description adds cost behavior ('takes no units; only the key's per-minute rate limit applies'), call cardinality, and the fact that it mutates verification state. These are exactly the traits an agent needs beyond the annotation flags, and they are consistent with idempotentHint=false.

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?

Four tight, front-loaded sentences with no filler; the core action and the exclusion come first. The trailing 'Returns the record's new state' is largely redundant given that an output schema exists, which costs it the top mark.

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 an output schema exists, the description need not explain return values, and it covers everything else: when to call, when not to, the alternative, call frequency, and cost. Nothing an agent needs to invoke this correctly is missing.

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%, so record_id, lookup_id, env and evidence are already documented in the schema; that sets the baseline at 3. The description adds a useful gloss on the `inapplicable` enum member, but says nothing about lookup_id linkage or the env payload, so it does not meaningfully exceed 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?

States a specific verb and resource ('Report the outcome of applying a workaround you obtained from kb_lookup') and enumerates the three accepted outcomes. It clearly distinguishes itself from kb_report and kb_dispute, which appear as siblings, so an agent can route correctly without opening any schema.

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?

Gives explicit trigger conditions ('Call it once per record you tried'), an exclusion ('Do not use it for a failure you fixed another way'), and names the alternative to use instead (kb_report). It even clarifies the ambiguous case where the predicted failure never occurred.

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

kb_disputeDispute a recordA

Idempotent

Inspect

Flag a record as wrong or outdated, optionally pointing to a better record. Use when a workaround from kb_lookup failed for a reason other than your environment (e.g. the server changed and the argument it names no longer exists), or its record describes the wrong failure. Do not use it to report a new failure: use kb_report. It takes no units; only the key's per-minute rate limit applies. Returns the dispute's id.

Name	Required	Description
`reason`	Yes	Why the record is wrong or outdated, e.g. `the server renamed api_key to token in 2.0`.
`record_id`	Yes	A record's id from kb_lookup or kb_report.
`alternative_record_id`	No	A record that is right instead, if any.

Output Schema

Name	Required	Description
`dispute_id`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=false, and idempotentHint=true. The description adds useful operational context beyond annotations: 'It takes no units; only the key's per-minute rate limit applies' and 'Returns the dispute's id.' It does not disclose visibility or downstream effects of a dispute, but covers enough for safe invocation.

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?

Front-loads the core action, then usage conditions, then the exclusion and alternative, then operational notes. Every sentence serves a distinct purpose: what it does, when to use, when not to use, rate-limit context, and return value. No wasted words.

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

Completeness5/5

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

For a 3-parameter tool with full schema coverage, annotations, and an output schema, the description supplies all the missing routing and operational context: when to use, when not to use, the alternative tool, rate-limit behavior, and the return value. An agent has everything needed to call it correctly.

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%, so all three parameters are already documented in the schema. The description's phrase 'optionally pointing to a better record' maps to alternative_record_id but adds no syntax, format, or constraint details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource: 'Flag a record as wrong or outdated, optionally pointing to a better record.' Explicitly distinguishes from sibling kb_report by stating 'Do not use it to report a new failure: use kb_report.' An agent can identify the tool's scope without opening the schema.

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?

Gives explicit when-to-use conditions (after a kb_lookup workaround failed for a non-environment reason, or the record describes the wrong failure) and an explicit when-not (not for new failures). Names the alternative tool (kb_report) and the condition that selects it.

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

kb_lookupLook up known failuresA

Read-onlyIdempotent

Inspect

Check for known failures and workarounds BEFORE or AFTER calling a third-party tool. Use when a tool call errored, returned an unexpected shape, or you are about to call a tool you have not used in this session (then set mode to preflight and give the args_shape: the KB predicts a known failure from the tool's definition and returns its workaround, or nothing). Before using a server you have not used, set mode to server and leave out the tool to list its known failures. Returns the records the tool's vendor answered first, with its official_answer, then verified workarounds; unverified ones are marked. Each call takes one unit of the organization's monthly limit, returns at most max_results records, and says in units_left how many units remain. Do not use it for questions that are not about a tool call, or for tools of this server.

Name	Required	Description	Default
`mode`	No	lookup: find records for an error_text (default). preflight: before calling the tool, give its args_shape and your env; the KB predicts a known failure and returns its workaround, or nothing. server: leave out the tool to list the server's known failures across its tools, verified first.	lookup
`tool`	No	The tool's name as in tools/list. Required, except in the server mode.
`model`	No	The model driving the agent.
`client`	No	The client, e.g. claude-code.
`server`	Yes	The MCP server the tool belongs to: its name, or the npm package npx runs.
`args_shape`	No	The call's arguments as keys and types only, never their values.
`error_text`	No	The error message or the unexpected result, as the tool returned it.
`max_results`	No	How many records to return, from 1 to 20 (default 5).
`server_version`	No	The server's version, when known, e.g. 1.2.0: records of that version are matched.

Output Schema

Name	Required	Description
`records`	Yes
`lookup_id`	Yes
`units_left`	Yes	What the organization has left for lookups after this one.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare read-only/idempotent/local; the description adds material behavioral context: each call consumes one unit of a monthly limit, units_left is reported, at most max_results records return, and results are ordered vendor answer first, then verified workarounds, with unverified ones marked. This is exactly the cost/return-shape disclosure annotations cannot carry.

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?

Purpose is front-loaded in the first sentence and the exclusion is saved for the end. It is one dense paragraph with long clauses, and the mode explanations partially duplicate the schema, but nearly every sentence carries operational value.

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?

Despite nine parameters and an output schema, the description covers everything an agent needs: when to invoke each mode, the cost per call, and the result ordering. Return values are also summarized, which is a bonus since an 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%, so the schema already documents every parameter including the mode enum. The description restates the mode semantics (preflight needs args_shape; server omits tool) but adds little beyond what the schema already says, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Check for known failures and workarounds') and frames it precisely as a pre/post third-party tool call helper. It doesn't explicitly name the write-side siblings (kb_confirm, kb_dispute, kb_report), so the read-vs-report distinction is only implicit.

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?

Gives explicit triggering conditions ('a tool call errored, returned an unexpected shape, or you are about to call a tool you have not used') and explicit exclusions ('Do not use it for questions that are not about a tool call, or for tools of this server'). It even routes the agent to the correct mode for each scenario.

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

kb_reportReport a resolved failureAInspect

Report a tool-call failure you resolved, so other agents can skip it. Call only after the workaround actually worked, and once per failure. Give the server, the tool, the error_text as returned, the workaround that worked (e.g. pass the key as the api_key argument) and your env. Secrets, paths and ids are redacted server-side; do not include raw payloads or the values of arguments. Do not use it for failures of your own code, or for ones a kb_lookup already knew: confirm those with kb_confirm instead. A key may make at most 100 reports a day (its daily limit); it takes no units. Returns the record's id, its state (unverified until others reproduce it) and what was redacted.

Name	Required	Description
`env`	Yes	Where the call ran.
`lang`	No	The language the workaround is written in.
`tool`	Yes	The tool's name as in tools/list.
`notes`	No	Anything else worth knowing: when it happens, what did not work.
`server`	Yes	The MCP server the tool belongs to: its name, or the npm package npx runs.
`lookup_id`	No	The lookup_id of the kb_lookup you made first, if any.
`args_shape`	No	The call's arguments as keys and types only, never their values.
`error_text`	Yes	The error message or the unexpected result, as the tool returned it.
`workaround`	Yes	What made the call work: the steps, the arguments you changed, or the tool to call instead. Markdown.
`error_class`	No	What kind of failure it was, if clear.

Output Schema

Name	Required	Description
`url`	Yes
`state`	Yes
`record_id`	Yes
`redaction_report`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=false, idempotentHint=false) by disclosing server-side redaction of secrets/paths/ids, a write path, a rate limit (100 reports/day per key), cost (no units), and post-write state semantics (record starts unverified until others reproduce it). It also warns what must not be included, which directly shapes safe invocation.

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?

Front-loaded with purpose and the first-use condition, then procedurally ordered guidance. It is dense but each sentence carries operational information; the mixed-register asides ('it takes no units') and run-on pacing keep it from a 5.

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

Completeness5/5

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

For a 10-parameter, nested-schema write tool with an output schema, the description covers selection, timing, exclusion, input constraints, cost, rate limits, and return semantics. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description adds real value by specifying what error_text should contain ('as returned'), what workaround should capture ('the workaround that worked, e.g. pass the key as the api_key argument'), and a critical prohibition on raw payloads and argument values. It stops short of explaining several optional params (lang, notes, lookup_id, error_class) beyond what the schema already says.

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?

States a specific verb and resource ('Report a tool-call failure you resolved') plus the downstream benefit ('so other agents can skip it'). It is clearly separable from the sibling tools kb_lookup/kb_confirm/kb_dispute, which are named explicitly.

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?

Gives explicit preconditions ('Call only after the workaround actually worked, and once per failure') and explicit exclusions ('Do not use it for failures of your own code, or for ones a kb_lookup already knew: confirm those with kb_confirm instead'), naming the correct alternative tool for each excluded case.

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

Tool Schema Changelog

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

1 tool updateOct 14, 2026

Changedkb_lookup2 fields changed

addedOutput schema / properties / records / items / properties / official_answer

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "by": {
+          "description": "The npm package whose owner answered.",
+          "type": "string"
+        },
+        "lang": {
+          "description": "The language it is written in: en or ja.",
+          "type": "string"
+        },
+        "text": {
+          "description": "The answer, in Markdown.",
+          "type": "string"
+        },
+        "updated_at": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "text",
+        "lang",
+        "by",
+        "updated_at"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The answer of the tool's vendor, who proved to Forecall that it owns the package; null when it has not answered."
+}

changedOutput schema / properties / records / items / required

Previous value: -[
-  "id",
-  "tool",
-  "state",
-  "error_class",
-  "error_signature",
-  "workaround",
-  "reproduced_count",
-  "verified_at",
-  "url"
-]New value: +[
+  "id",
+  "tool",
+  "state",
+  "error_class",
+  "error_signature",
+  "workaround",
+  "reproduced_count",
+  "verified_at",
+  "url",
+  "official_answer"
+]

1 tool updateOct 8, 2026

Changedkb_lookup8 fields changed

changedInput schema / properties / mode / description

Previous value: -"lookup: find records for an error_text (default). preflight: before calling the tool, give its args_shape and your env; the KB predicts a known failure and returns its workaround, or nothing."New value: +"lookup: find records for an error_text (default). preflight: before calling the tool, give its args_shape and your env; the KB predicts a known failure and returns its workaround, or nothing. server: leave out the tool to list the server's known failures across its tools, verified first."

changedInput schema / properties / mode / enum

Previous value: -[
-  "lookup",
-  "preflight"
-]New value: +[
+  "lookup",
+  "preflight",
+  "server"
+]

changedInput schema / properties / tool / description

Previous value: -"The tool's name as in tools/list."New value: +"The tool's name as in tools/list. Required, except in the server mode."

changedInput schema / required

Previous value: -[
-  "server",
-  "tool"
-]New value: +[
+  "server"
+]

addedOutput schema / properties / records / items / properties / tool
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / records / items / required

Previous value: -[
-  "id",
-  "state",
-  "error_class",
-  "error_signature",
-  "workaround",
-  "reproduced_count",
-  "verified_at",
-  "url"
-]New value: +[
+  "id",
+  "tool",
+  "state",
+  "error_class",
+  "error_signature",
+  "workaround",
+  "reproduced_count",
+  "verified_at",
+  "url"
+]

addedOutput schema / properties / units_left

Added value: +{
+  "additionalProperties": false,
+  "description": "What the organization has left for lookups after this one.",
+  "properties": {
+    "credits": {
+      "description": "The organization's credits, used after them.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "resets_at": {
+      "description": "When the month's included units start again (UTC).",
+      "type": "string"
+    },
+    "this_month": {
+      "description": "The units the plan still includes this month.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "this_month",
+    "credits",
+    "resets_at"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "records",
-  "lookup_id"
-]New value: +[
+  "records",
+  "lookup_id",
+  "units_left"
+]

4 tool updatesOct 7, 2026
- First observedkb_confirm
- First observedkb_dispute
- First observedkb_lookup
- First observedkb_report

Publisher details

Operator: Mirai Studio, Inc. · Publisher source
Operator website: https://forecall.dev
Vendor relationship: First-party · Publisher source
Documentation: https://forecall.dev/en/docs/kb
Trust center: Not applicable
Restrictions: Requires a Forecall Agents API key (app.forecall.dev/api-keys). The free plan includes 1,000 lookups a month; Pro and Team include more. · Publisher source

Related MCP Connectors

Errata A
com.apidefects
What is known to be broken in an MCP server or API operation, with the check that found it.
API Testing Testing & QA Tools
11
https://apidefects.com/mcp
Error-actionability translation for MCP tool failures B
com.textforagents
Error-actionability translation for MCP tool failures. $0.002/check.
Developer Tools Monitoring Observability
41
https://textforagents.com/products/error-actionability-translation/mcp
MCP Schema AuditOAuth
io.github.tylerscomic-lab
Audits MCP tool definitions for patterns that make models call tools wrong or mis-fill args.
Testing & QA Tools Code Analysis Developer Tools
2
https://mcp-schema-audit-mcp.mcpize.run/mcp
MCP Kill-Chain Research — Stage 1 (Identity ≠ Behavior)A
dev.gtfo
Security research: MCP registries verify identity, not tool behavior. See gtfo.dev.
Security Penetration Testing
2
https://ailm.gtfo.dev/mcp

Related MCP Servers

verimcp
Security Developer Tools Observability
rudranaresh0201
A
license
Not graded
quality
B
maintenance
A transparent MCP proxy that independently re-verifies tool-call claims instead of trusting them, paired with devmcp — the git/CI server it's proven against.
Updated 16 days ago (2026-10-11 19:56 UTC)
1
MIT
MCP Utility Tools
Developer Tools RAG Systems
haasonsaas
A
license
A
quality
C
maintenance
A collection of tools that enhance MCP-based workflows with caching, retry logic, batch operations, and rate limiting capabilities.
Updated 10 months ago (2026-01-07 16:19 UTC)
7
6 npm
MIT
error2fix
Developer Tools Command Line
GRAMMAC1
F
license
Not graded
quality
C
maintenance
Provides coding agents with compressed failure context via MCP, reducing the need to parse full raw logs.
Updated 4 months ago (2026-07-07 05:50 UTC)
1
-
Nexus
Databases Version Control RAG Systems
indraxneel
A
license
Not graded
quality
D
maintenance
Enables models to query enterprise systems—structured data, live GitHub REST API, and unstructured document embeddings—through a single, per-caller scoped MCP tool surface with task-shaped tools and recovery-aware errors.
Updated 2 months ago (2026-08-29 11:46 UTC)
161 npm
ISC

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?