fermi

Send feedback or a bug report to the Fermi team

send_feedback

Sends a short report about Fermi to the team that builds it. They read every report and use it to fix problems and decide what to build, so honest feedback, good or bad, is useful. Use this when:

a Fermi tool returned an error (send it right away), behaved unexpectedly or gave an estimate that looks wrong;
the user needs something no Fermi tool can do, or an option that is missing;
a description, output or error message was confusing;
a session in which you used Fermi is ending: send one short report even if everything worked. Knowing which tools did the job for which kind of question is useful data, not noise. Do not send one after a routine successful call mid-session. Put several points in one report. Only message is required. Fill in the other fields that apply so the team can act without guessing. Write in your own words. Never include personal data (names, email addresses, company names), the user's own numbers or private context, secrets or keys, or the conversation transcript; describe the question and any wrong result in general terms instead. Tell the user you are sending it. Add sender_email only if the user wants a reply; no copy is sent to it. If you are signed in, your account id is included. Returns status "sent".

Cost: free. Works without an account.

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": {
      "message": "<message>"
    },
    "name": "send_feedback"
  }
}

Input Schema

Name	Required	Description	Default
`impact`	No	How much it cost the user. blocked: could not finish. workaround: finished another way. minor: an annoyance. none: no cost, for example praise.
`api_key`	No	Optional Fermi API key. If given, the account id is attached so the team can look into it.
`message`	Yes	The report, in your own words, 10 to 5,000 characters. Say what you tried, what happened and what you expected. Leave out names, companies, the user's numbers or private context, and the conversation itself: write "a market-size question", not the question's details.
`expected`	No	What you expected to happen instead.
`tool_name`	No	The Fermi tool the report is about, for example estimate_quantity_or_probability.
`user_goal`	No	What the user was trying to do, as a general task in a few words, for example "forecast a market size". No names, company names or figures.
`error_text`	No	The error code and message the tool returned, if any. Remove any personal data or private context it quotes.
`suggestion`	No	What would have helped: a fix, a new feature or clearer wording.
`estimate_id`	No	The estimate_id the report is about, if an estimate was involved.
`sender_name`	No	The user's name. Optional; only with sender_email.
`sender_email`	No	Optional. The user's email address, only if they want a reply and gave it to you. Do not invent one. No copy is sent to it.
`feedback_type`	No	What kind of report this is. bug: a tool errored or broke. wrong_result: it ran but the estimate looks wrong. unmet_use_case: the user needed something no tool does. feature_request: a missing option or parameter. confusing: a description, output or error was hard to understand. praise: something worked well. other: anything else (the default).	other
`what_happened`	No	What actually happened, in general terms, without the user's numbers.

Output Schema

Name	Required	Description
`status`	No	"sent".
`billing`	No	Who this call was billed to and what is left. Present on every Fermi result.
`message`	No	Confirmation text, including whether the team can reply.

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedOct 30, 2026

addedInput schema / properties / error_text

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The error code and message the tool returned, if any. Remove any personal data or private context it quotes.",
+  "title": "Error Text"
+}

addedInput schema / properties / estimate_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The estimate_id the report is about, if an estimate was involved.",
+  "title": "Estimate Id"
+}

addedInput schema / properties / expected

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "What you expected to happen instead.",
+  "title": "Expected"
+}

addedInput schema / properties / feedback_type / default
```
Added value: +"other"
```

changedInput schema / properties / feedback_type / description

Previous value: -"\"bug\" for something broken, \"feature_request\" for something new, \"feedback\" for anything else."New value: +"What kind of report this is. bug: a tool errored or broke. wrong_result: it ran but the estimate looks wrong. unmet_use_case: the user needed something no tool does. feature_request: a missing option or parameter. confusing: a description, output or error was hard to understand. praise: something worked well. other: anything else (the default)."

changedInput schema / properties / feedback_type / enum

Previous value: -[
-  "feedback",
-  "feature_request",
-  "bug"
-]New value: +[
+  "bug",
+  "unmet_use_case",
+  "feature_request",
+  "confusing",
+  "wrong_result",
+  "praise",
+  "other"
+]

addedInput schema / properties / impact

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "blocked",
+        "workaround",
+        "minor",
+        "none"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How much it cost the user. blocked: could not finish. workaround: finished another way. minor: an annoyance. none: no cost, for example praise.",
+  "title": "Impact"
+}

changedInput schema / properties / message / description

Previous value: -"What to tell the team, 10 to 5,000 characters. Be specific."New value: +"The report, in your own words, 10 to 5,000 characters. Say what you tried, what happened and what you expected. Leave out names, companies, the user's numbers or private context, and the conversation itself: write \"a market-size question\", not the question's details."

addedInput schema / properties / sender_email / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / sender_email / default
```
Added value: +null
```

changedInput schema / properties / sender_email / description

Previous value: -"The user's email address. A copy is sent here and the team replies here. Ask the user for it; do not invent one."New value: +"Optional. The user's email address, only if they want a reply and gave it to you. Do not invent one. No copy is sent to it."

removedInput schema / properties / sender_email / type
```
Removed value: -"string"
```

changedInput schema / properties / sender_name / description

Previous value: -"The user's name. Optional."New value: +"The user's name. Optional; only with sender_email."

addedInput schema / properties / suggestion

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "What would have helped: a fix, a new feature or clearer wording.",
+  "title": "Suggestion"
+}

addedInput schema / properties / tool_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The Fermi tool the report is about, for example estimate_quantity_or_probability.",
+  "title": "Tool Name"
+}

addedInput schema / properties / user_goal

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "What the user was trying to do, as a general task in a few words, for example \"forecast a market size\". No names, company names or figures.",
+  "title": "User Goal"
+}

addedInput schema / properties / what_happened

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "What actually happened, in general terms, without the user's numbers.",
+  "title": "What Happened"
+}

changedInput schema / required

Previous value: -[
-  "feedback_type",
-  "message",
-  "sender_email"
-]New value: +[
+  "message"
+]

changedOutput schema / properties / message / description

Previous value: -"Confirmation text."New value: +"Confirmation text, including whether the team can reply."

AddedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing cost ('free'), no-account operation, what data travels with the report (account id when signed in, sender_email only for replies), the return value ('sent'), and a firm PII/transcript prohibition. It also states an obligation the agent must honour externally — tell the user you are sending it — which is exactly the kind of behavioural contract annotations cannot express.

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 the purpose, then a scannable bullet list of triggers, a do-not clause, and privacy rules — no filler. It runs long, but for a 13-parameter tool that transmits user-adjacent data the length is largely earned; the privacy paragraph is the one section that restates itself.

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 13-parameter, non-idempotent, externally-visible write, the description covers everything an agent needs: triggers, anti-triggers, required vs optional, consent requirement, redaction rules, auth dependence, cost, and outcome. Since an output schema exists, it does not need to explain return values further, making the brief 'Returns status "sent"' a bonus rather than a gap.

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?

Coverage is 100%, so the schema does most of the work and a 3 would be defensible; the description still adds value by stating that only message is required and that the remaining fields should be filled 'so the team can act without guessing'. The privacy constraint on message content ('write "a market-size question", not the question's details') meaningfully reinforces the schema's own wording rather than merely repeating it, though most per-field meaning stays in 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 concrete verb and resource — 'Sends a short report about Fermi to the team that builds it' — and immediately explains what the team does with it. Nothing in the sibling set (buy_credits, check_account_and_credits, estimate_*, list_my_estimates) could be confused with this, so the routing is unambiguous without opening a 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 an explicit include-list (errors, wrong estimates, missing capability, confusing output, session ending) and an explicit exclusion ('Do not send one after a routine successful call mid-session'), plus consolidation guidance ('Put several points in one report'). The only guidance that could be sharper is which sibling to call first for a failing estimate, but the trigger conditions themselves are complete.

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

All fermi 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.

Resources

Need Help?